Hey... Guess what?
I found out why the upgrade interface, the nav computer and a few other places in VS are so terribly slow with some drivers.
Text background is rendered character-by-character! One batch per character! Holy fuck!
Slowness in bases
-
- Elite
- Posts: 7243
- Joined: Mon Apr 18, 2005 2:40 pm
- Location: LS87, Buenos Aires, República Argentina
-
- Elite
- Posts: 1567
- Joined: Tue Jan 26, 2010 2:03 am
Re: Slowness in bases
That doesn't sound good.
Because of YOU Arbiter, MY kids? can't get enough gas. OR NIPPLE! How does that mkae you feeeel? ~ Halo
-
- Elite
- Posts: 7243
- Joined: Mon Apr 18, 2005 2:40 pm
- Location: LS87, Buenos Aires, República Argentina
Re: Slowness in bases
Yeah, I think we must kick the replace-the-font-system project to high gear. It's a drag.
-
- Elite
- Posts: 1567
- Joined: Tue Jan 26, 2010 2:03 am
Re: Slowness in bases
Is the system using bitmapped fonts or some api call such as the GDI calls made by DirectX
Because of YOU Arbiter, MY kids? can't get enough gas. OR NIPPLE! How does that mkae you feeeel? ~ Halo
-
- Elite
- Posts: 7243
- Joined: Mon Apr 18, 2005 2:40 pm
- Location: LS87, Buenos Aires, República Argentina
Re: Slowness in bases
glut, which does both bitmap fonts and "vector fonts" (with glut's funny definition of "vector fonts" as "lines").
It's awful. All the separate batches interspersed with raster ops (which is what glut uses internally, I just checked the code), is killing most drivers in performance metrics. I can confirm this with both nVidia and Intel, both Mesa and nVidia's binary driver.
In short, glut's text rendering is simply unusable, but even if replaced, the API would switch unruly between character texture and background, which would also kill the driver. This things needs a refactor.
I've been looking around, and we have two text rendering implementations (they look copypasted). One in hud.cpp, and one in gui/font.cpp. I'd keep the gui/font one, it looks tidier, and replace it with TTF-backed texture-cached fonts, rasterized with freetype.
Bad mojo is I lost my internet at home. I couldn't work at all during the weekend - I notice how useless I am without the internet to check documentation and stuff... I just couldn't do squat.
It's awful. All the separate batches interspersed with raster ops (which is what glut uses internally, I just checked the code), is killing most drivers in performance metrics. I can confirm this with both nVidia and Intel, both Mesa and nVidia's binary driver.
In short, glut's text rendering is simply unusable, but even if replaced, the API would switch unruly between character texture and background, which would also kill the driver. This things needs a refactor.
I've been looking around, and we have two text rendering implementations (they look copypasted). One in hud.cpp, and one in gui/font.cpp. I'd keep the gui/font one, it looks tidier, and replace it with TTF-backed texture-cached fonts, rasterized with freetype.
Bad mojo is I lost my internet at home. I couldn't work at all during the weekend - I notice how useless I am without the internet to check documentation and stuff... I just couldn't do squat.
-
- Elite
- Posts: 1567
- Joined: Tue Jan 26, 2010 2:03 am
Re: Slowness in bases
Thats why I like to have hardcopies of material I need. So long as its small enough to print out at home anyway...
Because of YOU Arbiter, MY kids? can't get enough gas. OR NIPPLE! How does that mkae you feeeel? ~ Halo