OpenGL issues with old cards/drivers

[SirVer]

by galtgendo from IRC:

Thi old card in question has a broad choice of *six* texture formats,
it accepts for framebuffer: MESA_FORMAT_B8G8R8A8_UNORM,
MESA_FORMAT_B5G6R5_UNORM, MESA_FORMAT_B4G4R4A4_UNORM,
MESA_FORMAT_B5G5R5A1_UNORM, MESA_FORMAT_Z24_UNORM_S8_UINT,
MESA_FORMAT_Z_UNORM16. So, you see, not much of a choice here.

This patch seems to work for butoons, tooltips and most of the windows,
sole exception being minimap. That one, while on occasion drawn
correctly, has problems with redraws, even on map scrolls.

Not sure what exactly goes wrong - most of the times it's not a typical
corruption (random pixels drawn), but simply not correctly drawn (whole
black or doesn't follow map position).

So, could you provide any hints on how to improve the patch ?

[SirVer (sirver)]

I am not sure what to say about the patch. It is pretty tiny and only introduces one more boolean state into the engine, so it is kinda unobstrusive. However we try right now to move Widelands onto tablets which means modernizing our OpenGL stuff and not support uncommon/broken/old configurations. We can apply this patch now, but it is very likely that it will break again in the near future. Also with OpenGL changes we can never know if we are not breaking other people. What would you do?

[Rafał Mużyło (galtgendo)]

So, as I've said on IRC, I did a bit more testing and managed to fix a minor regression caused by my patch.

However, the problem with the minimap remains and I've got no idea atm. where exactly minimap differs from (seemingly) all other surfaces.

Also, there might be a problem about GL_INTENSITY, but I can't tell for sure as I'm uncertain where exactly it's used.

That glTexSubImage2D bit is likely redundant - I was trying to figure out if perhaps it's a matter of uninitialized memory.
The change in src/graphic/render/gl_surface_screen.cc *might* not be needed as it seems all color components are treated same way, but for consistency...

Also, I need to elaborate on what exactly is the type of the corruption.
First of all, there's the generic corruption part; stuff is being drawn that seems to come from other programs, for example if I'm running windowed, on parts of the minimap I often see my clock and sometimes widelands window title.

Second, some of the times the minimap is drawn correctly, but at the wrong y-position (x seems correct).

Third, the reaction on mouse clicks is very slow.

[SirVer (sirver)]

maybe shevonar still remembers something about the minimap code that could help you.

[Shevonar (shevonar)]

As far as I remember the minimap is drawn by the software renderer alone, so I don't know why these OpenGL should cause problems there. I also never really touched the minimap code. Sorry I could not help.

[Rafał Mużyło (galtgendo)]

> As far as I remember the minimap is drawn by the software renderer alone

No, not really, it's drawn on a Surface, which might very well be a GLSurface.

Still, having looked at the code more, I strongly suspect it's a performance matter - map is redrawn faster than the hardware allows, therefore every now and then it's being drawn from memory that's already been released and claimed by different textures.

So, how can I implement minimap caching and redraws every 2 or so seconds (following the comment in src/graphic/render/minimaprenderer.c in draw_minimap) ?

[Hans Joachim Desserud (hjd)]

>However we try right now to move Widelands onto tablets which means modernizing our OpenGL stuff and not support uncommon/broken/old configurations.

Might be borderline off-topic, but have we at some point specified which opengl version we are targetting? I can't remember it, if that's the case. CMakeList.txt only checks whether the opengl headers are present AFAICS, but I do believe there is some feature sniffing going on when starting Widelands for the functionality we actually use. There was some talk about opengl-es support (bug 984372), but I don't think that ever led to anything code-wise.

I think having a clearer target in mind might make situations like this easier to deal with. If we target, say, opengl-es 2.0 (or whatever), then any driver supporting that standard should* be able to run Widelands. This would also make it easier for players to tell whether it might run or not on their system than an ambigious "opengl required".

I think a natural first step would be to decide which version of the standard we are targetting, get that in place, and then look at whether support should be extended for certain older systems. Could this potentially also make it easier to assess the risk/benefit when adding special cases such as this example for supporting older systems?

*excluding driver bugs and other real-world concerns :p

[SirVer (sirver)]

There are clear steps to that:

- Figure out what standard is supported by current tablets (iphone, nexus 7) and current OSes (Win, Mac, Linux). Use this as standard. I think this will be OpenGL ES 2.0, but I have very little experience with OpenGL, so somebody with more experience or who did more research needs to verify.

- (Re)implement the current feauteres using the standard.

[Rafał Mużyło (galtgendo)]

> Figure out what standard is supported by current tablets (iphone, nexus 7) and current OSes (Win, Mac, Linux).

Don't you mean "which version of OpenGL is supported by specific card models" ?
Mesa 10.1 - for example - does implement OpenGL 3.3, but r200 is stuck at 1.3 and i915 is 3.0, cause it simply doesn't make sense to implement on older cards what the card itself won't pull off.

This sounds for me a bit like "lets make use of trilinear filtering in a SNES emulator".

On one hand r200 might be a tad low these days, on the other unless you're planning to rewrite the rendering from the scratch, do you *really* need all those new features ?

[SirVer (sirver)]

It is my understanding that the current rendering will not work on most mobile devices. So the answer to your question seems 'yes'. If you are specialist and can get the current code to run efficiently and correctly on most tablets, please do so.

[Launchpad Janitor (janitor)]

[Expired for widelands because there has been no activity for 60 days.]

[SirVer (sirver)]

I read up on OpenGL a bit now, and I think it makes sense to use the subset of features that is in OpenGL 2.2 ES. That means that OpenGL 3.0 on the desktop should be enough to carry what we do in Widelands.

[SirVer (sirver)]

s/OpenGL 2.2 ES/OpenGL ES 2/