Interface Draw performance

[eriatarka]

Hi,

I've noticed Interface Draw takes up a *lot* of CPU time on my machine (Athlon 3200 XP, 2G Ram, Radeon 9500, Win2k). I commonly have it taking up 40-50%, often even more than Draw World. Lua doesn't seem to be the only offender here, because if I disable Lua widgets from the Spring settings, it does seem to get a little better, but not that much.

From searching the forum, it seems other people have noticed that same problem. Has anyone looked into this? It seems like there's a lot of optimization potential in this code. Or is there a valid reason why it should take so long? I'm completely new to the Spring codebase, but I'd like to investigate this if it might be worthwile. (Downloading from SVN as I write this...)

eria

[Argh]

I don't know much at all about this topic, but I am inclined to agree with your assessment- disabling LUA, and using the "standard" interface, doesn't seem to change performance much. I'd say that that probably means that the LUA interface has become about as efficient as the standard one, though, not that the standard one is amazingly slow, for what it does.

However, that said- many of the current Widgets aren't very efficiently using the whole processor time available. They do not use a spread-frame processing model, and execute on the same frame every second, and many of them use the same frame- a single SlowUpdate (about half a second), although from looking at CA's code, it looks like they're starting to space stuff out a lot more, for stuff that can run more slowly, which is good.

I plan to look into how to do this when I get the chance, it's something that I do with everything in BOS in my games (due to the same issues there, in synced code), and I suspect that causing things to choose their execution frame with a random amount of frames between executions could significantly help with loading overall. There hasn't been a great deal of attention paid to loading on the LUA side yet- everybody's been chugging away, getting stuff to work, and work fast, within the frame it executes, but little attention has been paid to distributing the load. Should be a very easy piece of logic.

[eriatarka]

Thanks for your thoughts. I've noticed you mentioning this topic of spreading calculations over frames a few times already, and I think you have a good point there.

At the moment, though, I'm solely looking at InputReceivers, i.e. stuff that has to be rendered every frame anyway because it is part of the UI. Turns out font rendering is dog slow: just rendering the few labels on the ResourceBar takes 3-4% on my machine when nothing much else is happening. I'm looking into it at the moment. Besides, I'm cleaning up the ResourceBar drawing code, which is a frigging mess.

While we're at it: doesn't it bother anyone else beside me that the small font on the resource bar is almost illegible? I'm sure we can do better than that.

The huge CPU hog in Interface Draw was therefore the profiler itself, which draws a *lot* of strings. So it's not as bad as I thought, but it still shows that font rendering is too slow.

[BrainDamage]

the profiler shows relative cpu usage ( if interface draw takes 50% of spring resources and spring 2% of the cpu, the cpu usage by interface draw is 1% ), so make sure you got a "real battle" when checking values, if there is not much else to do i guess it's normal for it to represent majority of resource usage

[trepan]

From many moons ago:
viewtopic.php?p=177875

The key point is that the lua setup uses a texture atlas,
so that even while being slower than engine C++, the
font stills renders more quickly. You could also use a
GL/font library to replace the current system (ex: ftgl).

[trepan]

Something else to note: just disabling LuaUI is not
enough to make sure that you have all Lua rendering
disabled. Test with a map/mod combination that does
not use LuaGaia/LuaRules. There are some pretty
heavy GL state resets that occur when the lua
script Draw call-ins are used.

[eriatarka]

From many moons ago:
viewtopic.php?p=177875

The key point is that the lua setup uses a texture atlas,
so that even while being slower than engine C++, the
font stills renders more quickly. You could also use a
GL/font library to replace the current system (ex: ftgl).

Ah, thanks for that info. I've looked into glFont.cpp, and indeed the problem is that each glyph is rendered into a separate texture; no wonder it's slow.

So there is a Lua script circumventing that problem? That's nice, but this seems to be a workaround at the Lua layer that really shouldn't be necessary if the core engine did it the right way. Also, the InputListeners I've looked at (CResourceBar, CTimeProfiler etc.) don't use Lua, so they don't benefit from that faster text rendering. Finally, while Lua is a comparatively fast scripting language, it's still only a scripting language, and its use for low-level rendering code where it isn't necessary somehow seems wrong to me.

So, what was the reasoning for doing this Lua workaround instead of fixing the problem at the root, in the engine? This shouldn't be too hard to do, and I'd like to try this as a first small project with Spring. Maybe the font.lua file could then be eliminated?

By the way, I've found that the illegible resource labels come from the fact that the font is first created at 20pt, and the texture is then scaled down for this smaller text. That doesn't look nice, of course.

[imbaczek]

there was only one problem with the current code - it's "good enough" (as in "works, do not touch") for most of the devs. that shouldn't stop you though :)