xpra icon
Bug tracker and wiki

Opened 15 months ago

Closed 15 months ago

Last modified 15 months ago

#1059 closed defect (fixed)

Unable to add working Xterm windows to HTML5 Client

Reported by: maxmylyn Owned by: Josh
Priority: major Milestone: 0.16
Component: html5 Version: trunk
Keywords: Cc:

Description (last modified by maxmylyn)

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

  • Running 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

Attachments (1)

HTML5_Client_not_rendering_xterm.png (179.4 KB) - added by maxmylyn 15 months ago.

Download all attachments as: .zip

Change History (13)

Changed 15 months ago by maxmylyn

comment:1 Changed 15 months ago by maxmylyn

Description: modified (diff)

(forgot server info in ticket description)

comment:2 Changed 15 months ago by maxmylyn

Update:

  • Having an Xterm as a start child also renders transparently. No need to run Firefox.

comment:3 Changed 15 months ago by Josh

Can you post the output of the Web Console in Firefox? Can't seem to replicate this issue....

comment:4 Changed 15 months ago by maxmylyn

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)
Last edited 15 months ago by maxmylyn (previous) (diff)

comment:5 Changed 15 months ago by Josh

Okay, I see. Do the windows paint correctly without this error if you disable h.264 encoding?

comment:7 Changed 15 months ago by maxmylyn

I get the same error with PNG, and no error at all with JPEG. They still don't paint correctly.

comment:8 Changed 15 months ago by Josh

Status: newassigned

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.

comment:9 Changed 15 months ago by Antoine Martin

@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?

comment:10 Changed 15 months ago by Josh

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

comment:11 Changed 15 months ago by Antoine Martin

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

comment:12 Changed 15 months ago by Josh

Resolution: fixed
Status: assignedclosed

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

comment:13 Changed 15 months ago by Antoine Martin

Applied to v0.15.x in r11514.

Note: See TracTickets for help on using tickets.