xpra icon
Bug tracker and wiki

Opened 3 years ago

Closed 3 years ago

#1364 closed defect (fixed)

Windows client painting random window as solid white upon connection

Reported by: J. Max Mena Owned by: J. Max Mena
Priority: major Milestone: 1.0
Component: android Version: trunk
Keywords: Cc:

Description

So, I'm running the latest r14448 1.0 client against the latest 1.0 server - upon connecting, one of my windows shows up solid white. Using the system tray to specify a refresh causes the issue to clear up. The first two connects is was an Xterm, the third try it was Firefox. This machine runs without OpenGL by default, but forcing it on, I get the same issue, but the window is instead solid black.

I'm attaching a -d all log, since I'm not sure what I'm looking for. -d opengl,paint didn't show any obvious errors. I'll attach that, too anyways in hopes that it has less junk and still has the issue.

Attachments (4)

1364_d_openglpaint.txt (48.1 KB) - added by J. Max Mena 3 years ago.
Connecting with OpenGL on - Window #4 (Firefox) shows up as solid black.
1364_d_all.txt (499.4 KB) - added by J. Max Mena 3 years ago.
Same steps, with -d all
1364_d_openglpaint_noopengl.txt (24.2 KB) - added by J. Max Mena 3 years ago.
Same steps, opengl off - solid white on Firefox
1364xprainfo.txt (191.7 KB) - added by J. Max Mena 3 years ago.
Xpra info with OpenGL on - Firefox still solid black. Firefox is Window 4.

Download all attachments as: .zip

Change History (8)

Changed 3 years ago by J. Max Mena

Attachment: 1364_d_openglpaint.txt added

Connecting with OpenGL on - Window #4 (Firefox) shows up as solid black.

Changed 3 years ago by J. Max Mena

Attachment: 1364_d_all.txt added

Same steps, with -d all

Changed 3 years ago by J. Max Mena

Same steps, opengl off - solid white on Firefox

Changed 3 years ago by J. Max Mena

Attachment: 1364xprainfo.txt added

Xpra info with OpenGL on - Firefox still solid black. Firefox is Window 4.

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

Resizing Firefox causes it to black out, with the following error repeated over and over again:

2016-11-18 13:45:18,326 Warning: failed to clear FBO
2016-11-18 13:45:18,332  GLError( err=1286, baseOperation = glClear )

And a traceback after trying to refresh:

Traceback (most recent call last):
  File "xpra\client\gl\gl_window_backing_base.pyc", line 886, in gl_paint_planar
  File "xpra\client\gl\gl_window_backing_base.pyc", line 966, in render_planar_update
  File "latebind.pyx", line 44, in OpenGL_accelerate.latebind.Curry.__call__ (c:\Users\mcfletch\OpenGL-dev\OpenGL-ctypes
\OpenGL_accelerate\src\latebind.c:1201)
  File "C:\Program Files (x86)\Xpra\library.zip\OpenGL\GL\exceptional.py", line 46, in glEnd
  File "errorchecker.pyx", line 53, in OpenGL_accelerate.errorchecker._ErrorChecker.glCheckError (c:\Users\mcfletch\Open
GL-dev\OpenGL-ctypes\OpenGL_accelerate\src\errorchecker.c:1218)
GLError: GLError(
        err = 1286,
        baseOperation = glEnd,
        cArguments = ()
)
Last edited 3 years ago by J. Max Mena (previous) (diff)

comment:2 Changed 3 years ago by Antoine Martin

Owner: changed from Antoine Martin to J. Max Mena

The default background colour is black for opengl and white for the non opengl case.

This is an opengl chipset:

vendor: Intel
renderer: Intel(R) Iris(TM) Graphics 5100
shading-language-version: 4.20 - Build 10.18.10.3345

Which is greylisted for a good reason: wiki/ClientRendering/OpenGL.

The glclear error belongs here: #1358.


As for the actual lack of paint bug: there are no paint events in the client log. (BTW, it would be a lot easier to parse with just one window in there..)
r14459 adds better debug logging to the client code.
I believe I have seen it before, but I have not been able to reproduce it. Do you have steps? Is it reliable?

In the log, we already see that the window gets created, mapped and later configured. Both map and configure events should have caused the server to send the window contents.
So I took a look at the sharing code added for #41 and I believe r14460 should make this safer, though I can't really explain how this could have been broken..
If you can still reproduce it, please grab:

xpra info | egrep "ui-driver"

There should always be a "ui-driver" and it should be the last client that interacted with the window (click or keyboard). In the case where a single client is connected, ui-driver should remain True for the duration of the session.

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

As for the Greylisted iGPU:

Yeah, I'm aware that it's greylisted - although I've been lucky so far and it hasn't caused any serious errors so far...at least until Friday..anyways:

Upped client and server to r14467:

That seems to have made my issue go away - I've started my server up the same xpra start :13 --start-new-commands --no-daemon --bind-tcp=0.0.0.0:2200 --start-child=xterm, and it's behaving nicely now.


Do you have steps? Is it reliable?


My steps were I had a session going on my Fedora machine, and I moved it to my Windows machine, and upon connecting it just stopped painting the one window. I dunno, it was super easy to run into, but it looks fixed now.


I'll hold on to this ticket for a day or two and see if I can get it again with the improved logging. If not, then I'll close it as it looks fixed.

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

Resolution: fixed
Status: newclosed

Okay, I've played around with this quite a bit and cannot reproduce it anymore. Closing.

Note: See TracTickets for help on using tickets.