xpra icon
Bug tracker and wiki

Opened 4 years ago

Closed 4 years ago

Last modified 3 years ago

#745 closed defect (fixed)

OpenGL issues with Intel 4000 chipset on MS Windows

Reported by: Lukas Haase Owned by: Antoine Martin
Priority: minor Milestone:
Component: client Version: 0.14.x
Keywords: Cc:

Description

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.

Attachments (4)

after.png (23.5 KB) - added by Lukas Haase 4 years ago.
before.png (50.4 KB) - added by Lukas Haase 4 years ago.
session-info-0.14.11-r8096.png (27.4 KB) - added by Lukas Haase 4 years ago.
session-info-0.14.12-r8135.png (27.4 KB) - added by Lukas Haase 4 years ago.

Download all attachments as: .zip

Change History (18)

Changed 4 years ago by Lukas Haase

Attachment: after.png added

Changed 4 years ago by Lukas Haase

Attachment: before.png added

comment:1 Changed 4 years ago by Antoine Martin

Owner: changed from Antoine Martin to Lukas Haase

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?

comment:2 Changed 4 years ago by 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.

comment:3 Changed 4 years ago by 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

comment:4 Changed 4 years ago by Antoine Martin

Owner: changed from Lukas Haase to Antoine Martin
Priority: criticalblocker
Status: newassigned

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?

comment:5 Changed 4 years ago by 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.

Last edited 4 years ago by Lukas Haase (previous) (diff)

Changed 4 years ago by Lukas Haase

Changed 4 years ago by Lukas Haase

comment:6 Changed 4 years ago by 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.

comment:7 Changed 4 years ago by 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.

comment:8 Changed 4 years ago by 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?

comment:9 Changed 4 years ago by Antoine Martin

Priority: blockerminor
Summary: 0.15 OpenGL issuesOpenGL issues with Intel 4000 chipset on MS Windows

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.

Last edited 4 years ago by Antoine Martin (previous) (diff)

comment:10 Changed 4 years ago by 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?

comment:11 Changed 4 years ago by 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..

Last edited 4 years ago by Antoine Martin (previous) (diff)

comment:12 Changed 4 years ago by Antoine Martin

Resolution: fixed
Status: assignedclosed

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.

comment:13 Changed 4 years ago by Antoine Martin

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

comment:14 Changed 3 years ago by Antoine Martin

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

See wiki/ClientRendering/OpenGL

Note: See TracTickets for help on using tickets.