OpenGL issues with Intel 4000 chipset on MS Windows

[totaam]

Issue migrated from trac ticket # 745

component: client | priority: minor | resolution: fixed

2014-11-26 05:28:05: lukashaase created the issue

---

I just tested 0.15 and compared to 0.14 I found some problems with must be related with OpenGL.

When I start applications with xpra (e.g. MATLAB, see before.png) and then switch to a different desktop and back with a desktop manager (VirtuaWin), the window becomes greyed out (see after.png). This did not happen in 0.14.

To my knowledge VirtuaWin has no issues with any applications (and I did not experience any) so I assume there would be other ways to trigger this effect which I just have not found.

As can be seen on after.png, the window still responds and on a click, e.g. displaying a context menu.

I found no way getting the window back except reconnecting the client or turning off OpenGL. Therefore I assume it has something to do with OpenGL.

Also, when I want to re-enable OpenGl it is not possible: The windows flash a couple of times but the OpenGl option stays unticked in the context menu. However, I assume OpenGL is still enabled/disabled. Because in one case, when I repeat the experiment, the same problem occurs (switching desktops making windows disabled) while in the other case it works.
I assume that in the former case OpenGL is enabled while in the latter case it is disabled - although the context menu shows it for disabled in both cases.

There are no messages displayed on the server side while this happens.

[totaam]

2014-11-26 05:28:15: lukashaase uploaded file after.png (23.5 KiB)

[totaam]

2014-11-26 05:28:26: lukashaase uploaded file before.png (50.4 KiB)

[totaam]

2014-11-26 18:11:12: totaam changed owner from antoine to lukashaase

[totaam]

2014-11-26 18:11:12: totaam commented

---

Can you help us narrow it down by trying a few older 0.15.0 beta builds: [http://xpra.org/beta/windows/], to see around which revision this bug was introduced? There was some opengl refactoring done for 0.15, but nothing that should have been able to cause this sort of problem.
Does minimizing the window and showing it again help?
If you start the client with opengl disabled, can you reproduce the problem?

The opengl tray menu option showing as disabled could have been caused by #724. Is this a relatively new thing?

[totaam]

2014-11-26 23:17:38: lukashaase commented

---

Yes, I will do a binary search on these revisions.

For the rest of the questions

1.) No minimizing and showing it again does not help. Also the "Refresh" menu item does not help. Disconnecting and reconnecting again helps

2.) Yes, just tried it, it is reproduceable. If I add to my xpra file:

opengl=yes

the problem occurs. If I add

opengl=no

it seems to work as expected.

3.) Regarding #724: I am not sure. I just tried clicking the tray icon with right click and then selecting with right click (and the same for left click). No change. But I saw that this happens for all items (e.g. Keyboard Sync, Clipboard - but not for the encoding submenu).
Therefore: Yes, this is a new thing at least for 0.15. With 0.14 I routinely changed "Keyboard Sync" option on the fly.

[totaam]

2014-11-26 23:54:50: lukashaase commented

---

Alright, I did some binary search.

First of all, it may be a good idea to split off the menu item bug into a separate ticket.
Because here I can clearly state:
Xpra_Setup_0.15.0-r7928.exe (and probably before): Menu items work as expected
Xpra_Setup_0.15.0-r8044M.exe (and afterwards): Menu issue occurs

Regarding the actual OpenGL problem: Bad news, every single 0.15 seems to be affected (everything I tried in http://xpra.org/beta/windows/) and I even realized the problem started with 0.14. Here I can summarize:

Xpra_Setup.exe (0.14.11-8096): WORKS!
Xpra_Setup.exe (0.14.12-8135): Stopped working

[totaam]

2014-11-27 00:47:31: totaam changed priority from critical to blocker

[totaam]

2014-11-27 00:47:31: totaam changed status from new to assigned

[totaam]

2014-11-27 00:47:31: totaam changed owner from lukashaase to totaam

[totaam]

2014-11-27 00:47:31: totaam commented

---

First of all, it may be a good idea to split off the menu item bug into a separate ticket.
[[BR]]
Yes. I think I will have to re-open #724 once I can reproduce this (once I have access to my win32 environment again)
[[BR]]
Regarding the actual OpenGL problem...
Xpra_Setup.exe (0.14.11-8096): WORKS!
Xpra_Setup.exe (0.14.12-8135): Stopped working
[[BR]]
Ouch!
This looks like #717. I thought we had tested it thoroughly enough - apparently not. Raising to blocker.

I'm not sure how / why virtualwin triggers it.
I would have thought that the zerocopy upload in that code only fired when processing data using specific encodings (webp being one of them it seems), so lossless window refresh could have triggered it, but further window updates should have been done with h264 - which should be unaffected.

Can you reproduce the problem with plain rgb or png?

[totaam]

2014-11-27 01:19:27: lukashaase commented

---

Actually, I just realized that the version that is working (0.14.11-8096) does not have the OpenGL menu entry. As can be seen on

[[Image(session-info-0.14.11-8096.png)]]

for "Client OpenGL" I get "cannot import name memoryview_to_bytes". Does that mean that OpenGL is not enabled and hence, it works?

By contrast, if I now switch to 0.14.12-8135 again, I get the screenshot:

[[Image(session-info-0.14.12-8135.png)]]

OpenGL says now "Double buffering" ... and the problem occurs.

Independently from that, it seems that the problem is unrelated to the codec. And in particular #717 because I never used JPG encoding. I always use plain RGB. I just tried toggling different codecs, the problem stays the same.

[totaam]

2014-11-27 01:19:44: lukashaase uploaded file session-info-0.14.11-r8096.png (27.4 KiB)

[totaam]

2014-11-27 01:19:52: lukashaase uploaded file session-info-0.14.12-r8135.png (27.4 KiB)

[totaam]

2014-11-27 01:29:50: lukashaase commented

---

One more remark: I just ran some OpenGL demos I found at http://magnum.dimajix.de/download/demos.shtml (e.g. gui3dtest-exe-12-28-04.zip, scenetest-exe-02-26-05.zip) so I assume it is no general OpenGL problem.
All of them work as expected. Let me know what else I could test.

[totaam]

2014-11-27 01:43:11: totaam commented

---

OK. Looks like there was a bug in 0.14.11 for win32, this caused opengl to fail to load with the cannot import name memoryview_to_bytes and since things work when we don't use opengl, 0.14.11 works.
Can you try 0.14.10 or earlier? Or even 0.13? Those versions should have a working opengl implementation.
[[BR]]

And in particular #717 because I never used JPG encoding
[[BR]]
That ticket title has been updated to better reflect the real cause of the problem we were seeing.
FYI: even when selecting another encoding, it is possible to end up receiving jpg data. (with h264 and vpx for example, but not with plain rgb)

[[BR]]
I think we may well have found to root cause of the issue though: Intel 4000 strikes again! #563
I think we need to blacklist it for all platforms, or at least win32 and osx.

[totaam]

2014-11-27 01:50:40: lukashaase commented

---

How sad, I tried Xpra_Setup_0.14.10-7980.exe and Xpra_Setup_0.13.0-r6550.exe - both have the same issues. Seems it was just a matter of luck that the bug was in 0.14.11 ...

Any more hope to pinpoint the issues?

[totaam]

2014-11-27 03:01:30: totaam changed priority from blocker to minor

[totaam]

2014-11-27 03:01:30: totaam changed title from 0.15 OpenGL issues to OpenGL issues with Intel 4000 chipset on MS Windows

[totaam]

2014-11-27 03:01:30: totaam commented

---

I'm fairly certain that the problem is with the Intel HD 4000 drivers on those platforms (I have also heard other reports of issues with this chipset on win32), so I have changed the bug title to reflect that, added Intel to the blacklist on MS Windows in r8160 (will backport) and lowered the priority of this ticket. Note: this blacklists all the chipsets, and not just the 4000 - that's because I simply do not have the hardware or the time to figure out which one work and which ones don't.

I actually own an Intel HD 4000:

[    19.663] (--) intel(0): Integrated Graphics Chipset: Intel(R) HD Graphics 4000

But I never run OSX or MS Windows natively anywhere. I guess I could install Windows on this laptop to test, but this would be a long process with very little chance of making progress in the end. Don't hold your breath.

Just to be clear: it is quite possible that the bug is in our code or in the libraries we use, but since this code works fine with all the other drivers and seems to work fine with the same piece of hardware running under Linux or even BSD... until proven otherwise, I blame the drivers.

[totaam]

2014-11-27 03:55:09: lukashaase commented

---

Ok, understand, thanks.
For reference: There are no fundamental disadvantages by just setting opengl=no ? If yes, which?
Maybe it even has advantages? When I think about OpenGL I think about lots of memory, rendering etc. So maybe disabling opengl even saves resources?

[totaam]

2014-11-27 05:25:43: totaam commented

---

opengl is recommended, more info here: ClientRendering OpenGL.
The non-opengl fallback should work, but it gets less testing, it will be slower (and may cause the server to send screen updates more slowly as a result), use more cpu, etc..

[totaam]

2014-12-04 17:26:57: totaam changed status from assigned to closed

[totaam]

2014-12-04 17:26:57: totaam changed resolution from ** to fixed

[totaam]

2014-12-04 17:26:57: totaam commented

---

Backport to v0.14.x is in 8168.

I am fairly confident this is the "correct" fix so closing this ticket, feel free to re-open if the next stable update still has issues for you.

[totaam]

2015-05-10 13:00:15: antoine commented

---

See #818#comment:10 - let's see how re-enabling opengl works out. (for 0.16)

[totaam]

2015-12-16 03:39:31: antoine commented

---

Intel drivers are greylisted again in 0.16.x, too many issues.

See ClientRendering OpenGL