Windows client painting random window as solid white upon connection

[totaam]

Issue migrated from trac ticket # 1364

component: android | priority: major | resolution: fixed

2016-11-18 21:17:50: maxmylyn created the issue

---

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.

[totaam]

2016-11-18 21:19:34: maxmylyn uploaded file 1364_d_openglpaint.txt (48.1 KiB)

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

[totaam]

2016-11-18 21:20:07: maxmylyn uploaded file 1364_d_all.txt (499.4 KiB)

Same steps, with -d all

[totaam]

2016-11-18 21:21:05: maxmylyn uploaded file 1364_d_openglpaint_noopengl.txt (24.2 KiB)

Same steps, opengl off - solid white on Firefox

[totaam]

2016-11-18 21:22:56: maxmylyn uploaded file 1364xprainfo.txt (191.7 KiB)

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

[totaam]

2016-11-18 21:45:46: maxmylyn commented

---

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 = ()
)

[totaam]

2016-11-19 12:48:44: antoine changed owner from antoine to maxmylyn

[totaam]

2016-11-19 12:48:44: antoine commented

---

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

[totaam]

2016-11-21 19:46:32: maxmylyn commented

---

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.

[[br]]

Do you have steps? Is it reliable?

[[br]]

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.

[totaam]

2016-11-22 17:29:18: maxmylyn changed status from new to closed

[totaam]

2016-11-22 17:29:18: maxmylyn set resolution to fixed

[totaam]

2016-11-22 17:29:18: maxmylyn commented

---

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