python3 opengl client

[totaam]

Issue migrated from trac ticket # 1569

component: client | priority: major | resolution: worksforme

2017-07-10 06:22:05: antoine created the issue

---

Split from #640. For general python3 issues, see #1568.

See #640#comment:41.

If this can be made to work, maybe it will be more stable than the GTK2 version?

See also: #921 native win32 opengl client

[totaam]

2017-07-20 17:51:26: antoine changed status from new to assigned

[totaam]

2017-07-20 17:51:26: antoine edited the issue description

[totaam]

2017-09-19 17:46:51: antoine uploaded file gtkglx.patch (6.8 KiB)

poc using GLX to wrap the X11 window

[totaam]

2017-09-19 18:07:14: antoine commented

---

Just because GTK3 decided to break every existing GTK opengl application out there does not mean that it should be that way.

Preparatory work removing unneeded dependencies on GTK from the pure opengl code: r16915, r16916, r16917, r16919, r16920, r16921, r16925, r16926, r16927.

The patch above almost works - it paints the screen OK but then the next update comes and messes it up.. It works fine with mmap.
It probably needs xsync to prevent crashes too.
It should be moved to platform code, and the client init code will need to be re-worked.
The code could be made generic enough to be used with both GTK2 and GTK3: the context code only needs a window XID.
Support for win32 and macos should also be possible.
We may then also be able to query the real pixel depth supported on those platforms.

[totaam]

2017-09-21 19:27:12: antoine uploaded file gtkglx-v2.patch (11.8 KiB)

working patch

[totaam]

2017-09-22 07:19:21: antoine commented

---

Support added for opengl with GTK3 in r16948 + r16949, only supported with X11 GLX for now.
It is now enabled by default with Python3 / GTK3.
The same backend can now also be used with GTK2 with X11:

xpra attach --opengl=native

Added bonus: we no longer depend on an unmaintained project.

Still TODO:

• blocker: the client crashes with tray=yes.. the way GTK has been sabotaging the system tray, I'm not sure we're to blame here - it doesn't work well at the best of times. It seems that simply enabling debugging (timing related?) can fix the crash, maybe we just need to xsync after running the gl_check?
• verify high bit depth support, see 10-bit color support in opengl client #1309
• implement win32 and macos native contexts

[totaam]

2017-09-22 20:10:58: antoine commented

---

Fixes and improvements:

• r16949: missed changes to config, man page and cosmetic fixes (+r16953, r16954)
• r16951: GLX improvements and cleanups (+r16958)
• r16952: if all the backends fail, just log a warning and continue without opengl
• r16955: win32 partial implementation (fixes in r16956, r16959, r16960)
• r16957: tell GLX to stop using the context on exit

TODO for win32 port:

• we cannot use the desktop window for running the sanity checks, so we may have to use a temporary (hidden?) window
• present_fbo fails at the point where we reset the target framebuffer, weird
• packaging: package python3 client on win32 #1574

As for macos, it's not very clear how we use opengl on an existing window:

• agl
• OpenGL Programming Guide for Mac
• Deep Image Display with OpenGL: 30-Bit Color is now supported..
• GLFullScreen
• Understanding and Detecting OpenGL Functionality
• packaging: python3 packaging for macos #1575

[totaam]

2017-09-29 14:04:37: antoine commented

---

As of r16993 (ugly workaround found here: How I can get DrawingArea window handle in Gtk3?), opengl works with the python3 builds on win32 (#1574). The present_fbo bug was fixed in r16964.

Still TODO:

• macos: comment:4 and python3 packaging for macos #1575
• sanity checks on win32 via temporary window
• the window handle code should be generalized (see ugly code added in r16993)

[totaam]

2017-09-30 11:56:59: antoine commented

---

The win32 port does work as of r16964, it justs needs some packaging fixes: #1574 / #1528.

[totaam]

2017-10-24 17:10:05: antoine changed status from assigned to new

[totaam]

2017-10-24 17:10:05: antoine changed owner from antoine to maxmylyn

[totaam]

2017-10-24 17:10:05: antoine commented

---

Ready for testing on Linux.

The python3 builds should now work with opengl enabled by default.

[totaam]

2017-11-06 09:00:00: antoine commented

---

Let's try to fix transparency: #1570.

[totaam]

2017-11-11 06:57:59: antoine commented

---

There was a bug with GTK3 on 64-bit MS Windows builds but it looks like a recent GTK update has fixed that too.

[totaam]

2017-11-11 15:13:14: antoine commented

---

r17368 also hooks up the driver probing so session info and OpenGL_check.exe (fixed in r17370) will now show the correct details.

[totaam]

2017-11-12 08:57:13: antoine commented

---

We don't use opengl on win32 if the window uses transparency, see #1570#comment:4 and #1682.

[totaam]

2017-11-29 19:07:33: maxmylyn commented

---

I'll have to set up my mini test box here to use a display (good old Timmeh, he's configured to use packages not build from source) so I can give this a try.

[totaam]

2017-12-02 00:27:20: maxmylyn changed owner from maxmylyn to antoine

[totaam]

2017-12-02 00:27:20: maxmylyn commented

---

NOTE:

Default install of python3-xpra sets the shebang to /usr/bin/python2.

Other than that, it seems to work fine for me - Fedora 26 and the 20171201r17551.fc26 python3-xpra-client running against a trunk r17551 Fedora 26 server. With OpenGL enabled (Nvidia ION "GPU").

[totaam]

2017-12-02 11:48:00: antoine changed status from new to closed

[totaam]

2017-12-02 11:48:00: antoine set resolution to worksforme

[totaam]

2017-12-02 11:48:00: antoine commented

---

Default install of python3-xpra sets the shebang to /usr/bin/python2.
The default shebang belongs in the xpra-common package, because we want to be able to install both python versions simultaneously.

Until the python3 version is made the default, this is how it is going to be. For running the python3 version, you are expected to run:

python3 /bin/xpra ...