Extremely slow framerate/performance with OpenGL

[Nicolai Hähnle]

On current bzr trunk, I noticed that Widelands is extremely slow (less than 1 fps) in-game in OpenGL mode.

Workaround: From the main menu, go to Settings -> Advanced Settings and turn off OpenGL. If even the main menu is too slow, you can start Widelands with the parameter --opengl=0 to force turning off OpenGL.

This happens with the following system setup:
- Lenovo Thinkpad T60 with Intel 945GM family integrated graphics
- Ubuntu 12.04 (Precise Pangolin)
- Linux kernel 3.2.0
- X.Org Intel driver 2.17
- Mesa 9.0

I know this system to be able to run Widelands in OpenGL in principle, though too many components (both Widelands and the Linux installation/graphics driver) have changed to be able to isolate the culprit quickly. (Though I should mention: common 3D games work as well as one would expect them to work with this kind of hardware, so it is not a completely obvious driver problem.)

If anybody else sees very slow OpenGL performance, it may be a good idea to collect system specs in this bug report. I'll keep investigating this myself as I find the time to do so.

[Gabriel Margiani (gamag)]

For me, I think it is a hardware or driver problem, since I can't remember it working on this laptop, but maybe my specs are useful somehow.
 - Acer Aspire 1310, S3 Graphics proSavage DDR
 - OpenSuse 12.2
 - Linux 3.4.11
 - Mesa 8.0.4

[SirVer (sirver)]

The only thing that was changed on OpenGL is that we now need a kind of framebuffer support (for of screen rendering). I implemented autodetecting of ARB and EXT support - both are good enough for us. But of course, OpenGL always suckz :)
This was merged in r6446 with the new rich text render.

Try going back before that revision and see if you still have trouble - you might debug from there.

[Nicolai Hähnle (nha)]

I actually went all the way back to build-17, which I know used to work well, but even build-17 runs as slow. So it must be a change in the driver or other system component. On the other hand, the number of triangles and the overdraw in games like Cube or the various older Quakes should be on the same order of magnitude as for Widelands, and those games run just fine (as well as can be expected on a six year old laptop...).

By disabling different code paths, it turns out that it suffices to have terrain rendering (without bobs or immovables or overlays) to get this extreme slowdown.

It may be tempting to blame the driver developers for this regression. But to be honest, our OpenGL terrain rendering has always been horrible. What we do (tons of state changes + immediate mode) is the exact opposite of what everybody knows OpenGL best practices to be. On top of that, immediate mode is FUBAR from the perspective of driver development (I speak from experience ;-)), so I personally don't blame the Mesa developers if it turns out that the performance regression is in their code (which is the most likely scenario).

I should find some time over the next few days, I will see what I can do about the terrain rendering code.

[SirVer (sirver)]

I guess this is fixed for you now, nicolai, right?

Fix was merged in r6501.

[Nicolai Hähnle (nha)]

Yes. Thank you!

[SirVer (sirver)]

Released in build-18 rc1.