xpra icon
Bug tracker and wiki

Opened 6 months ago

Closed 5 months ago

Last modified 5 months ago

#2202 closed defect (fixed)

Best screen size detection inconsistency

Reported by: cdrcnm Owned by: Antoine Martin
Priority: minor Milestone: 2.5
Component: html5 Version: trunk
Keywords: Cc:

Description (last modified by Antoine Martin)

When first connecting to a session with the HTML5 client, the best screen size is calculated by the server (function do_get_best_screen_size).
When the browser window is resized, the best screen size is calculated by the html5 client (XpraWindow.prototype.match_screen_size).
The size calculated by each method are not the same. It seems that the server would use a screen size bigger, and the html5 client use a screen size lower.

How to reproduce:

  1. Connect to a xpra session with the html5 client. The screen size would be bigger that the browser size.
  2. Resize the browser window and get back to the same size as in 1. The screen size would be different that the first one.

This cause 2 problems:

  • After the connection, before any resize, the screen size is bigger than the browser window. Some part of the remote desktop are hidden.
  • When the browser window is resized, the screen size is not the same as if the user connected directly on the same size window.

Tested with 2.4 and trunk.

I changed the parameter bigger at False in x11_server_core.py. The screen size is always smaller that the browser window, but it's often smaller that the one found by the HTML5 client.

Attachments (1)

showconfig (11.9 KB) - added by cdrcnm 5 months ago.

Download all attachments as: .zip

Change History (9)

comment:1 Changed 6 months ago by Antoine Martin

Description: modified (diff)
Status: newassigned

@cdrcnm: you are using seamless mode, right?

comment:2 Changed 6 months ago by Antoine Martin

Owner: changed from Antoine Martin to cdrcnm
Status: assignednew

Before:

best bigger resolution for client(1806x1415) is: (1856, 1472)

After r22056:

best smaller resolution for client(1806x1415) is: (1792, 1408)

@cdrcnm: does that work for you?

comment:3 Changed 5 months ago by cdrcnm

That works better, with one problem.
Just after initial connection there is a resize, launched by the client. After this the mouse event are not properly forwarded, there is a offset. The offset is exactly of the difference of size of the screen before and after the resize.

comment:4 Changed 5 months ago by Antoine Martin

Just after initial connection there is a resize, launched by the client

What screen size were you running at?
Do you have the corresponding server log?

comment:5 Changed 5 months ago by cdrcnm

The browser window size is 1920*977

The server log:

2019-03-13 13:44:01,687 xpra is ready.
2019-03-13 13:45:57,661 Handshake complete; enabling connection
2019-03-13 13:45:57,673  automatic picture encoding enabled, also available:
2019-03-13 13:45:57,674   jpeg
2019-03-13 13:45:57,675 HTML5 Linux Chrome client version 2.5
2019-03-13 13:45:57,677 setting keyboard layout to 'fr'
2019-03-13 13:45:57,709  client root window size is 1920x977 with 1 display:
2019-03-13 13:45:57,710   HTML (508x258 mm - DPI: 96x96)
2019-03-13 13:45:57,710     Canvas
Screen change found, reloading...
2019-03-13 13:45:57,818 server virtual display now set to 1856x960 (best match for 1920x977)
2019-03-13 13:45:58,149 client got hello: server version 2.5 accepted our connection
2019-03-13 13:45:58,155 client connection_progress( Session started ,   ,  100 )
2019-03-13 13:45:58,155 client best screen size: 1920 960
2019-03-13 13:45:58,163 client startup complete
2019-03-13 13:45:58,164 client connection-established
2019-03-13 13:45:58,191 DPI set to 96 x 96
Screen change found, reloading...
2019-03-13 13:45:58,531 server virtual display now set to 1920x960
2019-03-13 13:45:58,842 DPI set to 96 x 96
2019-03-13 13:46:23,567 Warning: sanitizing invalid gtk selection
2019-03-13 13:46:23,567  format=-0x13eecb30, type=0x55e13542a800, length=-0x1
2019-03-13 13:46:23,568 Warning: sanitizing invalid gtk selection
2019-03-13 13:46:23,568  format=-0x13eecb30, type=0x55e13542a800, length=-0x1

The browser console:

connection status - change event= undefined , connection info= {effective-type: "4g", downlink: 1450000} tell server: 1
Utilities.js:42 connection_progress( Session started ,   ,  100 )
Utilities.js:42 best screen size: 1920 960
Utilities.js:42 startup complete
Utilities.js:42 connection-established
Utilities.js:42 server connection is OK

There is a 64 pixels difference on the horizontal size before and after the restart (1856 to 1920). The mouse offset is 32 pixels, half of 64 pixels. It match with the size difference, because the canvas is centered on the screen, so there is 32 pixels more on each side.

Only some resolution seems to be affected. I think it's when the client requested resolution and server calculated resolution are different.

comment:6 Changed 5 months ago by Antoine Martin

Owner: changed from cdrcnm to Antoine Martin
Status: newassigned

As per wiki/ReportingBugs, please make sure to report the commands used.
I had asked in comment:1 : @cdrcnm: you are using seamless mode, right?
And from this latest log output, I have just discovered that you are not, you must be using desktop mode (xpra start-desktop), otherwise you would not reach the client best screen size:.. log statement.

Last edited 5 months ago by Antoine Martin (previous) (diff)

comment:7 Changed 5 months ago by Antoine Martin

Resolution: fixed
Status: assignedclosed

Fixed in r22083.

Changed 5 months ago by cdrcnm

Attachment: showconfig added

comment:8 Changed 5 months ago by cdrcnm

Sorry, I thought I responded at your question.
Yes, I'm running the desktop mode.

Xpra command: xpra start-desktop :99 --bind-tcp=0.0.0.0:14500 --start=openbox-session --html=on --daemon=no
Server OS: Debian 9.8
Xpra server version: xpra v2.5-r22078 compiled
Xpra html5 client: xpra v2.5-r22078 on Nginx on Debian 9.8

I also uploaded the config used.

Note: See TracTickets for help on using tickets.