xpra icon
Bug tracker and wiki

Opened 4 years ago

Closed 4 years ago

Last modified 4 years ago

#887 closed defect (fixed)

chrome dpi issue

Reported by: Jiang Owned by: Jiang
Priority: critical Milestone: 0.16
Component: core Version: 0.15.x
Keywords: Cc:

Description (last modified by Antoine Martin)

This has to be the weirdest issue I've encountered. After upgrading google-chrome from 43.0.2357.124-1 to 43.0.2357.125-1, the chrome window forwarded over network through xpra has extremely low dpi. See attached file.

Window forwarded through ssh -X behaves normally. So does local instance of chrome. Downgrading the chrome back to 43.0.2357.124-1 resolve the issue. Something must have changed between chrome *.124 and *.125 that interacts with xpra badly.

I'm running xpra 0.16 in both client(32bit) and server (64bit) on Ubuntu 14.04. Both of the versions are from xpra.org repository. Here's my options for server:

XPRA_CLIPBOARD_LIMIT=20 xpra --xvfb='Xorg -noreset -nolisten tcp +extension GLX +extension RANDR +extension RENDER \
    -logfile ${HOME}/.xpra/Xvfb-10.log  -config ${HOME}/.xpra/xorg.conf' start :100 --bind-tcp=

Here's my client option:

xpra --encoding=rgb --packet-encoder=rencode --speaker-code=wav --compressor=lz4 attach tcp:workstation:10000

Let me know if more debugging information is needed!

Attachments (1)

chrome-screen-shot.png (197.2 KB) - added by Jiang 4 years ago.

Download all attachments as: .zip

Change History (12)

Changed 4 years ago by Jiang

Attachment: chrome-screen-shot.png added

comment:1 Changed 4 years ago by Jiang

Priority: majorcritical

Just as an additional notes. No other applications, such as firefox or gimp, has this dpi issue when forwarded over xpra.

comment:2 Changed 4 years ago by Antoine Martin

Description: modified (diff)
Owner: changed from Antoine Martin to Jiang


  • --packet-encoder=rencode is not necessary, it is the default if available
  • --compressor=lz4 - same

I have no idea where we can lookup the delta between those two versions of chrome, but it would be very interesting to look at it.

Have you tried xpra's dpi switch? Does it help or make any difference at all?

comment:3 Changed 4 years ago by Jiang

Can you reproduce this issue on your fedora box?
This seems to be the only "key fix" during this chrome update, which looks like it's indeed dpi related:
I've got it from here:
Ironically, it is used to "solve" the dpi issue in some linux instances.

I did try --dpi 110 on the server, but it does not seem to help.

comment:4 Changed 4 years ago by Antoine Martin

Their changes look correct. Using the gtk xft dpi.

Can you post the output of:

xrdb -query -all


python /usr/lib/python2.7/dist-packages/xpra/platform/gui.py

(both from within the xpra session and directly on the client system)

comment:5 Changed 4 years ago by Jiang

Per the bug report from chrome, I actually found a workaround. I simply append

--high-dpi-support=1 --force-device-scale-factor=1

to my google chrome command line when launching it. That seems to fix the problem. So if you could not fix it, an additional notes in the help page could be added for this workaround.

Last edited 4 years ago by Antoine Martin (previous) (diff)

comment:6 Changed 4 years ago by Jiang

I can post the outcome of xrdb and xpra python gui. But should I run it on client or server side?

comment:7 Changed 4 years ago by Antoine Martin

But should I run it on client or server side?

Please include both (client and server) for both of them! (server and client).

comment:8 Changed 4 years ago by Jiang

On server, I run it on the screen instance that is spawned by
DISPLAY=100 screen
where display 100 is my xpra instance. This screen instance is where I launch new application to be forwarded.
gnome.Xft/DPI: 98304
Xft.hinting: 1
xterm*pointerShape: arrow
Xft.antialias: 1
Xft.dpi: 96
*customization: -color
xterm*Background: black
xterm*pointerColor: blue
Xft.hintstyle: hintslight
xterm*cursorColor: LightBlue?
XTerm*metaSendsEscape: true
xterm*Foreground: white
Xft.rgba: rgb

python /usr/lib/python2.7/dist-packages/xpra/platform/gui.py
Using X11 display :100

On client:
qian2@MacBookPro:$ xrdb -query -all
*customization: -color
XTerm*metaSendsEscape: true
Xft.antialias: 1
Xft.dpi: 96
Xft.hinting: 1
Xft.hintstyle: hintslight
Xft.rgba: rgb
xterm*Background: black
xterm*Foreground: white
xterm*cursorColor: LightBlue?
xterm*pointerColor: blue
xterm*pointerShape: arrow

Using X11 display :0.0

Version 0, edited 4 years ago by Jiang (next)

comment:9 Changed 4 years ago by Antoine Martin

So the dpi properties are all set correctly and match the client side values:

Xft.dpi:        96
gnome.Xft/DPI:  98304
xsettings.Gdk/UnscaledDPI        : 98304
xsettings.Xft/DPI                : 98304

(all but Xft.dpi are multiplied by 1024)

The only values that are NOT quite right are:

* dpi                              : 19
* dpi.randr                        : (17, 21)
* dpi.x                            : 17
* dpi.xsettings                    : -1
* dpi.y                            : 21

That's because we do not ship a modified dummy driver for Ubuntu, and so the dummy screen has a fixed size, which ends up being far too big for your screen resolution. (and therefore giving very low DPI values)

I suspect that somehow Chrome is calculating the DPI values directly from the dimensions given by the X11 server, rather than honouring the properties (as it should - and as the commits seem to imply).

Without fixing the chrome code, you can workaround this problem from the xpra side in a number of ways:

  • build your own modified dummy driver (there are very few code updates to this driver, so the patches should apply cleanly)
  • define a much smaller screen size in your xorg.conf, ie something like: DisplaySize 254 158 - until you get dpi values closer to what you want.

Both options will also fix many applications, not just chrome (Java and others).
The second option is much easier, but it is only reliable if the client has a fixed screen size (or within similar ranges).

Last edited 4 years ago by Antoine Martin (previous) (diff)

comment:10 Changed 4 years ago by Jiang

Resolution: fixed
Status: newclosed

I'll stick to the current workaround (by appending an additional option to chrome) until I encounter some other program that has this problem. I can now close this ticket.

comment:11 Changed 4 years ago by Antoine Martin

Note: we now have a wiki page for DPI issues: wiki/DPI

Note: See TracTickets for help on using tickets.