Texts not displayed correctly with the new font renderer

[wl-zocker]

Discovered in r7712 on Win10.

As you can see in the attached screenshot, most text are unreadable. The same problem exists in the menus.

Readable texts (apart from those in the screenshot):
- The lists for resolutions and languages in the options menu.
- The text boxes in campaigns (but not the OK button).
- Also notice that some texts are partially readable (e.g. Kundschafterhütte).

The stderr is empty, the only suspicious lines in stdout are:
Font file not found. Falling back to serif: serif
Could not find file: could not find file or directory: i18n/fonts/serif
(see bug 1535296).

I also noticed that Widelands needs some seconds to display the map information when I select a map for the first time - not sure if that's related.

[SirVer (sirver)]

This is not reproducible on any of my system which suggests a gl driver issue.

Do you know a recent good revision? I could see z-buffer problems be responsible for this, but knowing the breaking revision will make this easier.

> Am 19.01.2016 um 14:54 schrieb wl-zocker <email address hidden>:
>
> Public bug reported:
>
> Discovered in r7712 on Win10.
>
> As you can see in the attached screenshot, most text are unreadable. The
> same problem exists in the menus.
>
> Readable texts (apart from those in the screenshot):
> - The lists for resolutions and languages in the options menu.
> - The text boxes in campaigns (but not the OK button).
> - Also notice that some texts are partially readable (e.g. Kundschafterhütte).
>
> The stderr is empty, the only suspicious lines in stdout are:
> Font file not found. Falling back to serif: serif
> Could not find file: could not find file or directory: i18n/fonts/serif
> (see bug 1535296).
>
> I also noticed that Widelands needs some seconds to display the map
> information when I select a map for the first time - not sure if that's
> related.
>
> ** Affects: widelands
> Importance: Undecided
> Status: New
>
> ** Attachment added: "shot0006.png"
> https://bugs.launchpad.net/bugs/1535732/+attachment/4552665/+files/shot0006.png
>
> --
> You received this bug notification because you are subscribed to
> widelands.
> https://bugs.launchpad.net/bugs/1535732
>
> Title:
> Most texts not displayed correctly
>
> Status in widelands:
> New
>
> Bug description:
> Discovered in r7712 on Win10.
>
> As you can see in the attached screenshot, most text are unreadable.
> The same problem exists in the menus.
>
> Readable texts (apart from those in the screenshot):
> - The lists for resolutions and languages in the options menu.
> - The text boxes in campaigns (but not the OK button).
> - Also notice that some texts are partially readable (e.g. Kundschafterhütte).
>
> The stderr is empty, the only suspicious lines in stdout are:
> Font file not found. Falling back to serif: serif
> Could not find file: could not find file or directory: i18n/fonts/serif
> (see bug 1535296).
>
> I also noticed that Widelands needs some seconds to display the map
> information when I select a map for the first time - not sure if
> that's related.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/widelands/+bug/1535732/+subscriptions

[kaputtnik (franku)]

Couldn't confirm this for r7712 under linux. The things shown in screenshot and the options menu works fine. Also textboxes in campaigns.

> I also noticed that Widelands needs some seconds to display the map information when I select a map for the first time

I couldn't confirm "some seconds" but sometimes the information isn't shown immediately. You meant the menu to start a new game?

I am wondering about your localization. Some of the strings (like: "Kundschafter") isn't localized to german here.

[wl-zocker (wl-zocker)]

r7689 works fine, but r7702 shows the glitches.

Map selection:
Yes, I meant Singleplayer -> New Game. Not every map takes so long (one I tried was three seconds, some others cause a noticeable delay).

Localization:
I use Tino's release builds. I have some older versions installed, I don't know if they mess translations up. But Kundschafter is the current German translation on Transifex.

[SirVer (sirver)]

I suspect r7692 (render queue) or r7704 (texture atlas, [2]) or r7709 (full image cache), to be the culprits, in order of likelihood, highest first.

Since recently we have continuous integration for Windows too, which creates installers for each commit. It started working just after 7693, which is unfortunate, because we cannot test if it was good before, but we know that at 7689 everything was good.

Could you test the installers, mentioned below starting from the top and stopping with the first one that is broken?

Windows installers:

at 7693, one commit after render_queue: https://ci.appveyor.com/project/widelands-dev/widelands/build/master-132/artifacts

at 7702, before texture atlas https://ci.appveyor.com/project/widelands-dev/widelands/build/master-169/artifacts
7703 does not seem to be build by appveyor :(
at 7704, texture atlas, https://ci.appveyor.com/project/widelands-dev/widelands/build/master-173/artifacts

at 7708, https://ci.appveyor.com/project/widelands-dev/widelands/build/master-192/artifacts
at 7709, https://ci.appveyor.com/project/widelands-dev/widelands/build/master-198/artifacts

[SirVer (sirver)]

Just realized that you already mentioned a higher bound for the commit... sorry. Could you test the render queue?

[Tino (tino79)]

Sorry, there are currently missing files in the appveyor artifacts. To fix: extract attached zip to the install dir.

Apart from this: I cannot reproduce these errors with my local builds (gcc 5.3, static linking) or an installer downloaded and installed from appveyor.

Because in recent builds the translations are pretty outdated (several weeks since the last transifex sync), may strings are not translated because the source code has changed!
So when i am running current trunk, e.g. the scout's hut is not translated at all, even with german language setting the string "Kundschafterhütte" does not appear ingame.

When installing new builds, do you uninstall previous builds? I am suspecting a file mixup in your directory. Please try a really fresh install in a new directory and/or delete any remaining files after uninstalling an older version.

[wl-zocker (wl-zocker)]

I can download the installers from appveyor and install Widelands. Afterwards, I add the files from #7. When I start Widelands, I only get a black screen and a message box "Widelands does not react". The stdout ends after the graphic report, the stderr is empty. I tried the first two links (r7693 and r7702), both in a new directory, and none of them worked. So I cannot test anything.

Two things about this appveyor:
- The installer doesn't ask me where I want to install Widelands. Instead, it chooses the last location. Tino's installer offers the last direcotry as default, but lets me change it, which makes having several version at the same time easier.
- Is this something official? If so, is there a conversion list revision number <-> appveyor version? I would like to add this information to the wiki then (but not before the missing files are included).

I have also quickly tested the latest version (r7715) on Ubuntu, where everything is fine.

When I install a new Widelands version, I usually use the same directory as before. But r7689 and r7702 (downloaded from Tino's site) have been installed into a new directory, and r7702 shows the glitch.

[Tino (tino79)]

The most recent build by appveyor is fine:
https://ci.appveyor.com/api/buildjobs/h8t4tirbd4j92ko3/artifacts/Widelands-master-222-win64.exe

I've downloaded this and the installer works as excpected, i can choose any install dir:
https://imgur.com/a/MjZqx

Another screenshot shows that the scout's hut is currently not translated in the build menu. So if there are german strings displayed, somethings mixed up.

All these tests were done with Win 7 x64.

I'll have to check if i can reproduce anything on my Win 10 System the next days. Perhaps Innosetup does not produce Win10 compatible installer at the moment?

There is no direct conversion list between appveyor build number and a specific bzr revision. Appveyor does use a continous number (over all branches) and the branch name. So you can't conclude from "bzr[xxxx]" to the appveyor build but the other way round: "master-222" is unique in the appveyor build history and allows lookup of the specific git commit it which relates to an specific bzr branch/commit.

[GunChleoc (gunchleoc)]

- From the description, the bugs only happen with fh1, not with fh.

- The map descriptions are loading a bit slow right now, because the word wrap algorithm used is slower than the old one. I made it this way so we could get some more testing exposure for it, because in the end, it will be used in editing fields only (Editor -> Map Options). I will switch over to using the new font renderer without any go-between before build19, so the map descriptions will then load fast again. So, not related to this bug.

- The missing localizations are also a different bug.

[wl-zocker (wl-zocker)]

I cannot choose the install dir; after the license agreement, I get directly to the components selection (I can choose user-defined installation here, but that doesn't help).

Win7/Win10 might be a problem, although so far, everything that ran under Win7 also runs under Win10.

With master-222, the window flashes open and I get this in stderr:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Caught exception (of type '10WException') in outermost handler!
The exception said: [C:/projects/widelands/src/graphic/build_texture_atlas.cc:121] The texture atlas must use at least 2048 as size (1024 was given)

This should not happen. Please file a bug report on version master-222(Release).
and remember to specify your operating system.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Do you want a seperate report for this?

[Tino (tino79)]

Ok, i think we really need to split these bugs up:

- I downloaded the 7712-installer and installed it on my Windows 10 system, no problems to install (if you can't choose the directory it means you already have a Widelands version installed. We do not change the internal appID for different installers.)
- No text artifacts or problems at all

But:
If i install the same installer on my Windows 7 system, many strings are not translated.
E.g. in the small buildings menu every building name is english except the "Wachposten". But everywhere it is "Baukosten".
On Windows 10 everything is german.
On both systems it doesn't matter if i set language to "German" or "System setting".

So, i would excpect different behavior between my builds and appveyor builds due to different library versions, but i've no clue why the same binary (7712 widelands.exe statically linked) show such an different behavior on Win10 and Win7 :(.

[SirVer (sirver)]

I have a hunch about the z-layering issues of the text and proposed https://code.launchpad.net/~widelands-dev/widelands/disable_gl_depth/+merge/283353. Could we get that tested somehow?

[wl-zocker (wl-zocker)]

I tried to, but I still get the texture atlas problem (bug 1536377). It seems that has to be fixed first.

[SirVer (sirver)]

The appveyor build with a potential fix is here: https://ci.appveyor.com/project/widelands-dev/widelands/build/_widelands_dev_widelands_disable_gl_depth-231/artifacts

Could somebody who had the problem please try that build?

[SirVer (sirver)]

I am optimistically setting this to fixcommitted now . 7720 might work okay.

I checked with nha and we actually did render in offscreen textures using GL_DEPTH testing without clearing the Depth buffer ever. I thought that was well defined, but according to nha (who works on gl drivers) it is not. This is fixed in 7720 and might be all that was needed. Could somebody please verify?

[wl-zocker (wl-zocker)]

Still doesn't work on Win10 with r7721 from Tino's site.

[SirVer (sirver)]

Is the behavior still exactly the same?

Is the dynamic behavior similar to https://www.youtube.com/watch?v=Zk-icEzCIxU?

Could I get a couple more screenshots from various places in the game?

[wl-zocker (wl-zocker)]

As far as I can tell, the behavior has not changed at all. Every time I start Widelands, the details of the texts shown are a bit different (compare the Kundschafterhütte from my first screenshot with the one attached to this, in-game.png. While they differ in detail, the general shape in the same. These changes are normal and happen whenever I restart Widelands. Maybe this helps.

I have no dynamic behavior. No texts change when I move my mouse or click anywhere. They are always as presented in the screenshots.

I attach a couple of screenshots. Some comments:
- In both in-game screenshots, building names and statistics are switched on.
- In the editor, I have selected a terrain. No text is shown in the bottom.
- The text on the splash screen ("press any key") and the tips shown on loading are also corrupted. (No screenshots possible)
- The save game dialog is corrupted, too, but the list of savegames and the field to enter the new filename are fine. (No screenshot possible)

[SirVer (sirver)]

wl-zocker, has the situation changed? Can you run the appveyor builds with glbinding now maybe so we can get opengl tracing?

[wl-zocker (wl-zocker)]

Not really.
Master-522 (Debug) x64 gives me a runtime error and this output to stderr (--debug_gl_traces=true doesn't change anything):
terminate called after throwing an instance of 'WException'
  what(): [../src/graphic/build_texture_atlas.cc:121] The texture atlas must use at least 2048 as size (1024 was given)

(The difference to the error message from bug 1536377 might be because that was a release build.)

The output to stdout is the same as in https://bugs.launchpad.net/widelands/+bug/1536377/comments/11.

[kaputtnik (franku)]

Testing with this appveyor build (win32 bit):https://ci.appveyor.com/project/widelands-dev/widelands/build/_widelands_dev_widelands_bug_1395278_scripting-525/job/qtq9egydleirkp0x/artifacts

I get this also. Texts are not shown or replaced with parts of other images. See attachment(s)

[SirVer (sirver)]

kaputtnik, can you run the game with --debug_gl_trace=true and attach the full output? The file will get pretty big pretty quick, so only run the game till you see broken text.

[kaputtnik (franku)]

I would, but i couldnt get any output in console. What i have tried

> widelands.exe --verbose
> widelands.exe 1> widelands.log
> widelands.exe 1> widelands.log 2>&1
> widelands.exe --debug_gl_trace=true

There is no output in console ever, nor a file named widelands.log is created. I have also looked into the temp folder. Just nothing.

> widelands.exe --help
> widelands.exe -?

shows also nothing.

Used cmd to get a console.

[kaputtnik (franku)]

Sorry... i have found it... damn windows cuts always the extension...

The attached output is from command:

widelands.exe --debug_gl_trace=true 1>widelands_gl.log

[Tino (tino79)]

Just wondering: The screenshots clearly show build-416, but you said you have downloaded build-525?

I am sorry i cannot help here, i cannot reproduce this on any machine I've at hand. The only thing i can suggest:
- Uninstall every Widelands version that exist on your system
- Check folders if there are empty or better have been completely deleted on uninstall
- Delete (Backup) %USERHOME%\.widelands
- Uninstall the latest build http://widelands.8-schuss.de/Widelands-bzr7817-nomusic-win64.exe

But for me it looks like a driver/Hardware problem..

[kaputtnik (franku)]

> Just wondering: The screenshots clearly show build-416, but you said you have downloaded build-525?

Yes... i had to explain that. I installed first build416, took the screenshots and then encountered how to get the latest build. So i uninstalled build416 (+ removing folder ".widelands") and installed build 525. I checked the result and because the texts are still misbehaving, i didn't want to take the same screenshots again. I could try to uninstall this version again and check for remaining folders if you want me to do so.

This was the first install of widelands on this windows system. Oh, and its win7 here.

[Tino (tino79)]

Sorry, took me a bit to long to write the last message. The log shows the version you've downloaded...

Have you checked your Windows Optional Updates if there are any Driver Updates available for your graphics card? Or the support pages from your hardware provider if you have a laptop?

Perhaps SirVer can interpret the logfile in more detail...

[SirVer (sirver)]

The logfile shows no errors :( - it seems like everything is smooth sailing, just the outputs are broken.

What is peculiar is that the driver reports opengl 3 instead of 2. I wonder if I should try a port to OpenGL 3 Core and see if that fixes the issue.

[kaputtnik (franku)]

The graphics card used by wl-zocker and here on this computer is Intel. Has anyone an Intel card which works correct?

[SirVer (sirver)]

I ported our code to OpenGL 3.2 real quick. My hunch is that this is better supported on newer cards than the legacy 2.1 and maybe has less bugs. Once appveyor builds this branch, could you test again?

https://code.launchpad.net/~widelands-dev/widelands/opengl3/+merge/285967

[Tino (tino79)]

I've already built it: http://widelands.8-schuss.de/

But on my system Widelands stays completely black. It does run, i can click in the main menu according to the log, but nothing is drawn.

Btw, i've also an Intel Chipset (Intel HD 4400):
selected language: en
Graphics: Try to set Videomode 800x600
Graphics: OpenGL: Version "3.2.0 - Build 10.18.14.4139"
[snip]
Graphics: OpenGL: Double buffering enabled
Graphics: OpenGL: Max texture size: 16384
Graphics: OpenGL: ShadingLanguage: "1.50 - Build 10.18.14.4139"
**** GRAPHICS REPORT ****
 VIDEO DRIVER windows
 pixel fmt 370546692
 size 800 600
**** END GRAPHICS REPORT ****

[kaputtnik (franku)]

This Laptop is a Dell Vostro 3550 with Intel and AMD graphic. The AMD graphic could not be activated though (no option in bios or in graphic settings of the Intel driver). I tried to use an original AMD driver provided by an "AMD automatic driver update utility" , but this broke the whole graphics :-D

Yes, i will test that, but i use this laptop only at weekends.

[SirVer (sirver)]

Tino, can you provide the --debug_gl_trace=true output?

[Tino (tino79)]

I am not sure if this helps, because the 32bit glbinding build is behaving fine.
My 64bit-glew-build does show the black screen.

I'll try 64bit-glbinding next...

[Tino (tino79)]

The other log.

[Tino (tino79)]

Logfile 64bit glbinding => working

So, either it is a glew vs. glbinding problem, or something with my different build environments (msys2 vs nuwens) ...

[Tino (tino79)]

Ok, last one: 64bit glew with the compiler from last message: black screen

So the port to OpenGL 3 works with glbindings, but not with glew.
I've removed the download from my page, we have to wait for the appveyor builds with glbinding.

[kaputtnik (franku)]

Some examples with the last installation.

The help shows on the left always the faulty things, on the right it looks good.
At the bottom you see one objective window of the first tutorial.

[GunChleoc (gunchleoc)]

Thanks for testing again!

I went through all the screenshots and the problem lies with the new font renderer somewhere - texts rendered with the old font renderer are fine.

[GunChleoc (gunchleoc)]

I can reproduce this on Windows 10 now, but not on Windows 7 (on the same machine).

[kaputtnik (franku)]

Hopefully you find whats going wrong :-) Thanks a lot for investigating!

[GunChleoc (gunchleoc)]

Struck gold on first try - if I deactivate the font cache, everything's fine. Now I have to find out why...

[kaputtnik (franku)]

Some other things i have noticed (i use the term "Stringsign" here for strings which are replaced with other fragments of texts or images):

1. The stringsigns do not change f.e. if one starts the editor and close it again, the stringsigns of the mainmenu are the same as before.
2. Editing text boxes (f.e. in map options) i have noticed the following:
  - Pressing always the same Character the printing on the screen isn't always the same. Normally i would expect that pressing the same button would lead into printing the same stringsign.
  - While pressing always the same character the whole stringsign changes.
  - when hitting backspace the same stringsign appears as it was before entering the last character. Deleting the whole stringsign and repeat it again, on each character input the same stringsign appears as before. F.e. Entering "aaa" gives a specific stringsign, then deleting "aaa" and write "aaa" again gives the same stringsign as writing "aaa" the first time.
  - Sometimes the previous entered characters appears when the characters are deleted (with backspace) and other characters are entered. F.e writing "abcd", deleting this and writing "efg" the characters "abc" appear.

I just write this in hope that this will bring up an idea what is wrong. If i should make a video or other tests, please ask :-)

[GunChleoc (gunchleoc)]

2. hints that the cached text textures are stable now, so the remaining bug shouldn't be in the cache. The changing results for the same character hint at garbage pointers somewhere.

[kaputtnik (franku)]

Because bunnybot was too slow the tests of the two branches have to wait until next weekend... i am not at the buggy maschine during the week.

Maybe wl-zocker could test?

[wl-zocker (wl-zocker)]

I've tried out the testfix branch, but I still get the texture atlas bug.

[kaputtnik (franku)]

Good to see that you are still here :-)

[wl-zocker (wl-zocker)]

Actually, I am not. Since I cannot play Widelands since I reported those bugs, I lost interest in it. However, I am still subsribed to said bugs and I hope to see them fixed eventually. Maybe I'll return then :)

[Miroslav Remák (miroslavr256)]

On my Windows 7 VM (using VirtualBox):
 - AppVeyor builds show massive texture corruption, which is not limited to just texts.
 - Tino's daily builds crash in GLEW after calling glGenFramebuffers. A black screen shows up and Widelands crashes immediately.
 - My own cross builds (using MXE -- http://mxe.cc/) show the same behavior as Tino's builds. They use GLEW as well. However, I've managed to fix the crashes by using the EXT variants of framebuffer functions. These builds do not show any signs of texture corruption.

@wl-zocker:
I'm not sure if my issues are related to this bug in any way, but could you try the attached build? It doesn't come with a fancy installer or Widelands data, so you'll need to extract it into an existing installation directory. Alternatively, you can extract it wherever you want and run widelands.exe --datadir="C:\widelands_install_dir\data" from command line.

[Miroslav Remák (miroslavr256)]

Version of the above build is bzr7978 + this patch.

[wl-zocker (wl-zocker)]

#81: I doesn't help, it still looks similar to the screenshot in #1 (except that I cannot read "Collector"/"Sammler" in the objective window).

[kaputtnik (franku)]

Is there something to test while i am on the buggy machine until Monday morning?

[GunChleoc (gunchleoc)]

We have this:

https://ci.appveyor.com/project/widelands-dev/widelands/build/_widelands_dev_widelands_bug_1535732_fun_with_pointers-890

But I don't expect it to make any difference now. Testing can't hurt though if you have the time.

[Miroslav Remák (miroslavr256)]

And also this:
https://ci.appveyor.com/project/widelands-dev/widelands/build/_widelands_dev_widelands_bug_1535732_testfix-889

[kaputtnik (franku)]

Both do not work :-(

All the same: Texts are replaced with fragments of images or other texts. But i did not investigated a lot, just started the game and opened some menus.

[GunChleoc (gunchleoc)]

*headdesk* thanks for testing again.

[SirVer (sirver)]

I spend some time looking into this bug today - I ran a full game with a lot of AI under ASAN[1]. It did not report a single error - so I doubt that we use a dangling pointer or have use after free anywhere here. We could still use uninitialized memory - I think that is the likely problem. Unfortunately MSAN is much harder to get up and running.

I read through the code again and have another hunch: Could it be related to text with shadows? At [2] we do some special handling of texts with a shadow background - we render the text twice and overlay it in a new surface. And I am not sure if we do that correctly. It also has a comment that says we could do better with SDL2 - I did not investigate this yet.

For now, I temporarily disabled rendering with shadows in r8055 - could somebody with a buggy machine test again and report back?

[1] https://github.com/google/sanitizers/wiki/AddressSanitizer
[2] http://bazaar.launchpad.net/~widelands-dev/widelands/trunk/view/8054/src/graphic/text/sdl_ttf_font.cc#L83

[kaputtnik (franku)]

Was it intended to put your changes directly to trunk?

I couldn't test this because trunk gives no appveyor build for installing on windows. Or have i overlooked something?

[kaputtnik (franku)]

Sorry, i have found it :-)

[SirVer (sirver)]

Yes, it was intended. Trunk is farther distributed and the patch was trivial and does not affect gameplay in a major way - so I considered it acceptable risk to put it into trunk directly.

The appveyor link is here:
https://ci.appveyor.com/project/widelands-dev/widelands/build/master-1089

[kaputtnik (franku)]

I tried that build, but the result is the same: Strings are replaced with other kind of images on buttons, tips in load screens, hoover bubbles, lists and so on :-(

[SirVer (sirver)]

:( Was anybody able to reproduce this in a virtual machine? I require a way to stably reproduce this to fix it.

[kaputtnik (franku)]

Isn't it possible to deactivate all things which could cause this and activate them part by part to find the module/part of code which fail?

SirVer: I could maybe give you my faulty win7 laptop... but it's windows... and i have to ask my girl friend first.

[SirVer (sirver)]

> Isn't it possible to deactivate all things which could cause this and activate them part by part to find the module/part of code which fail?

I would not know where to start there. If I do not have a faulty machine, I do not know what to disable.

> SirVer: I could maybe give you my faulty win7 laptop... but it's windows... and i have to ask my girl friend first.

Could you get me the exact model number and os version? Maybe I could ebay such a device then. But the bigger problem is that I'd require a build environment under windows, and I have no experience setting this up - this would certainly require more than a weekend. If we'd had a faulty linux system that I could try to replicate, it might go easier.

[kaputtnik (franku)]

Laptop: Dell Vostro 3550 N-Series, core i5 with integrated Intel graphics. It has also an AMD discrete graphic, but this couldn't be activated. The original HD is replaced with a SSD-Harddrive.

OS: Windows 7 (don't know any revision number) and arch-linux (no problems with the linux graphics)

[SirVer (sirver)]

mmh, I only found this laptop as new for ~500€. I was hoping I could get one for cheaper on ebay, but no luck it seems.

[SirVer (sirver)]

janus tested this with this laptop: http://www.dell.com/de/unternehmen/p/latitude-e5250-laptop/pd?oc=ca012le5250bemea with windows 10 and an intel GPU and widelands was running just fine - no issues. Not closer to the source of the problem with this.

[SirVer (sirver)]

I found it!!!!

Thanks to kaputtnik and his girlfriend who borrowed me their laptop that showed the issue - and kaputtnik preparing everything for me, so that I did not need to figure out compiling under windows.

It was still quite the hunt: Using glIntercept to figure out what is wrong in OpenGL calls made the issue go away. Digging through the source code of glIntercept to figure out what the difference beween using and not using glIntercept is put me on the idea that maybe the framebuffer are switched too early - before the pipeline is flushed. And indeed, that is the case!

My understanding is that this is a bug in the Intel OpenGL implementation - the flush should happen, but it does not. So we now have to pay the price of an extra flush - quite an expensive operation, but what can you do?

[kaputtnik (franku)]

Great :-)

[Tino (tino79)]

Nice catch!

So, does the additional flushing decrease performance, e.g. lower framerates?

If yes, I am for adding a new parameter (like widelands --intel_compat) which enables the flushing.

It is no general Intel/OpenGL problem, I was never able to reproduce it on several machines with different operating systems and Intel graphics hardware.
So a documented switch for enabling this workaround seems a good alternative to decrease performance (you could see it as regression for other users ;) ) in general.

If it decreases performance...

[kaputtnik (franku)]

How is performance best tested? I ran regression_test.py to current trunk (containig the additional flush) and a build before current trunk:

With additional flush:
  Ran 33 tests in 365.810s

Without additional flush:
   Ran 33 tests in 364.381s

But i guess this is not really an indicator how performance get influenced.

[SirVer (sirver)]

@wl-zocker: Could you confirm that this is fixed after r8077?

> So, does the additional flushing decrease performance, e.g. lower framerates?

It should increase CPU usage (but is not noticeable in my case) and could probably lower frame rates if we have a lot to do. I do not think that we will ever notice though: We only switch framebuffers (hence flush) if we do render new text - which we do offscreen and then cache it. So most of the time, we just render to the front buffer using the cached textures.

> If yes, I am for adding a new parameter (like widelands --intel_compat) which enables the flushing.

that is premature - the graphics pipeline is not the bottleneck these days, so adding this flag without definite proof that performance is worse adds complexity without a clear gain.

> How is performance best tested?

For graphics related stuff: make sure no logic happens, i.e. all AI is None. But you should have plenty of objects, also turn on as much text rendering as possible (c+s). Change the maxfps in the options to 200 or so (> 60, which will be the cap for most systems). Run the game and watch CPU usage.

[wl-zocker (wl-zocker)]

I tested r8078 from Tino's site and it is working. Great work and thank you to everyone who contributed his part in solving this bug!

[GunChleoc (gunchleoc)]

Great news, thanks for confirming :)

[GunChleoc (gunchleoc)]

Fixed in build19-rc1.