Xpra: Ticket #968: browser failing to render to actual size

When google chrome was being opened through Xpra running in Fedora 21, I observed that the size of the browser was not rendering to actual size.

Details: Server: OS : Linux

Fedora 21 Twenty One

Xpra 0.16.0 Revision r10306

Client: OS: Linux

Fedora 21 Twenty One

Xpra 0.16.0 Revision r10306



Thu, 27 Aug 2015 19:47:05 GMT - pharindranath: attachment set


Thu, 27 Aug 2015 19:47:21 GMT - pharindranath: attachment set


Thu, 27 Aug 2015 19:52:24 GMT - pharindranath: attachment set


Fri, 28 Aug 2015 00:56:23 GMT - pharindranath:

Attaching -d window server and client logs

Fedora21_S0.16.0Rev10306_C0.16.0Rev10306_DebugCode_window_resize(Ref:ticket_#968)-serverLogs Fedora21_S0.16.0Rev10306_C0.16.0Rev10306_DebugCode_window_resize(Ref:ticket_#968)-clientLogs


Fri, 28 Aug 2015 00:56:59 GMT - pharindranath: attachment set


Fri, 28 Aug 2015 00:57:50 GMT - pharindranath: attachment set


Fri, 28 Aug 2015 04:38:56 GMT - Antoine Martin: owner changed

@pharindranath: please use plain-text formats for plain-text data. A word processor is not suitable for working with log files.

Is this a regression? If so:


Sat, 29 Aug 2015 00:27:28 GMT - pharindranath:

I tried doing a regression testing by checking for xpra version 0.15.4 r10209 on server side and xpra version 0.15.4 r10209 on client side, but I still faced the same issue.

I am attaching a screen shot for the same as: Fedora21:S0.15.4r10209_C0.15.4r10209.png

when I tried doing the same for earlier versions from 0.15.3 to 0.15.0, it failed to install even after multiple attempts. Hence I was not able to figure out if it worked for the above (0.15.0 and earlier) versions.

I observed the Browser failing to render to actual size when opened through Xpra when I was working on speaker codecs.

This regression is both server-side as well as client side.


Sat, 29 Aug 2015 00:28:09 GMT - pharindranath: attachment set


Sat, 29 Aug 2015 14:24:27 GMT - Antoine Martin:

This regression is both server-side as well as client side.


No, that's very very unlikely. We don't even know if it is a regression at this point.

It would be very helpful to know if this is a regression at all, and seeing that 0.15.x is also affected, it might not be. Please try 0.14.x clients with 0.15.x or trunk servers and vice versa.


Sun, 30 Aug 2015 10:14:42 GMT - Antoine Martin: description, summary changed

(editing crazy long ticket title)


Tue, 01 Sep 2015 09:00:30 GMT - Antoine Martin:

@pharindranath: as per comment:2, please attach usable plain-text attachments.


Wed, 02 Sep 2015 19:48:57 GMT - pharindranath: attachment set


Thu, 03 Sep 2015 09:30:40 GMT - Antoine Martin:

@pharindranath: still missing the logs in a usable format.

Does this also occur with / without opengl enabled? If not, please post glxinfo, xdpyinfo and maybe also the client's Xorg log file.


Wed, 28 Oct 2015 21:56:12 GMT - alas: owner changed

Sorry for the delay.

No, the issue wasn't happening with opengl disabled.

That being the case, maxmylyn did some digging and found that, by installing a different (working) opengl driver, the issue went away completely.

A quick inventory of some of our Fedora 21 opengl shows that (wait for it...) Intel graphics cards with Mesa drivers (3.0 Mesa 10.3.3 & 3.0 Mesa 10.4.7) cause this issue when opengl is enabled, but installing a 4.5.0 NVIDIA 352.55 opengl driver (on a machine with an nvidia video card) solves the issue.

We haven't tried to find Intel drivers that might fix the issue... but considering Intel's opengl track record (thinking here of osx blacklists), we are putting that rabbit hole off for now.

I'll pass this back to you to decide if you still want any logs, or if you want to just put this off - or pass it back if you need full glxinfo in order to set up yet another Intel opengl blacklist.


Thu, 29 Oct 2015 04:32:29 GMT - Antoine Martin: owner changed

@pharindranath: sounds like we need to blacklist the intel driver again, at the very least on Linux (but maybe also other platforms?)

That being the case, maxmylyn did some digging and found that, by installing a different (working) opengl driver, the issue went away completely.


What was the version before and after so we can distinguish them? Where did you get the drivers from?

Maybe we should gather a list of the platforms and versions which cause problems. I have a laptop with "Mesa DRI", opengl 3.0 and no such problems...


Fri, 30 Oct 2015 17:33:30 GMT - J. Max Mena: owner, status changed

What was the version before and after so we can distinguish them?


The machine that has this issue returns the following from gl_check.py:

OpenGL properties:
* GLU extensions           : GLU_EXT_nurbs_tessellator GLU_EXT_object_space_tess
* GLU version              : 1.3
* display_mode             : ALPHA, SINGLE
* gdkgl.version            : 1.4
* gdkglext.version         : 1.2.0
* gtkglext.version         : 1.2.0
* has_alpha                : True
* max-viewport-dims        : (16384, 16384)
* opengl                   : 3.0
* pygdkglext.version       : 1.1.0
* pyopengl                 : 3.1.0
* renderer                 : Mesa DRI Intel(R) Haswell Desktop
* rgba                     : True
* safe                     : True
* shading language version : 1.30
* texture-size-limit       : 4096
* vendor                   : Intel Open Source Technology Center
* zerocopy                 : True

It says that OpenGl? is working, but it most definitely is not. I'll wander over to the machine with the working OpenGL drivers (Nvidia) and give you that info...and then later today if I get some working Intel drivers on here, I'll give you the working driver info...but I don't have much hope of accomplishing that today between the other tickets that need commenting here, and the fact that I have to leave early today to attend my sister's wedding.


Fri, 30 Oct 2015 17:39:16 GMT - J. Max Mena:

Output on the working machine (nvidia drivers):

OpenGL properties:
* GLU extensions           : GLU_EXT_nurbs_tessellator GLU_EXT_object_space_tess
* GLU version              : 1.3
* display_mode             : ALPHA, SINGLE
* gdkgl.version            : 1.4
* gdkglext.version         : 1.2.0
* gtkglext.version         : 1.2.0
* has_alpha                : True
* max-viewport-dims        : (16384, 16384)
* opengl                   : 4.5
* pygdkglext.version       : 1.1.0
* pyopengl                 : 3.1.0
* renderer                 : GeForce GTX 745/PCIe/SSE2
* rgba                     : True
* safe                     : True
* shading language version : 4.50 NVIDIA
* texture-size-limit       : 16384
* vendor                   : NVIDIA Corporation
* zerocopy                 : True

Fri, 30 Oct 2015 17:50:40 GMT - J. Max Mena:

Update:

According to this https://ask.fedoraproject.org/en/question/67862/intel-drivers-fedora-21/ thread, the Mesa driver is the 'main' Intel Chipset driver for Fedora 21....and after more research (googling), it appears that the proprietary Intel drivers are no longer available.


Review:

Not working: Intel Mesa drivers

Working: Proprietary Nvidia Drivers

Probably working, but unable to test here: Proprietary AMD drivers.

Worth Mentioning: Mesa Nvidia Drivers won't even launch Xpra with OpenGL enabled, Xpra fatally crashes with an OpenGL error. (at least that's what happened on my two very different Nvidia machines)


Mon, 02 Nov 2015 07:42:06 GMT - Antoine Martin:

@maxmylyn: please provide the gl_check.py output for those systems so we can try to blacklist them by version - the Intel Mesa drivers work OK here with Fedora 22 on an Intel laptop.


Tue, 03 Nov 2015 20:11:38 GMT - J. Max Mena:

@Antoine: gl_check.py output from the buggered machine (Fedora 21) is in comment:10


Wed, 04 Nov 2015 03:50:13 GMT - Antoine Martin:

I have a laptop with an almost identical card, only "Ivybridge" instead of "Haswell" and this has worked fine since Fedora ?18? or earlier... so I cannot blacklist based on this info alone.

Can you try with r11123 + r11124, which will include slightly more information in the gl_check output and also post:

rpm -qa | grep PyOpenGL

(we don't need to worry about nvidia cards and AMD was also working fine last time I tried, problems only seem to occur with Intel..)


Fri, 06 Nov 2015 18:21:56 GMT - J. Max Mena:

Upped Fedora 21 machine in question to r11146.

OpenGL properties:
* GLU extensions           : GLU_EXT_nurbs_tessellator GLU_EXT_object_space_tess
* GLU version              : 1.3
* accelerate               : 3.1.0
* display_mode             : ALPHA, SINGLE
* gdkgl.version            : 1.4
* gdkglext.version         : 1.2.0
* gtkglext.version         : 1.2.0
* has_alpha                : True
* max-viewport-dims        : (16384, 16384)
* opengl                   : 3.0
* pygdkglext.version       : 1.1.0
* pyopengl                 : 3.1.0
* renderer                 : Mesa DRI Intel(R) Haswell Desktop
* rgba                     : True
* safe                     : True
* shading language version : 1.30
* texture-size-limit       : 4096
* transparency             : True
* vendor                   : Intel Open Source Technology Center
* zerocopy                 : True

rpm -qa | grep PyOpenGL:

PyOpenGL-accelerate-3.1.0-2.fc21.x86_64
PyOpenGL-3.1.0final-3.fc21.noarch

I've done some further testing(against a Fedora 21 trunk r11146 Server) and found that different applications will paint properly to different sizes before starting to partially paint. For example, I can render Firefox (entirely before it starts partially painting) in a window noticeably larger than Gedit will allow me.

Before you hit this seemingly arbitrary limit, the application behaves just fine; I can surf around in Firefox, and do my German homework in Gedit seemingly indefinitely without any hiccups, but once you attempt to resize a window too large it only partially paints.


Fri, 13 Nov 2015 11:28:13 GMT - Antoine Martin: priority changed

Wait! I've only just noticed that the versions of PyOpenGL you have do not match: 3.1.0-2.fc21 vs 3.1.0final-3.fc21... (that was caused by the Fedora packaging breaking our packages without warning.. ouch)

I have now forced the lockstep (r11201 + r11202) and rebuilt new beta rpms with this change. Please try updating to those and see if you can still reproduce the problem.


Fri, 13 Nov 2015 17:15:31 GMT - J. Max Mena: owner, status changed

of note:

gl_check.py returns the same information as it did before. Edit: for both built from source and beta package


Sat, 14 Nov 2015 07:16:23 GMT - Antoine Martin: owner changed

Can you please post rpm -qa | grep PyOpenGL to make sure the package versions do match now?


Tue, 17 Nov 2015 19:57:00 GMT - J. Max Mena:

This particular machine is still at the same version (r11178 trunk)

gl_check.py output:

OpenGL properties:
* GLU extensions           : GLU_EXT_nurbs_tessellator GLU_EXT_object_space_tess
* GLU version              : 1.3
* accelerate               : 3.1.0
* display_mode             : ALPHA, SINGLE
* gdkgl.version            : 1.4
* gdkglext.version         : 1.2.0
* gtkglext.version         : 1.2.0
* has_alpha                : True
* max-viewport-dims        : (16384, 16384)
* opengl                   : 3.0
* pygdkglext.version       : 1.1.0
* pyopengl                 : 3.1.0
* renderer                 : Mesa DRI Intel(R) Haswell Desktop
* rgba                     : True
* safe                     : True
* shading language version : 1.30
* texture-size-limit       : 4096
* transparency             : True
* vendor                   : Intel Open Source Technology Center
* zerocopy                 : True

rpm -qa | grep PyOpenGL:

PyOpenGL-accelerate-3.1.0-2.fc21.x86_64
PyOpenGL-3.1.0final-3.fc21.noarch

Looks like they're matching, or not?


Wed, 18 Nov 2015 01:25:57 GMT - Antoine Martin:

I'm trying to figure out why yum / dnf don't use the 3.1.1a1 update which is in the repo. In the meantime, please try:

yum remove PyOpenGL-accelerate PyOpenGL
yum install PyOpenGL

I assume turning opengl off fixes the problems?

I really wished Fedora packaging hadn't created such a bad conflict..


Tue, 01 Dec 2015 20:57:17 GMT - J. Max Mena: owner changed

Ran commands:


Everything works just fine with --opengl=no.


Wed, 02 Dec 2015 02:14:05 GMT - Antoine Martin: owner changed

As of r11321 trunk has Intel Open Source Technology Center vendor greylisted, so opengl should not be enabled by default on those cards.

@maxmylyn: Doesn't that make the client run without opengl by default on your system? (this would need to be backported)


Thu, 03 Dec 2015 17:55:28 GMT - J. Max Mena:

@antoine: yes, it does run with opengl off by default, as I had to manually turn it back on. With opengl off, everything runs properly.


Sat, 05 Dec 2015 10:54:31 GMT - Antoine Martin: status changed; resolution set

Closing as "fixed" since we now correctly greylist those problematic drivers.


Wed, 16 Dec 2015 03:38:43 GMT - Antoine Martin:

See wiki/ClientRendering/OpenGL


Sat, 23 Jan 2021 05:11:09 GMT - migration script:

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