Xpra: Ticket #745: OpenGL issues with Intel 4000 chipset on MS Windows

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.



Wed, 26 Nov 2014 05:28:14 GMT - Lukas Haase: attachment set


Wed, 26 Nov 2014 05:28:26 GMT - Lukas Haase: attachment set


Wed, 26 Nov 2014 18:11:12 GMT - Antoine Martin: owner changed

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?


Wed, 26 Nov 2014 23:17:38 GMT - Lukas Haase:

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.


Wed, 26 Nov 2014 23:54:50 GMT - Lukas Haase:

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-r8096): WORKS! Xpra_Setup.exe (0.14.12-r8135): Stopped working


Thu, 27 Nov 2014 00:47:30 GMT - Antoine Martin: owner, priority, status changed

First of all, it may be a good idea to split off the menu item bug into a separate ticket.


Yes. I think I will have to re-open #724 once I can reproduce this (once I have access to my win32 environment again)

Regarding the actual OpenGL problem... Xpra_Setup.exe (0.14.11-r8096): WORKS! Xpra_Setup.exe (0.14.12-r8135): Stopped working


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?


Thu, 27 Nov 2014 01:19:26 GMT - Lukas Haase:

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

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-r8135 again, I get the screenshot:

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.


Thu, 27 Nov 2014 01:19:44 GMT - Lukas Haase: attachment set


Thu, 27 Nov 2014 01:19:51 GMT - Lukas Haase: attachment set


Thu, 27 Nov 2014 01:29:50 GMT - Lukas Haase:

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.


Thu, 27 Nov 2014 01:43:11 GMT - Antoine Martin:

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.

And in particular #717 because I never used JPG encoding


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)


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.


Thu, 27 Nov 2014 01:50:39 GMT - Lukas Haase:

How sad, I tried Xpra_Setup_0.14.10-r7980.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?


Thu, 27 Nov 2014 03:01:30 GMT - Antoine Martin: priority, summary changed

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.


Thu, 27 Nov 2014 03:55:08 GMT - Lukas Haase:

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?


Thu, 27 Nov 2014 05:25:43 GMT - Antoine Martin:

opengl is recommended, more info here: wiki/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..


Thu, 04 Dec 2014 17:26:56 GMT - Antoine Martin: status changed; resolution set

Backport to v0.14.x is in r8168.

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.


Sun, 10 May 2015 12:00:14 GMT - Antoine Martin:

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


Wed, 16 Dec 2015 03:39:30 GMT - Antoine Martin:

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

See wiki/ClientRendering/OpenGL


Sat, 23 Jan 2021 05:04:43 GMT - migration script:

this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/745