Remove software rendering as an "official" option

[SirVer]

Software rendering must die! This bug discusses if it can die now.

Here are some reasons:
1) It is SLOW, so slow. It cannot keep up with the ever increasing resolutions of displays. Playing Widelands on 1280x800 at 60fps takes nearly a full CPU in software mode. That leaves no room for logic, AI ....
2) It holds us back with implementing new features. For example, I had a zoom implementation running on my machine for the OpenGL renderer already, but implementing it in the software renderer was too cumbersome and would have been too slow, so I decided to throw it away.
3) It dictates design: The OpenGL implementation could be much more efficient if we bunch up many textures in one big one, the software renderer relies on a texture being one continuous block of memory. Changing the design only for the GL renderer is hard if the other one is still around.
4) It complicates the code. One renderer == simpler, less bugs, less options.
5) It is not necessary: We now use Open GL 2.1 for rendering (Release date: July 2, 2006), no extensions, no magic. This should literally work on any computer that can display graphics. Software rendering was sometimes still needed because we used extensions to the (much older) Open GL 1.1 which some devices did not even bother to implement anymore.

Caveats: we render the minimaps on the homepage using the software renderer (through src/logic/wl_map_info). Maybe we can use a software only gl driver for that though, this needs investigating.

Thoughts, opinions?

[Tino (tino79)]

I agree.
Regarding the minimaps: What about putting a small render image (png) of the map into the wmf container?
The widelands editor could do this on a save using the opengl renderer (screenshot functionality?).

[GunChleoc (gunchleoc)]

We also have minimaps with savegames, they will need to be generated as well. I don't know how the current code works.

Otherwise, sounds like a good idea. Less code to maintain + faster - what's not to like?

[SirVer (sirver)]

The minimaps in the savegame are written on save. Tino is right that we could do the same when saving maps - we would need to add the images to the maps on the homepage while people still upload with old version which would be a pain, but doable.

Having the ability to work with graphics even while headless (no window) would still be nice though - for example for programs that recompact graphics and so on. Maybe it is not necessary though... I need to think some more about this.

[Hans Joachim Desserud (hjd)]

Regarding point 3) (with the disclaimer that I have no idea about this); shouldn't that be just an implementation detail? I would think that the renderer just sits there until someone throws an object at it and tells it "draw this to the screen". How textures are stored and organized in-memory should be up to the individual renderer to figure out. Or would it require changes in the way textures are stored on disk? (Sounds like there might be an abstraction layer which isn't totally clear here, but fixing that might require a refactoring which might be too late/not worth it given the title of this report).

Point 5) I think the main reason for keeping the software renderer around was as a fallback in case the user didn't have graphics card/driver capable of using openGL. If support for openGL 2.1 is indeed widespread enough that this is no longer an issue, I agree that much of the basis for keeping it around disappears.

Btw, what's the current state of driver support for OpenGL on Microsoft Windows like? I got the impression it was a bit lacking some years back, since most Windows-software used DirectX anyways. I haven't followed this closely, though with the move to more cross-platform development (OS X, Steam porting, etc) the situation seem to have improved a lot. Though the main question would be whether it works for people running older hardware/operating systems and drivers.

I think the rest of the points are valid.

[GunChleoc (gunchleoc)]

Seems like OpenGL support depends on the video driver http://answers.microsoft.com/en-us/windows/forum/windows_7-hardware/opengl-driver-missing/d3f01e2c-831a-4277-8818-075ff46bc879

So, if the video card supports it and has an appropriate driver, OpenGL is available in Windows 7.

OpenGL has in principle been available in Windows XP, which is now oooold and past its end of life https://www.opengl.org/discussion_boards/showthread.php/161387-OpenGL-Windows-Vista

And here's the OpenGL documentation for Windows, just in case this might come in useful http://msdn.microsoft.com/en-us/library/dd374278%28v=vs.85%29.aspx

Aaand... a similar discussion on the 0AD forum: http://www.wildfiregames.com/forum/index.php?showtopic=16734&hl=opengl

[Hans Joachim Desserud (hjd)]

>Seems like OpenGL support depends on the video driver

Yes, and I got the impression that some drivers focused on DirectX, but more or less ignored OpenGL support. This is some years ago, and I don't know how accurate it was, so I'm curious.

>Windows XP, which is now oooold and past its end of life
Yes. Ancient operating systems which have reached end of life should not hold us back. We're mainly concerned with currently supported ones. Btw I can't load this link, I get a certificate error: sec_error_ocsp_old_response. Just me?

[GunChleoc (gunchleoc)]

No certificate problems here. It would indeed be interesting exactly how widespread OpenGL support is under Windows now, starting from Windows Vista.

Some more info:

http://stackoverflow.com/questions/758874/what-percentage-of-windows-boxes-have-opengl-support

It seems that we will be fine supporting hardware from 2006 up if we use OpenGL only. Also, from the Steam survey, Windows Vista use is around 2%, so it won't be around much longer. Windows 7 is still very strong, probably because not everybody likes Windows 8.

[SirVer (sirver)]

Answers to #4:

3) It is not that simple. The concept of how the textures are represented can be abstracted away, but it is much simpler if we only have on engine to care for in either case. For example, there is one class that is loading an image from disk and creates a texture out of this. This would need changes for texture atlases to support images that never change and are rendered always together and dynamic textures like the rendered richtext. That is something that the software renderer would not care about.

5) We have no data in either case. Could be that fallback software is used by many people, could be that it was not used in years. We can only remove the support and wait for the outcry. Or are there other options?

The 0AD discussion actually is supporting my case very strongly. They are even much more aggressive about it actually.

So for me the remaining issue is how to draw minimaps on the server. We can always fall back to tinos suggested solution for that.

[GunChleoc (gunchleoc)]

Sounds good to me. People rarely use computers older than 10 years for their daily stuff, because by then they will probably go on the fritz anyway. And we have already hit the 8 year mark according to my research in #7.

[SirVer (sirver)]

Okay, so we are on the same page. As a first step, I ripped out falling back to software rendering. OpenGL can still be disabled in the options or via commandline.

Next step will be to write a minimap to each mapfile and update the homepage to use it.

Next: update the homepage so that it can deal with maps without minimap.

Next: rip out software rendering.

[Hans Joachim Desserud (hjd)]

Answers to #8
3) Ok, just wondered.

>Could be that fallback software is used by many people, could be that it was not used in years. We can only remove the support and wait for the outcry. Or are there other options?

Can't really think of any other good solutions.

What I think would be a good idea is to have a beta/release candidate which is available for a longer time than usually. I don't have any data to back this up, but it is my impression that more people run release candidates than the development builds. This means it would be tested on a wider variety of hardware and we would be able to assess how overwhelming (or lacking) the pressure for a software fallback is.

This sorta brings us to another discussion, which I don't think we should cover in depth here, but what are the plans for the next release?

[SirVer (sirver)]

I now made a patch that writes the minimap into maps (https://code.launchpad.net/~widelands-dev/widelands/save_minimap) to support tinos suggestion. However, I also figured something out for the sever: There is a tool called xvfb which fakes an X environment and a library called MESA that fakes OpenGL in software. I tried it on the server and it seems to be working, so we have a working solution for graphics on the server. The only downside is that the server is running 12.04 LTS and we do not build dailys for this anymore - so I have no current Widelands version on the server to test with. Maybe I can upgrade to 14.04 LTS, but I wait for feedback from strato if this is save on a virtualized server.

 > This sorta brings us to another discussion, which I don't think we should cover in depth here, but what are the plans for the next release?

One Tribe is the last big project for the next release I have. I think we can plan for a new release in q1 or q2 next year.

[SirVer (sirver)]

I remove the software renderer in r7275.

Oh the possibilities people - we might now even be able to get a proper fullscreen switching!

[GunChleoc (gunchleoc)]

Fixed in build19-rc1.