#90 closed task (fixed)
python3 and gtk3 support
Reported by: | Antoine Martin | Owned by: | J. Max Mena |
---|---|---|---|
Priority: | major | Milestone: | 0.15 |
Component: | core | Version: | 0.1.0 |
Keywords: | Cc: |
Description
Makes sense to bundle this together since python3 is only really supported with gtk3 and vice versa.
Main work items:
- backwards compatible python3 changes (via 2to3 mostly), most already done in r618, r619, r620, r621 and r622
- python3 strings: changes need testing on python2.5, also need to ensure that calling
encode(..)
anddecode(..)
does not adversely affect performance - for other non-backwards compatible python3 changes, find a way to run 2to3 during build so we can keep a unified source tree in python2 format. (main issue here: catch exception syntax change)
- gtk3 imports have moved and now require annotation to silence pydev lint
- gtk3 methods on
gtk.Window
have changed,client.py
will need to provide wrapper methods:gdk.get_default_root_window().get_pointer()
(removed)gdk.get_default_root_window().get_size()
(removed)gtk.Window.__init__(win, wintype)
(removed: no arg constructor now)window.set_geometry_hints(...)
(signature changed)window.flags()
(removed - must callget_$FLAGNAME
)window.window.set_cursor(..)
(renamed towindow.override_cursor
?)window.window.invalidate_rect
(nowwindow.queue_draw_area
)do_expose_event(event)
is nowdo_draw(context)
window.window.get_geometry
(removed, must now callget_position()
andget_size()
?)- constants have moved
gdk.keymap_get_default
(removed?)gdk.Cursor
can no longer use pixbuf..- ...
- gtk3 removed
GdkPixmap
andGdkImage
, we're supposed to be using cairo butcairo.ImageSurface.create_for_data
is not implemented in pycairo and there are no alternatives (ouch!) - PIL (Python Imaging Library) is not available on python3 (so we can't use that to fix cairo either)
Attachments (10)
Change History (62)
comment:1 Changed 9 years ago by
Status: | new → accepted |
---|
comment:2 Changed 9 years ago by
Some useful links:
- GObject Introspection
- Introspection Porting
- Migrating from GTK+ 2.x to GTK+ 3 (and in particular changes that need to be done at the time of the switch)
- GTK+ 3 Reference Manual
- The Python GTK+ 3 Tutorial
- Converting PIL Image to GTK Pixbuf
- pygi-convert.sh
- Ubuntu app indicators when using PyGObject (grrr)
- Convert PIL Image to Cairo ImageSurface
- PIL and Cairographics / PyCairo
- cairo.ImageSurface.create_for_data
comment:3 Changed 9 years ago by
The patch above "works" in the sense that one can get something on screen with gtk3, but it has a number of important shortcomings:
- problems with the new
StringIO
class, which fails because of a missingfileno()
jpeg
andrgb24
have to be parsed usingPIL
then exported toPNG
to then be loaded by cairo as cairo is incapable of loading anything else (seriously!? gtk devs, this is not an upgrade by a giant leap backwards). Forrgb24
it seems to require an unnecessarily large rowstride (RGBA? according to this answer it uses 32 bit per channel data no matter what) - which we do not control as it is generated by gdk on the server side. This means making png the default and finding a solution for the mmap case: possibly using cairo server side to export with the rowstride expected by cairo on the client? Maybe also moving the draw/expose code to a utility class so we can use the current code on gtk2 and the new horrible mess on gtk3 only.- some re-drawing problems due to coordinates and clipping interfering with each other (shouldn't be too hard to fix)
comment:4 Changed 9 years ago by
r640 makes python3 + gtk3 almost usable by providing two different window backing mechanisms (we keep the old/fast code for gtk2, cairo for gtk3).
But there are still many issues remaining:
- most of the gtk3 function stubs at the top of
client.py
are still missing an actual implementation (no cursors, no keyboard support, etc) display = gdk.display_get_default()
and watching for screen changes has been hacked out with aif not is_gtk3()
guard- the gtk3 version of the tray menu is mostly broken due to api changes: missing icons, about dialog errors, etc
comment:6 Changed 9 years ago by
- r667 fixes
get_modifiers_mask
,set_geometry_hints
andis_flag_set
vsMAPPED
/REALIZED
comment:7 Changed 9 years ago by
There are serious compatibility issues between the new io.StringIO
module and PIL
, r697 reverts back to StringIO.StringIO
in order to fix window icons - this will cause problems when trying to port the server to gtk3/python3.
comment:9 Changed 9 years ago by
Milestone: | 0.4 → future |
---|
comment:10 Changed 8 years ago by
Milestone: | future → 0.11 |
---|---|
Status: | accepted → new |
Worth updating and getting the basics to work properly (keyboard, etc)
And maybe also: transparency, GL, cursors, ..
comment:12 Changed 7 years ago by
Lots of updates, this may be a better option than #300:
- misc fixes: r6205, r6203, r6194, r6192, r6191, r6190, r6208
- py3k string mess: r6189, r6184, r6183, r6181, r6179+r6180, r6178
- build updates: r6188, r6177, r6176 (broke rencode python build on win32 - fixed by r6211), r6210, r6213, r6214, r6215
- refactoring: r6202
- gtk3 x11: r6201, r6200, r6199
- mouse and beep support: r6206, r6207
- re-use new buffer code (see #465): r6198, r6212
- ugly cairo mess: r6197, r6196, r6187, r6186, r6185 (last three are candidates for backports)
- support for icons: r6195
- support for system tray: r6193
It is in a much better shape now, including some keyboard support.
Things that just need more work:
- transparency (should now work on osx and win32 without opengl?)
- window state (fullscreen, etc)
- spinner
- workspaces
- launcher
- session info and about dialog
- clipboard (oh joy)
- sound (gstreamer 1.x)
- osx integration work (..)
Things that won't work out of the box with python3:
- py2exe does not support python3 at all, maybe use cx_freeze (the python documentation claims to be able to generate installers directly, I doubt this will work well enough for our needs but worth a try: distutils builtdist: creating windows installers)
- gtkglext and pygtkglext aren't supported with gtk3... tegtkgl claims to be GTK+ 3.0 OpenGL widget, or maybe this gtkglext port to GTK+ 3 - Note: A git build is included below as part of the
pygobjectwin32
installer.
- python netifaces does not support py3k
MS Windows issues
GTK (what a mess):
- pygobjectwin32 seems to be the place to get everything - the alternative would be to build from source with mingw and jhbuild...
Things that install OK on win32 via installers (preferred):
Things that install OK on win32 via scripts\pip.exe install
or py -3 -m pip install
:
Things that need a C compiler to install on win32. Note: I have used mingw32 as per http://stackoverflow.com/questions/3297254/how-to-use-mingws-gcc-compiler-when-installing-python-package-using-pip instead of Visual Studio 2010 normally used with Python 3.4 because I already have Visual Studio 2008 installed for Python 2.7... for now.
Changed 7 years ago by
Attachment: | netifaces-python3.patch added |
---|
fixes netifaces to build with python3
comment:13 Changed 7 years ago by
Using Porting Extension Modules to Python 3 and Porting Extension Modules To Py3k, it was relatively easy to port netifaces
. Now builds on both Linux and win32 with Python 3.4.
I have sent the patch to the author, who said he was going to look at it. Alternatively, netifaces-merged could be used.
Changed 7 years ago by
Attachment: | win32-build-with-mingw.patch added |
---|
with this patch I can build with python3.4 and mingw
comment:14 Changed 7 years ago by
comment:15 Changed 7 years ago by
Many build updates in r6233, r6236, r6237, r6238, r6239, r6240, r6241, r6242
We can now build all the cython modules properly easily with unmodified build files:
set PYTHON=C:\Python34 set PATH=%PATH%;C:\MinGW\bin set PKG_CONFIG_PATH=C:\MinGW\lib\pkgconfig;C:\MinGW\msys\1.0\local\lib\pkgconfig;C:\MinGW\msys\1.0\lib\pkgconfig win32\MAKE-INSTALLER.BAT /silent
You must build ffmpeg
and libvpx
into the mingw environment to use them via pkg-config
:
./configure (...) --prefix=C:\MinGW make make install
comment:16 Changed 7 years ago by
And... cx freeze (stub added in r6243) is not available for Python 3.4 on win32, it does not build either.
So I will start again from the top with Python 3.3.5 instead.
comment:17 Changed 7 years ago by
Things to install using pygobjectwin32:
gobject-introspection
(replacespygtk
)gst-plugins
gdkglext
gst-plugins-extra
gtk+
pango
gstreamer
gdk-pixbuf
dbus-glib
gtkglext
- Development packages (use defaults)
More build updates in r6245, r6246, r6247, r6248, r6249, r6250, r6251.
Big change in r6252 allows us to build correctly again on all (?) platforms (fixes buffer compilation issues with Visual Studio)
comment:18 Changed 7 years ago by
Lots more build updates up to r6280 means that we now have the ability to build GTK3 / Python3 installers from the same source tree as the regular GTK2 / Python2!
Notes:
- you will get a R6034 error on start (probably a missing DLL, or wrong compiler...) - update: now fixed
- you must use
PNG
encoding (which has native support incairo
), the others crash.. (horrible / inflexible API decisions in cairo) - you probably have to remove
OSSBuild
from%PATH%
and%PYTHONPATH%
(though r6273 means this may no longer be strictly required, still better / safer)
comment:19 Changed 7 years ago by
Many more build updates, cleanups and fixes up to r6290, keyboard support in r6291.
It works well enough in PNG
encoding that you can actually almost use it.
Still TODO:
- the root window size reported by GDK is complete garbage and had to be sanitized at both ends. Maybe use the screen dimensions if the root window is wrong? (this error is visible from the process output:
Gdk-WARNING **: gdkwindow-win32.c:1976: GetClientRect failed: Invalid window handle.
- mouse clicks seem to be off by some margin!
- most pixel encodings (except
PNG
) cause crashes, theRGB
codepath needs fixing - got this with webm:
access violation reading 0x0000000
fromlibc.memcpy
indecode.py
- session info is missing (needs a typedict to parse strings)
- some refactorings may be needed or useful:
- the gtk2 client:
do_get_pixbuf
anddo_get_image
should be moved to gtk util WINDOW_TOPLEVEL
: use type if we have one (a better one thanPOPUP
for OR windows)
- the gtk2 client:
sys.stdout
isNone
when running in GUI mode, causing alert box popups on error (ie: "no mode"). We need to ensure we always have log file redirection, even for early errors, and send the message there- win32 cx_freeze installer is too big: filter out
lib/*
andshare/*
with whitelist (too much cruft) OpenGL
support: big- clipboard and keyboard test tools need porting, will be useful
- enable server win32 builds?
CTRL_C
needs event to exit main loop, force one?- transparency
- launcher
- gstreamer
DLL
s for tortoise are the same, so skip them rather than overwrite?
etc..
comment:20 Changed 7 years ago by
Warning: make sure you remove all references to OSSBuild
installations from your environment before building!
Updates:
- sound works: r6315, r6308, r6306
- display geometry detection works: r6304, r6303
- work on launcher (incomplete): r6305, r6299
CTRL_C
works, sort of, it exits without cleaning up - which is better than hanging: r6302- work on the clipboard tool: r6300
- keyboard tool works: r6299
- accelerators work: r6317
- window location fixed: r6318 (looked like it was a mouse position offset)
etc..
Some useful porting links:
comment:21 Changed 7 years ago by
- cx-freeze version 4.3.3 was released today and does include an installer for python 3.4 this time.
- pywin32 also got updated today, first update in almost 2 years. Definitely worth having.
With r6337, I can now build a python 3.4 version too!
r6347 makes the sound fully supported with gstreamer 1.0
comment:22 Changed 7 years ago by
r6370 reduces the installer size by half (now almost the same as the GTK2 version), removing most of the bits we don't need and adding support code to easily pick and choose which components to include or not.
comment:23 Changed 7 years ago by
With all the changes up to r6379, it should now be usable in png
and jpeg
modes. We still have corrupted pixels in rgb
(and with mmap
), but at least now it should not crash! (webp
is disabled completely in r6377 as it would crash reliably - will fix this later). The csc decoding step has a number of issues (mostly those pedantic py3k string conversions), so h264
and vpx
are not usable yet.
New beta GTK3 build uploaded.
Changed 7 years ago by
Attachment: | cairo-repaint.patch added |
---|
getting cairo to paint rgb pixels with python3 / gi is a nightmare, this almost does it
comment:24 Changed 7 years ago by
Despite a lot of time and effort spent on this, I see no way of painting with cairo without doing a roundtrip via PNG client side, what a waste! (details in r6394)
At least video decoding should now works (just a shame that it ends up doing: video decoding -> CSC -> RGB -> PNG -> cairo!)
I'll try to finish off this horrible mess ASAP, and hope that the OpenGL
rendering will work better.
comment:25 Changed 7 years ago by
Many more refactorings and improvements in r6399.
The cairo backing now works well with both gtk2 (use XPRA_USE_CAIRO_BACKING=1
to activate it) and gtk3. It is interesting that all the backings behave slightly differently when resizing:
- the gtk2 pixmap backing is very slow to resize (multiple expensive copies back and forth between pixbuf and surfaces which use different pixel orders)
- the cairo backing behaves very well (at least for this specific action - forgetting the awful paint codepath for a minute..)
- the GL backing is also slower than it should be (see #478)
- window icons are ignored - no idea why
Remaining issues:
OpenGL
support (so painting the screen won't be so agonizingly slow)- clipboard support
pycrypto
fastmath #373- the win32 cx_freeze installer could be trimmed down further (low priority)
CTRL_C
needs event to exit main loop, force one?- fix transparency with cairo (or just use
OpenGL
) - launcher
- fix webp
- mouse cursors support
- session info statistics are missing, graphs need rewriting using cairo (oh joy)
XSETTINGS
and root property support- packaging: use separate
RPM
s? - add
--max-size
option (see #263 for GTK2) - maybe GTK3 will allow us to deal with grabs and application-modal windows?
comment:26 Changed 7 years ago by
Enough for a first round of testing:
- smo: build from source (most of the info is in comment:12, comment:15 and comment:18)
- afarr: check for crashes and other issues not spotted above (a GTK3 python 3.4 build at r6407 is in the beta area)
comment:28 Changed 7 years ago by
Note: Sustaining support for GTK+3 under Win32 - looks like GTK3 on windows isn't as well supported as we would have hoped..
comment:29 Changed 7 years ago by
For the python extensions:
- install the corresponding version of visual studio, ie: VS2010 for Python 3.4 (it can be installed side by side with VS2008, just install it afterwards)
- ensure that it will be used by placing the following contents into
C:\Python34\Lib\distutils\distutils.cfg
:[build] compiler = msvc
- build
Cython
, then everything else, ie: for pycrypto (without fastmath.. see #373), from a Visual Studio Command Prompt do:CD pycrypto-2.6.1 C:\Python34\Python.exe setup.py build C:\Python34\Python.exe setup.py install
- workaround for numpy: http://bugs.python.org/issue16296
- lz4: does not build with msvc at present (reported here: python-lz4 issue 27), you must replace the existing
extra_compile_args
with something like:["/Ot", "/Wall", "/DLZ4_VERSION=\"r119\""]
- PIL: must be told where to find jpeg, zlib, webp, etc..
Eventually, we may also want to compile all the dlls using msvc rather than a mix of msvc and gcc:
- Building x264 on Windows with Visual Studio
- FFMPEG: Microsoft Visual C++ or Intel C++ Compiler for Windows
- VPX: Building For Windows Using Visual Studio
etc.
comment:30 Changed 7 years ago by
Milestone: | 1.0 → 0.14 |
---|---|
Priority: | minor → major |
Please confirm that you can build a GTK3 version as per the instructions in this ticket then close this against milestone 0.14, the remaining issues are now tracked in #640.
Note: as of r7571 you need the cairo header file (preferably matching the DLL version installed) in C:\pycairo-1.10.0\pycairo\pycairo.h
.
comment:31 Changed 7 years ago by
Note this ticket is only about testing the GTK3 build to make sure that the it runs on real hardware.
I have moved the need for a proper build system to #678.
comment:32 Changed 7 years ago by
Testing the beta 0.15.0-r7639 gtk3-py34 win client (against a fedora 20 0.15.0 r-7543 server, which seems to be running some gtk 2.24.24 - which hopefully isn't a problem?)...
- Running the install and forgetting to uncheck the
Launch Xpra
box which triggers the GUI launcher, I got a fail message (will attach a screen shot).
- Launching from command line, with
--opengl=on
, OpenGL fails with the message:some required OpenGL functions are not available: glActiveTexture, glMultiTexCoord2i
- Forgetting aradtech's warning to use only png or rgb, and launching with auto encoding produces a nearly constantly repeating traceback which may be of interest:
Traceback (most recent call last): File "E:\xpra\trunk\src\xpra\client\window_backing_base.py", line 266, in do_paint_rgb24 File "E:\xpra\trunk\src\xpra\client\gtk_base\cairo_backing_base.py", line 100, in _do_paint_rgb24 File "E:\xpra\trunk\src\xpra\client\gtk3\cairo_backing.py", line 85, in _do_paint_rgb File "cairo_workaround.pyx", line 83, in xpra.client.gtk3.cairo_workaround.set_image_surface_data (xpra/client/gtk3/cairo_workaround.c:1022) AssertionError: pixel buffer is too small for 1170x824 with stride=3520: only 0bytes, expected 2900480 2014-09-17 17:12:36,905 do_paint_rgb24 error Traceback (most recent call last): File "E:\xpra\trunk\src\xpra\client\window_backing_base.py", line 266, in do_paint_rgb24 File "E:\xpra\trunk\src\xpra\client\gtk_base\cairo_backing_base.py", line 100, in _do_paint_rgb24 File "E:\xpra\trunk\src\xpra\client\gtk3\cairo_backing.py", line 85, in _do_paint_rgb File "cairo_workaround.pyx", line 83, in xpra.client.gtk3.cairo_workaround.set_image_surface_data (xpra/client/gtk3/cairo_workaround.c:1022) AssertionError: pixel buffer is too small for 1170x824 with stride=3520: only 0bytes, expected 2900480
... launching with --opengl=on
, in conjunction with either --encoding=png
or --encoding=rgb
, produces the same OpenGL failure message as with default encoding.
- Launching with
--encoding=png
also resulted in a sound error and traceback:2014-09-17 17:19:37,488 Unhandled error while processing a 'sound-data' packet from peer using <bound method XpraClient._process_sound_data of <XpraClient objec t at 0x4127558 (xpra+client+gtk3+client+XpraClient at 0x2a970d0)>> Traceback (most recent call last): File "E:\xpra\trunk\src\xpra\client\client_base.py", line 585, in process_packet File "E:\xpra\trunk\src\xpra\client\ui_client_base.py", line 1623, in _process_sound_data File "E:\xpra\trunk\src\xpra\client\ui_client_base.py", line 1586, in start_sound_sink AssertionError
- Launching with
--encoding=rgb
, aside from the awful performance, something is causing a Gdk-CRITICAL warning (I seem to have stumbled across it while trying to open the windows tray icon, but not reliably enough to reproduce at will, maybe only when the sound delay elapsed time is over 3000 at the time I click?):2014-09-17 17:29:22,162 push-buffer error: <enum GST_FLOW_FLUSHING of type GstFlowReturn> 2014-09-17 17:29:22,166 stopping speaker because of error: push-buffer error: <enum GST_FLOW_FLUSHING of type GstFlowReturn> 2014-09-17 17:30:21,623 re-starting speaker because of overrun (Xpra_cmd.exe:3864): Gdk-CRITICAL **: gdk_device_get_source: assertion 'GDK_IS_DEVICE (device)' failed (Xpra_cmd.exe:3864): Gdk-CRITICAL **: gdk_device_get_source: assertion 'GDK_IS_DEVICE (device)' failed
With the png encoding though, it is functional, if without OpenGL.
Changed 7 years ago by
Attachment: | xpra_beta_gtk3-py34_setup_r7639_gui-launch-fail-message.PNG added |
---|
xpra gtk3 py34 r-7639 gui launcher error message
comment:33 Changed 7 years ago by
Almost forgot to mention, when using a control-c to induce a SIGINT from the client command line, I am seeing an error message saying
This application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information.
There is also a windows application crash message box that opens (will attach another screenshot)... I feel like I saw another ticket related to this, but a semi-cursory search didn't turn any up (and I'm not certain if this is specific to the gtk client builds or not... will test some more when I get a chance).
Changed 7 years ago by
Attachment: | xpra_beta_gtk3-py34_setup_r7639_ctrl-c-crash-message.PNG added |
---|
xpra 0.15.0-r7639 gtk3-py34 client side control-c crash message
comment:34 Changed 7 years ago by
Owner: | changed from Smo to alas |
---|
server, which seems to be running some gtk 2.24.24 - which hopefully isn't a problem?
Not a problem. Those are completely independent.
You can run the client against a server which does not even have GTK at all (assuming you can build such a server, I believe the OSX shadow server is not far off that), and you can run a client without GTK either (the html5 client, the defunct Qt client, the Android clients are all examples of this)
.. the GUI launcher, I got a fail message ..
Known issue: see comment:25
.. OpenGL fails with the message ..
Damn. That's the one I was really interested in.
I think I will just have to bite the bullet and buy some hardware (and run windows on it.. shudder) to be able to test.
Launching with
--encoding=png
also resulted in a sound error and traceback:... instart_sound_sink
Probably not directly related to png encoding, but maybe png just makes it more likely we'll encounter this situation.
It looks like a real bug where we're trying to start receiving sound more than once.
If you can reproduce this one, please file a new ticket for it.
Attaching a full -d sound
log sample would help.
Gdk-CRITICAL **: gdk_device_get_source: assertion 'GDK_IS_DEVICE (device)' failed
Looks like a GTK3 bug fixed upstream: gnome bug 696756.
We'll get the fix for this one when we build a newer GTK3 version.
Almost forgot to mention, when using a control-c to induce a SIGINT..
Known issue. And one that is hard to fix (I haven't found a way yet).
We may just have to live with it, at least for a while. Most users don't use the command line anyway, and those that do get to pick up the pieces.
But really, this ticket is old, and was meant to be tested in the 0.14 milestone.
So, as long as the existing GTK3 0.13 or 0.14 builds run no worse than this one, please close this ticket and we can follow up in #640 and #678.
comment:35 Changed 7 years ago by
Unfortunately, testing with xpra-gtk3-py34_setup_0.14.1-r7376 windows client against the same fedora 20 server, with --opengl=on
and with either --encoding=png
or with no encoding specification, when trying to type into an xterm I can't seem to get any keyboard focus, instead getting the following error messages client-side whenever trying to interact with the xterms:
2014-09-18 17:32:03,185 do_paint_rgb24 error Traceback (most recent call last): File "C:\Python34\lib\site-packages\PIL\ImageFile.py", line 454, in _save AttributeError: '_idat' object has no attribute 'fileno' During handling of the above exception, another exception occurred: Traceback (most recent call last): File "C:\Python34\lib\site-packages\PIL\Image.py", line 426, in _getencoder AttributeError: 'module' object has no attribute 'zip_encoder' During handling of the above exception, another exception occurred: Traceback (most recent call last): File "E:\xpra\tags\v0.14.x\src\Temp\xpra\client\window_backing_base.py", line 283, in do_paint_rgb24 File "E:\xpra\tags\v0.14.x\src\Temp\xpra\client\gtk_base\cairo_backing.py", li ne 145, in _do_paint_rgb24 File "E:\xpra\tags\v0.14.x\src\Temp\xpra\client\gtk_base\cairo_backing.py", li ne 196, in _do_paint_rgb File "C:\Python34\lib\site-packages\PIL\Image.py", line 1663, in save File "C:\Python34\lib\site-packages\PIL\PngImagePlugin.py", line 619, in _save File "C:\Python34\lib\site-packages\PIL\ImageFile.py", line 459, in _save File "C:\Python34\lib\site-packages\PIL\Image.py", line 430, in _getencoder OSError: encoder zip not available
Also, for an added bonus, I get the following error upon connecting:
2014-09-18 17:32:02,628 server: Linux Fedora 20 Heisenbug, Xpra version 0.15.0 ( r7543) 2014-09-18 17:32:02,631 Unhandled error while processing a 'server-event' packet from peer using <bound method XpraClient._process_server_event of <XpraClient o bject at 0x3dc7b70 (xpra+client+gtk3+client+XpraClient at 0x2a690d0)>> Traceback (most recent call last): File "E:\xpra\tags\v0.14.x\src\Temp\xpra\client\client_base.py", line 583, in process_packet File "E:\xpra\tags\v0.14.x\src\Temp\xpra\client\ui_client_base.py", line 1116, in _process_server_event TypeError: sequence item 0: expected str instance, bytes found 2014-09-18 17:32:02,850 Attached to tcp:10.0.32.53:1201 (press Control-C to deta ch)
I can test again with a 0.13 GTK3 client if you'd like, but should I continue to use the 0.15 trunk server or an older version?
comment:37 Changed 7 years ago by
Hmm... I seem to be running into the same problem even with plain RGB.
With:
0.14.1 r7376 windows 7 client (beta Xpra-GTK3-py34_Setup_0.14.1-r7376)
0.15.0 r7543 fedora 20 server
TypeError: sequence item 0: expected str instance, bytes found (..) AttributeError: '_idat' object has no attribute 'fileno' (..) AttributeError: 'module' object has no attribute 'zip_encoder' (..) OSError: encoder zip not available
Full (long and mostly redundant with the same errors repeating) log moved to attachment/ticket/90/pillow-errors.log
The xterms that launch are blacked out and show no cursor - clicking on a blacked-out xterm produces more of the same error.
- Also having nearly the same problems without
--opengl=on
:
More of the same: attachment/ticket/90/pillow-errors2.log
Changed 7 years ago by
Attachment: | pillow-errors2.log added |
---|
replace long quote with attachment - part2
comment:38 Changed 7 years ago by
The reason why you still hit those errors is that you set the main encoding to rgb, but png and jpeg were still enabled and ended up being used, causing the errors.
To force only rgb to be used: --encodings=rgb
(not --encoding
)
Now for the fix (long).
To build pillow from source with the 3 codecs we want on win32, do all this from a VC 2010 shell:
- jpeg: OSError: decoder jpeg not available on Windows - fixes missing jpeg
- zlib (for png):
- uncompress it
cd contrib
cd masmx86
bld_ml32.bat
- edit contrib\vstudio\vc10\zlibvc.sln and only keep the
Release|Win32
line from thepreSolution
GlobalSection
(or you should be able to do the same from the VC gui if you have access it: select 'release' win32 build) - remove all occurrences of
ZLIB_WINAPI;
from thevc10
directory (!) - see http://stackoverflow.com/a/6559315/428751 - run
msbuild contrib\vstudio\vc10\zlibvc.sln
- copy zlib.h and zconf.h to Python34\include
- copy zlibstat.lib to Python34\libs\zlib.lib (yes, you do have to rename the file)
- webp:
- copy webp's include directory to python's include directory as webp (so you end up with Python34\include\webp\encode.h, etc)
- copy webp's libwebp.lib to libs\webp.lib (yes, again, you have to rename the file..)
These instructions are actually "nice" compared to the ones I found researching this.
Ensure that VC is configured as the default compiler for distutils, if not:
- add
-c msvc
to the python distutils build commands, OR: - How to use MinGW's gcc compiler when installing Python package using Pip? (reverse those instructions)
You can now build pillow:
C:\Python34\Python.exe ./setup.py build C:\Python34\Python.exe ./setup.py install
After the build step, it will print a summary. Verify that all 3 codecs are enabled.
Next, verify that you can load images with pillow in each of the 3 formats:
C:\Python34\Python.exe -c "from PIL import Image;print(Image.open('E:\example.jpg')" C:\Python34\Python.exe -c "from PIL import Image;print(Image.open('E:\example.png')" C:\Python34\Python.exe -c "from PIL import Image;print(Image.open('E:\example.webp')"
For the record, we can ignore those warnings:
gdk_device_get_source : assertion `GDK_IS_DEVICE(source)` failed
which are already fixed upstream: https://bugzilla.gnome.org/show_bug.cgi?id=696756
comment:39 Changed 7 years ago by
Testing again with same client (with windows 8.1 client w/4K monitor), with encodings=rgb
& --opengl=on
, playback seems to be pretty good... until I tried to test fullscreen on a 4K monitor. (I guess I shouldn't be too surprised.) The session locked half rendered and had to be quit, but behaved well up until I went crazy with a fullscreen command.
- Upon starting
firefox
from an xterm, I did see the following client-side output:
Traceback (most recent call last): File "E:\xpra\trunk\src\xpra\client\ui_client_base.py", line 1942, in _process _window_icon File "E:\xpra\trunk\src\xpra\client\gtk_base\gtk_client_window_base.py", line 527, in update_icon File "E:\xpra\trunk\src\xpra\gtk_common\gtk_util.py", line 401, in get_pixbuf_ from_data TypeError: cannot use a str to initialize an array with typecode 'B'
Testing with the latest beta (0.15.0 r7856) I got the following client-side output upon starting a chrome window from an xterm:
(Xpra_cmd.exe:5740): GdkGLExt-WARNING **: wglMakeCurrent() failed 2014-10-07 16:02:53,326 gtk3.GLWindowBacking(3, (2560, 1378), YUV444P).gl_paint_ planar(..) error: Traceback (most recent call last): File "E:\xpra\trunk\src\xpra\client\gl\gl_window_backing_base.py", line 593, i n gl_paint_planar File "E:\xpra\trunk\src\xpra\client\gl\gtk_compat.py", line 48, in __enter__ AssertionError 2014-10-07 16:02:53,408 gtk3.GLWindowBacking(3, (2560, 1378), YUV444P).gl_paint_ planar(..) error: argument 2: <class 'TypeError'>: wrong type Traceback (most recent call last): File "E:\xpra\trunk\src\xpra\client\gl\gl_window_backing_base.py", line 603, i n gl_paint_planar File "E:\xpra\trunk\src\xpra\client\gl\gl_window_backing_base.py", line 672, i n render_planar_update ctypes.ArgumentError: argument 2: <class 'TypeError'>: wrong type (Xpra_cmd.exe:5740): GdkGLExt-WARNING **: wglMakeCurrent() failed 2014-10-07 16:02:53,494 gtk3.GLWindowBacking(3, (2560, 1378), YUV444P).gl_paint_ planar(..) error: Traceback (most recent call last): File "E:\xpra\trunk\src\xpra\client\gl\gl_window_backing_base.py", line 593, i n gl_paint_planar File "E:\xpra\trunk\src\xpra\client\gl\gtk_compat.py", line 48, in __enter__ AssertionError 2014-10-07 16:02:53,498 do_paint_rgb24 error Traceback (most recent call last): File "E:\xpra\trunk\src\xpra\client\window_backing_base.py", line 266, in do_p aint_rgb24 File "E:\xpra\trunk\src\xpra\client\gl\gl_window_backing_base.py", line 478, i n _do_paint_rgb24 File "E:\xpra\trunk\src\xpra\client\gl\gl_window_backing_base.py", line 549, i n _do_paint_rgb File "latebind.pyx", line 44, in OpenGL_accelerate.latebind.Curry.__call__ (sr c\latebind.c:1201) File "C:\Program Files (x86)\Xpra\OpenGL\GL\exceptional.py", line 46, in glEnd return baseFunction( ) File "errorchecker.pyx", line 53, in OpenGL_accelerate.errorchecker._ErrorChec ker.glCheckError (src\errorchecker.c:1218) OpenGL.error.GLError: GLError( err = 1282, description = b'invalid operation', baseOperation = glEnd, cArguments = () )
Then, when I tried to navigate to a website from the start screen I got the following over and over:
Traceback (most recent call last): File "E:\xpra\trunk\src\xpra\client\gl\gl_window_backing_base.py", line 595, i n gl_paint_planar File "E:\xpra\trunk\src\xpra\client\gl\gl_window_backing_base.py", line 648, i n update_planar_textures File "latebind.pyx", line 32, in OpenGL_accelerate.latebind.LateBind.__call__ (src\latebind.c:989) File "wrapper.pyx", line 318, in OpenGL_accelerate.wrapper.Wrapper.__call__ (s rc\wrapper.c:6561) File "wrapper.pyx", line 311, in OpenGL_accelerate.wrapper.Wrapper.__call__ (s rc\wrapper.c:6439) File "errorchecker.pyx", line 53, in OpenGL_accelerate.errorchecker._ErrorChec ker.glCheckError (src\errorchecker.c:1218) OpenGL.error.GLError: GLError( err = 1281, description = b'invalid value', baseOperation = glTexSubImage2D, pyArgs = ( GL_TEXTURE_RECTANGLE_ARB, 0, 0, 0, 2560, 1378, GL_LUMINANCE, GL_UNSIGNED_BYTE, <memory at 0x077ED880>, ), cArgs = ( GL_TEXTURE_RECTANGLE_ARB, 0, 0, 0, 2560, 1378, GL_LUMINANCE, GL_UNSIGNED_BYTE, <memory at 0x077ED880>, ), cArguments = ( GL_TEXTURE_RECTANGLE_ARB, 0, 0, 0, 2560, 1378, GL_LUMINANCE, GL_UNSIGNED_BYTE, <memory at 0x077ED880>, ) )
I don't think we currently have a system to build GTK3 clients, so I'll need betas to test any further.
comment:40 Changed 7 years ago by
- One other note, when disconnecting the GTK3 client, even in the absence of any client/server problems, with a control-c, I'm getting an error pop-up locally (will post screenshot) as well as the following message server-side:
2014-10-07 17:53:39,299 client Protocol(SocketConnection(('10.0.32.53', 1201) -('10.0.11.129', 59823))) has requested disconnection: exit on signal SIGINT 2014-10-07 17:53:39,299 Disconnecting client Protocol(SocketConnection(('10.0.32.53', 1201) - ('10.0.11.129', 59823))): client request 2014-10-07 17:53:39,301 xpra client disconnected. 2014-10-07 17:53:39,307 internal error: read connection SocketConnection(('10.0.32.53', 1201) - ('10.0.11.129', 59823)) reset: [Errno 104] Connection reset by peer
Changed 7 years ago by
Attachment: | GTK3-Xpra-Crash.PNG added |
---|
windows 8.1 local error message pop-up on control-c exit client side
comment:41 Changed 7 years ago by
TypeError: cannot use a str to initialize an array with typecode 'B'
This one I failed to reproduce - which is strange seeing that this looks like the correct fix for it: r7907.
ctypes.ArgumentError: argument 2: <class 'TypeError'>: wrong type
This one should be fixed in r7908. Then I found more instances of this same issue, fixed in r7909.
with a control-c, I'm getting an error pop-up locally
Yes, there are still lots of build problems (causing scary warnings), lack of proper control-C support in GTK3 (for which I have yet to find a suitable workaround), etc..
I have uploaded a new win32 beta build, which works OK with opengl enabled.
I still have to fix the cairo non-opengl fallback case, which seems to get a bit confused about the pixel buffer size: ... only 0 bytes, expected XXXXX
Then there is also the problem that the PyOpenGL
rpm packages for python3 seem to have a problem... spent a lot of time on this, and then found that re-installing using easy_install-3.3
instead of RPM worked fine.
comment:42 Changed 6 years ago by
Owner: | changed from alas to Antoine Martin |
---|
Is there anything new that I should be testing with this? It looks like yes, but I haven't seen any sign of any GTK3 client builds on our end, nor any newer than August 2014 on yours.
comment:43 Changed 6 years ago by
I have uploaded a newer GTK3 beta 0.15 build.
Not sure how much things have regressed since this ticket was updated though - so there just to try out.
Then I tried to fix the 0.14.x branch - with some success (r8662, r8663, r8664, r8665), but ended up making things so much worse: I hit a cx_freeze problem that looked like it might be fixed with an upgrade.. which broke things even more. And downgrading doesn't help either!?
It is now stuck on one of the most unhelpful error message ever invented: DLL load failed: %1 is not a valid win32 application: "%1", wtf? (upstream, just as unhelpful: cx_Freeze bug 28)
What a waste of time.
comment:44 Changed 6 years ago by
Milestone: | 0.14 → 0.15 |
---|---|
Owner: | changed from Antoine Martin to alas |
OK, I hate having to do this, but I give up. Not going to bother with the GTK3 for the 0.14.x branch.
comment:45 Changed 6 years ago by
Hmmm... not pretty.
Tried to test with Xpra-GTK3-py34_Setup_0.15.0-r8663
(windows 8.1) against fedora 20 0.15.0 r8661.
Tried first with no flags, and again with --encodings=rgb
, two xterm start-childs.
In both cases, the application promptly crashed with a windows error dialog box, and the following client-side output:
C:\Program Files (x86)\Xpra>xpra_cmd.exe attach tcp:10.0.32.53:1201 --encodings=rgb 2015-02-23 17:36:10,475 cannot load enc_vpx (vpx encoder): Encoder missing from xpra.codecs.vpx.encoder: currently broken with python3.. 2015-02-23 17:36:10,475 Traceback (most recent call last): File "E:\xpra\trunk\src\xpra\codecs\loader.py", line 40, in codec_import_check File "xpra\codecs\vpx\encoder.pyx", line 478, in xpra.codecs.vpx.encoder.selft est (xpra/codecs/vpx/encoder.c:6083) AssertionError: currently broken with python3.. 2015-02-23 17:36:10,806 xpra client version 0.15.0 2015-02-23 17:36:12,477 OpenGL_accelerate module loaded 2015-02-23 17:36:12,477 Using accelerated ArrayDatatype 2015-02-23 17:36:12,477 OpenGL accelerate missing: numpy_formathandler 2015-02-23 17:36:12,492 Error loading OpenGL support: 2015-02-23 17:36:12,492 'tuple' object has no attribute 'red_float' Traceback (most recent call last): File "E:\xpra\trunk\src\xpra\client\gtk_base\gtk_client_base.py", line 442, in init_opengl File "X:\Python34-x32\lib\importlib\_bootstrap.py", line 2237, in _find_and_load File "X:\Python34-x32\lib\importlib\_bootstrap.py", line 2226, in _find_and_load_unlocked File "X:\Python34-x32\lib\importlib\_bootstrap.py", line 1191, in _load_unlocked File "X:\Python34-x32\lib\importlib\_bootstrap.py", line 1161, in _load_backward_compatible File "E:\xpra\trunk\src\xpra\client\gl\gtk3\gl_client_window.py", line 11, in <module> File "X:\Python34-x32\lib\importlib\_bootstrap.py", line 2237, in _find_and_load File "X:\Python34-x32\lib\importlib\_bootstrap.py", line 2226, in _find_and_load_unlocked File "X:\Python34-x32\lib\importlib\_bootstrap.py", line 1191, in _load_unlocked File "X:\Python34-x32\lib\importlib\_bootstrap.py", line 1161, in _load_backward_compatible File "E:\xpra\trunk\src\xpra\client\gl\gtk3\gl_window_backing.py", line 10, in <module> File "X:\Python34-x32\lib\importlib\_bootstrap.py", line 2237, in _find_and_load File "X:\Python34-x32\lib\importlib\_bootstrap.py", line 2226, in _find_and_load_unlocked File "X:\Python34-x32\lib\importlib\_bootstrap.py", line 1191, in _load_unlocked File "X:\Python34-x32\lib\importlib\_bootstrap.py", line 1161, in _load_backward_compatible File "E:\xpra\trunk\src\xpra\client\gl\gl_window_backing_base.py", line 41, in <module> File "E:\xpra\trunk\src\xpra\client\gl\gl_window_backing_base.py", line 40, in get_fcolor AttributeError: 'tuple' object has no attribute 'red_float' C:\Program Files (x86)\Xpra\library.zip\xpra\gtk_common\gtk_util.py:461: Warning: The property GtkSettings:gtk-menu-images is deprecated and shouldn't be used anymore. It will be removed in a future version. 2015-02-23 17:36:12,713 detected keyboard: layout=us 2015-02-23 17:36:12,713 desktop size is 5120x2160 with 1 screen(s): 2015-02-23 17:36:12,713 '1\WinSta-Default' (1354x571 mm - DPI: 96x96) workarea: 5120x2120 2015-02-23 17:36:12,713 DISPLAY1 3840x2160 at 1280x0 (621x341 mm - DPI: 157x160) workarea: 3840x2120 2015-02-23 17:36:12,713 DISPLAY2 1280x720 (597x336 mm - DPI: 54x54) workarea: 1280x680 2015-02-23 17:36:13,196 enabled remote logging, see server log file for output
... on the plus side, it looks like the remote logging flag wasn't objected to.
comment:46 Changed 6 years ago by
Oh, that's interesting:
cannot load enc_vpx (vpx encoder): Encoder missing from xpra.codecs.vpx.encoder: currently broken with python3..
This one is a known issue, will eventually fix and remove the scary warning.
- this colour error:
File "E:\xpra\trunk\src\xpra\client\gl\gl_window_backing_base.py", line 40, in get_fcolor AttributeError: 'tuple' object has no attribute 'red_float'
That's a bug with the border colour code with the opengl renderer code, only in GTK3, and since I don't have opengl enabled on my test systems... I never saw it. Will fix.
Until then, you can try with opengl disabled to see if you get any further.
comment:47 Changed 6 years ago by
The colour bug is fixed in r8693 (briefly tested with virtualbox by forcing opengl on)
comment:48 Changed 6 years ago by
Retested with the r8890 GTK3 Py34 Win8.1 client against an 14.22 r8936 Fedora 21 server:
- Client complained about no disk in Drive: E?
- The E drive on this computer is the unused SD card slot - no card inserted
- On closing it terminates in "an unusual way" according to the cmd disabled
- Running with
--opengl=yes
and I get a really weird rendering issue. Will attach a screenshot
retesting with a .15.0 (latest) beta build from /beta (we don't have newer Fedora 21 builds yet):
edit:
- Same no disk in drive E ouput
- Client successfully connects, but after getting all the windows it crashes with the following traceback (with and without Opengl enabled)on connecting, but no output when it crashes, just the generic Windows 'Program has stopped working, Microsoft is looking for a fix(heh)'
C:\Program Files (x86)\Xpra>Xpra_cmd.exe attach tcp:10.0.32.137:2200 --opengl=ye s --encodings=webp,png,h264 2015-04-16 15:36:36,261 cannot load enc_vpx (vpx encoder): Encoder missing from xpra.codecs.vpx.encoder: currently broken with python3.. 2015-04-16 15:36:36,261 Traceback (most recent call last): File "E:\xpra\trunk\src\xpra\codecs\loader.py", line 40, in codec_import_check File "xpra\codecs\vpx\encoder.pyx", line 478, in xpra.codecs.vpx.encoder.selft est (xpra/codecs/vpx/encoder.c:6083) AssertionError: currently broken with python3.. 2015-04-16 15:36:38,796 xpra client version 0.15.0 2015-04-16 15:36:39,342 OpenGL_accelerate module loaded 2015-04-16 15:36:39,342 Using accelerated ArrayDatatype 2015-04-16 15:36:39,342 OpenGL accelerate missing: numpy_formathandler C:\Program Files (x86)\Xpra\library.zip\xpra\gtk_common\gtk_util.py:461: Warning : The property GtkSettings:gtk-menu-images is deprecated and shouldn't be used a nymore. It will be removed in a future version. 2015-04-16 15:36:39,499 detected keyboard: layout=us 2015-04-16 15:36:39,499 desktop size is 2560x1080 with 1 screen(s): 2015-04-16 15:36:39,499 '1\WinSta-Default' (677x285 mm - DPI: 96x96) workarea: 2560x1040 2015-04-16 15:36:39,499 DISPLAY1 (670x280 mm - DPI: 97x97) workarea: 2560x10 40 2015-04-16 15:36:39,686 server: Linux Fedora 21 Twenty One, Xpra version 0.15.0 (r8988) 2015-04-16 15:36:39,686 Attached to tcp:10.0.32.137:2200 (press Control-C to det ach)
Changed 6 years ago by
Attachment: | ticket 90 rendering bug.png added |
---|
Rendering bug when connecting to a 14.22 server
comment:49 Changed 6 years ago by
Owner: | changed from alas to Antoine Martin |
---|---|
Status: | new → assigned |
Client complained about no disk in Drive: E?
Something from the build environment must be leaking. I use drive E for the source code.
Some visual corruption would be expected until #465 is properly fixed. We'll have to test again after that.
after getting all the windows it crashes with the following traceback
There is no crash traceback in the output. The vpx one is a startup warning (which we may be able to re-enable already, or after #465 is fixed).
comment:50 Changed 6 years ago by
Owner: | changed from Antoine Martin to J. Max Mena |
---|---|
Status: | assigned → new |
As for the opengl thing, see ticket/640#comment:17.
I have uploaded 3 beta win32 builds of the same svn revision with the fixes from ticket:640#comment:21 and ticket:640#comment:22 :
- standard GTK2 build
- mingw GTK3 build
- msvc GTK3 build
I hope this works well enough (with the caveats in the comments), close this ticket, and follow up in #640.
comment:51 Changed 6 years ago by
Resolution: | → fixed |
---|---|
Status: | new → closed |
Retried with the following builds against an r9087 Fedora 21 server:
MSVC:
- Client connected and gave me my windows (currently starting with Firefox, xterm, xterm), however, I was unable to right click on the tray icon to disconnect
- in addition a CTRL-C to the CMD window started a disconnect but then the client hung, before closing but not exiting completely.
Got the following output from the server:
2015-04-20 11:35:25,311 client Protocol(SocketConnection(('10.0.32.137', 2200) - ('10.0.11.113', 59162))) has requested disconnection: CTRL_C 2015-04-20 11:35:25,311 Disconnecting client Protocol(SocketConnection(('10.0.32.137', 2200) - ('10.0.11.113', 59162))): client request 2015-04-20 11:35:25,328 internal error: read connection SocketConnection(('10.0.32.137', 2200) - ('10.0.11.113', 59162)) reset: [Errno 104] Connection reset by peer
- However, a re-launch(closing the CMD window and opening a new one) with and without OpenGl? works as expected. Must have been a one-time fluke, but I can investigate further if needed
MinGW:
- I get a generic error ("blah" has stopped working, Windows isn't checking to fix it, etc etc) on disconnect every time. Other than that it works as expected.
edit: I see the caveat on #640 now. I'll refrain from posting the obvious and leave this be.
---
- No longer asking about the E: drive.
- Will mention the generic error in #640.
Closing.
comment:52 Changed 3 months ago by
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/90
More done in r626, r627, r628, r629 and r630: most of the code is now python3/gtk3 compatible, except for: