Title is a bit wonky.
The server is a Fedora 23 trunk r11425 server started with:
dbus-launch xpra start :13 --bind-tcp=0.0.0.0:2200 --html=on --start-child=firefox --start-new-commands=yes
And connected by navigating to $IP:2200
. The client machine runs Win8.1 64-bit. The browsers this was tested on are Google-Chrome 47.0.2526.106 and Firefox 43.0
xpra control :13 start-child xterm
or using the Start Command tray option causes a transparent Xterm to launch. You can type into it (e.g to launch chrome or exit), but it does not render
(forgot server info in ticket description)
Update:
Can you post the output of the Web Console in Firefox? Can't seem to replicate this issue....
Chrome console output:
EDIT: I get the following error when spawning an Xterm window:
error processing 'draw' with 'function (packet, ctx) { var start = new Date().getTime(), wid = packet[1], x = packet[2], y = packet[3], width = packet[4], height = packet[5], coding = packet[6], data = packet[7], packet_sequence = packet[8], rowstride = packet[9], options = {}; if (packet.length>10) options = packet[10]; if (coding in ctx.OLD_ENCODING_NAMES_TO_NEW) coding = ctx.OLD_ENCODING_NAMES_TO_NEW[coding]; var win = ctx.id_to_window[wid]; var decode_time = -1; if (win) { // win.paint draws the update to the window's off-screen buffer and returns true if it // was changed. win.paint(x, y, width, height, coding, data, packet_sequence, rowstride, options, function (ctx) { decode_time = new Date().getTime() - start; ctx._window_send_damage_sequence(wid, packet_sequence, width, height, decode_time); } ); // request that drawing to screen takes place at next available opportunity if possible if(requestAnimationFrame) { requestAnimationFrame(function() { win.draw(); }); } else { // requestAnimationFrame is not available, draw immediately win.draw(); } } }': RangeError: Source is too large }}} (looks to be the relevant error)
Okay, I see. Do the windows paint correctly without this error if you disable h.264 encoding?
I get the same error with PNG, and no error at all with JPEG. They still don't paint correctly.
I get this problem now with trunk server, I thought I had updated before I tested but seems not.
r11499 makes debugging easier because the web console output will reflect the line the error occurred.
The Xpra log showed that h264 was selected regardless of the encoding option in html5 client. r11500 makes us a bit more verbose about what options are being set. It was clear from this that none of the URL parameter options were being set, broken by r10847 and fixed in r11501. A real doobie that one, sorry.
The error persists even with rgb encoding, so r11502 adds some logging of image data sizes. Now the problem is clear.
got 1024 to paint with stride 64 xpra_client.js:231 received a draw packet xpra_window.js:773 got 1024 to paint with stride 64 xpra_client.js:231 received a draw packet xpra_window.js:773 got 2944 to paint with stride 184 xpra_client.js:231 received a draw packet xpra_window.js:773 got 1024 to paint with stride 64 xpra_client.js:231 received a draw packet xpra_window.js:771 data size mismatch: wanted 184 , got 2852 , stride 2852 xpra_window.js:775 Uncaught RangeError: Source is too large xpra_client.js:231 received a draw packet xpra_window.js:771 data size mismatch: wanted 184 , got 2852 , stride 2852 xpra_window.js:775 Uncaught RangeError: Source is too large xpra_client.js:231 received a draw packet xpra_window.js:773 got 1024 to paint with stride 64 2 xpra_client.js:231 received a window-metadata packet xpra_client.js:231 received a draw packet xpra_window.js:773 got 10336 to paint with stride 608 xpra_client.js:231 received a draw packet xpra_window.js:773 got 19536 to paint with stride 888 xpra_client.js:231 received a draw packet xpra_window.js:773 got 1024 to paint with stride 64
Partial window updates were cut out in r8779 and I forgot to add them back in after refactoring the drawing code. I am really surprised I did not notice this till now.
@joshiggins: I was just in the process of making the final 0.16.0 builds... but it sounds like these changes should be included - should I just cancel the builds and merge this in 0.16?
@antoine: I'm just finishing off the fix for this, it's not pushed yet. But yes, if you can (sorry!) it would be better to get this in.
@joshiggins: I have cherry picked the non-debug changes in r11503. It looks like these should be applied to the 0.15 branch too? Hopefully that's enough, if not, we can include more in 0.16.1.
@antoine: r11503 looks good. Yes I think they should go back to 0.15 too.
@maxmylyn: TL;DR please make sure our old friend python-imaging is installed.
It seems that we did have partial window drawing but ignoring the rowstride - we can place images wherever we want anyway, so there was method in the madness.
The apparent regressions (transparent windows, corrupted partial updates, huge strides) are because python-imaging is missing. I thought I was going mad! If you inspect the raw rgb values, they were either zeros or repeating pattern of 255, 0, 255. I remember now that this came up before on the original HTML5 ticket (#473).
However a few other (minor) issues have been identified whilst looking at this which I will move into another ticket.
Applied to v0.15.x in r11514.
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/1059