xpra icon
Bug tracker and wiki

Opened 4 years ago

Closed 3 years ago

Last modified 3 years ago

#968 closed enhancement (fixed)

browser failing to render to actual size

Reported by: pharindranath Owned by: J. Max Mena
Priority: major Milestone: 0.16
Component: client Version: 0.15.x
Keywords: Fedora, browser, rendering, size, xpra Cc:

Description (last modified by Antoine Martin)

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

Change History (33)

Changed 4 years ago by pharindranath

Changed 4 years ago by pharindranath

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

comment:2 Changed 4 years ago by Antoine Martin

Owner: changed from Antoine Martin to pharindranath

@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:

  • when did it start?
  • is it a server-side regression or client-side?
Last edited 4 years ago by Antoine Martin (previous) (diff)

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

Changed 4 years ago by pharindranath

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

comment:5 Changed 4 years ago by Antoine Martin

Description: modified (diff)
Summary: Browser failing to render to actual size when opened through Xpra( Server:0.16.0Rev10306 Client 0.16.0Rev 10306) running on Fedora 21browser failing to render to actual size

(editing crazy long ticket title)

comment:6 Changed 4 years ago by Antoine Martin

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

Changed 4 years ago by pharindranath

Attachment: gl_info.txt added

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

comment:8 Changed 4 years ago by alas

Owner: changed from pharindranath to Antoine Martin

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.

comment:9 Changed 4 years ago by Antoine Martin

Owner: changed from Antoine Martin to pharindranath

@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...

comment:10 Changed 4 years ago by J. Max Mena

Owner: changed from pharindranath to J. Max Mena
Status: newassigned

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.

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

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

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

comment:14 Changed 4 years ago by J. Max Mena

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

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

comment:16 Changed 4 years ago by J. Max Mena

Upped Fedora 21 machine in question to r11146.

  • Updated gl_check.py :
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.

Last edited 4 years ago by J. Max Mena (previous) (diff)

comment:17 Changed 4 years ago by Antoine Martin

Priority: minormajor

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.

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

comment:18 Changed 4 years ago by J. Max Mena

Owner: changed from J. Max Mena to Antoine Martin
Status: assignednew
  • Upped client and server to r11211
  • Still broken
    • Both built from source, and beta package (r11178)(although that one looks too early to include your changes)

of note:

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

Last edited 4 years ago by J. Max Mena (previous) (diff)

comment:19 Changed 4 years ago by Antoine Martin

Owner: changed from Antoine Martin to J. Max Mena

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

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

Last edited 4 years ago by J. Max Mena (previous) (diff)

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

comment:22 Changed 3 years ago by J. Max Mena

Owner: changed from J. Max Mena to Antoine Martin

Ran commands:

  • Proper PyOpenGL (3.1.1a1) is now installed
  • Issue remains

Everything works just fine with --opengl=no.

comment:23 Changed 3 years ago by Antoine Martin

Owner: changed from Antoine Martin to J. Max Mena

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)

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

comment:25 Changed 3 years ago by Antoine Martin

Resolution: fixed
Status: newclosed

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

comment:26 Changed 3 years ago by Antoine Martin

Note: See TracTickets for help on using tickets.