[winswitch] DPI, window resizing increments and performance (was dpi..)

Antoine Martin antoine at nagafix.co.uk
Thu Oct 6 05:11:00 BST 2016


On 06/10/16 02:14, Thomas Esposito wrote:
> Adding the path to the usr/lib64/xorg/modules/drivers directory of my
> local install to the LD_LIBRARY_PATH was not enough to force Xorg to use
> the patched dummy driver. However, I discovered that I could add a
> "ModulePath" line to my xorg.conf in order to change the effective
> module search path.
> 
> So, the DPI problem is solved. Thanks for the help!
Ah, forgot about this option!

> The next 2 issues on my list are:
> 
> 1.) My terminal of choice has been gnome-terminal for a while. This is
> version 2.31.3 on RHEL6.6. The problem is that, when I maximize the
> window, the edge of the window appears to extend beyond the bottom edge
> of my monitor. As a result, the bottom row of text in the terminal is
> mostly cut off. When I maximize to an extended display in a dual-monitor
> setup, it is not quite as bad and I can see about the top 75% of the
> bottom row of text. I wonder if this has something to do with this
> particular X application being forced to relatively coarse-grained
> sizing increments (i.e. in units of text columns-rows), and then
> rounding up to the next size increment rather than down when the
> maximized window size doesn't exactly match one of these coarse-grained
> increments.
Sounds like:
http://xpra.org/trac/ticket/1327
The size increments should be forwarded to the client.

> 2.) This is a bigger issue. I'm finding that compared to TigerVNC, which
> is the officially-supported remote X solution in my office (and doesn't
> support per-application windows like xpra), is MUCH faster than xpra. I
> haven't ruled out some kind of network QOS prioritizing VNC traffic over
> ssh, but I wanted to ask what kind of performance I should be expecting
> relative to something like TigerVNC. We also have FreeNX working (but
> again, not with per-application windows), which supposedly uses ssh as
> well, but FreeNX performance is at least as good as TigerVNC, if not
> better. xpra is in a DISTANT 3rd place.
See the other email, sounds like a bug.

Cheers
Antoine

> 
> 
> 
> On Tue, Oct 4, 2016 at 11:23 AM, Antoine Martin <antoine at nagafix.co.uk
> <mailto:antoine at nagafix.co.uk>> wrote:
> 
>     On 04/10/16 21:43, Thomas Esposito wrote:
>     > On Tue, Oct 4, 2016 at 4:52 AM, Antoine Martin via shifter-users
>     > <shifter-users at lists.devloop.org.uk
>     <mailto:shifter-users at lists.devloop.org.uk>
>     > <mailto:shifter-users at lists.devloop.org.uk
>     <mailto:shifter-users at lists.devloop.org.uk>>> wrote:
>     >     On 04/10/16 03:18, Thomas Esposito via shifter-users wrote:
>     >     > I'm not sure if this is related to my issue,
>     >     Probably is.
>     >
>     >     > but I have reason to doubt
>     >     > that the shared libraries that I extracted from the rpm files are actually
>     >     > being loaded.
>     >     This may severely impact your experience: missing picture codecs, wrong
>     >     DPI, etc..
>     >
>     > Actually, I think the one of the issues contributing to my DPI problem
>     > are that I can't seem to load the dummy_drv.so instead of the patched
>     > version from the rpm. I'm guessing that Xorg is using a hard-coded path
>     > to /usr/lib64/xorg/modules/drivers/, and using that without even looking
>     > at my LD_LIBRARY_PATH. I'm not sure there is any way around this without
>     > directly replacing the lib in /usr/lib64/xorg/modules/drivers.
>     Yes, like I said just below, use the patched dummy driver.
>     In your case, you may need to build your own patched Xorg server from
>     source to get it loaded.
> 
>     (snip)
>     >     > Also, despite my LD_LIBRARY_PATH setting, my Xorg.:100.log file (I'm using
>     >     > display :100) reports that it is loading the standard
>     >     > /usr/lib64/xorg/modules/drivers/dummy_drv.so, rather than the patched
>     >     > driver in
>     >     > <my_xpra_extract_directory>/usr/lib64/xorg/modules/drivers/dummy_drv.so..
>     >     This will be the source of your DPI problems: you won't be using a
>     >     patched dummy driver.
>     ^ See here.
> 
>     >     > How can I be sure that any of the libraries that I have downloaded are
>     >     > actually being loaded?
>     >     That depends on how the application loads its shared objects.
>     >     In the case of Xorg, this is probably a hard-coded path you can do
>     >     nothing about. (and you probably won't be able to LD_PRELOAD it either)
>     >
>     > Nope, I can't seem to LD_PRELOAD your dummy_drv.so (I get ERRORs).
>     >
>     >
>     >     > On Mon, Oct 3, 2016 at 3:07 PM, Thomas Esposito <thomase00 at yahoo.com <mailto:thomase00 at yahoo.com>
>     <mailto:thomase00 at yahoo.com <mailto:thomase00 at yahoo.com>>> wrote:
>     >     >
>     >     >> The fonts rendered by Xorg are very small, and I suspect the reason is
>     >     >> because the DPI is being set to an unreasonably low value (i.e. 42x28 now,
>     >     >> but varies depending on the monitor setup). Rather than deal with the
>     >     >> patched dummy driver, I'm assuming that I should be able to simply fix the
>     >     >> X DPI to a reasonable value (i.e. 96x96), since that is what I'm accustomed
>     >     >> to anyway, being a Windows user primarily. I know there are quasi-religious
>     >     >> arguments about a fixed DPI of 96, particularly with all the high-res
>     >     >> monitors available now, but I'd rather not get into that.
>     >     The issue you're hitting is that the applications you use do not honour
>     >     any of your DPI settings but they try to calculate their own "hardware
>     >     DPI" based on the monitor dimensions and screen resolution.
>     >     This never works well, which is why we have use a patched dummy driver
>     >     to simulate the "correct" values.
>     >
>     > I'm not sure about this explanation.
>     OK.
> 
>     > For example, when I use TigerVNC, I
>     > can set the DPI directly on the vncserver command line with the '-dpi'
>     > switch. When I do this, the "resolution" reported by xdpyinfo matches
>     > the value that I set on the command line. More importantly, when running
>     > the very same X applications that I am having DPI problems with when
>     > using xpra, the Xvnc server fonts scale EXACTLY according the the
>     > reported "resolution" value (at least when application requests a
>     > DPI-scaled font). When using xpra (at least without the patched
>     > dummy_drv.so), the "--dpi" switch has absolutely NO effect on the
>     > "resolution" reported by xdpyinfo. Rather, it seems to ALWAYS be
>     > calculated based on the Modeline resolution and the DisplaySize (I think
>     > we agree on this). In particular, what doesn't make sense to me is the
>     > idea that individual X applications will be doing their OWN DPI
>     > calculation. According to my understanding, the X application simply
>     > asks the X server to render a font.
>     Those days are long gone, "most" applications use toolkits nowadays and
>     not X11 core rendering.
> 
>     > It may asks for an unscaled font
>     > (e.g. RHEL6 xemacs seems to do this), which will always be rendered the
>     > same regardless of DPI, but otherwise it is up to the X server how to
>     > render it based on its own understanding of DPI. It seems that the issue
>     > is NOT that some X applications calculate their own DPI, but rather that
>     > the X server itself (when using the standard dummy_drv.so) effectively
>     > IGNORES the DPI switch that Xorg was started with and instead calculates
>     > it based on Modeline resolution and DisplaySize.
>     Almost, but not quite: the dpi is not ignored, it is scaled.
>     When the client connects, the dummy virtual screen is resized to match
>     your client's resolution as best we can, and at that point the dummy
>     screen does have a "fixed virtual size" of sorts.
> 
>     ie with trunk: when we change the default ~8K resolution down to
>     1080p... the original DPI value is divided by ~4.
> 
>     The patched dummy driver will not only keep the DPI constant when the
>     screen is resized, it will also try to honour the value supplied by the
>     client. (obviously, not all clients have the same DPI settings)
> 
>     > I suppose that the end
>     > result is ultimately the same, and dummy_drv.so needs to be fixed in
>     > such a way that it respects the DPI. As you say, I imagine that if I was
>     > actually able to use the patched dummy_drv.so (it seems I can't though),
>     > I would see that the "resolution" reported by xdpyinfo is what I have
>     > requested and DPI-scaled fonts will look "right".
>     Yes, that's why it's there.
> 
>     > Ultimately, I believe that the only input the individual X applications
>     > provide into the equation is effectively binary. That is, it either
>     > requests a scaled on un-scaled font.
>     > Also, I think it's confusing to refer to the X server DPI and Xft.dpi in
>     > the same context. These are associated with 2 TOTALLY different font
>     > rendering systems. Xft is for modern client-side (i.e. X application
>     > side) font rendering. This is totally independent of the X server DPI
>     > and it explains why I don't have any problems with the fonts in my
>     > gnome-terminal for example.
>     As far as xpra is concerned, whether the forwarded applications will be
>     using X11 rendering or client-side rendering is totally irrelevant: all
>     options must be supported.
> 
>     So we synchronize all the DPI settings we can get our hands on in the
>     hope that all applications will render using the correct settings.
>     In some cases, this requires a patched dummy driver be achieved.
> 
>     > All that being said, forgive me if I'm being presumptuous. ;-) I can
>     > certainly be convinced otherwise, but right now, something just isn't
>     > adding up regarding this explanation.
>     There should be enough information above, otherwise there is *a lot*
>     more on the wiki and the DPI related tickets.
> 
>     Cheers
>     Antoine
> 
> 
>     >
>     >
>     >
>     >     If you want to fix this without using the patched dummy
>     driver, your
>     >     only option is to edit your etc/xpra/xorg.conf and change the
>     >     DisplaySize of the monitor to get the desired DPI value:
>     >     https://wiki.archlinux.org/index.php/xorg#Display_size_and_DPI
>     <https://wiki.archlinux.org/index.php/xorg#Display_size_and_DPI>
>     >   
>      <https://wiki.archlinux.org/index.php/xorg#Display_size_and_DPI
>     <https://wiki.archlinux.org/index.php/xorg#Display_size_and_DPI>>
>     >     This will not adapt when you connect clients with different
>     resolutions.
>     >
>     >     You may also want to try to switch to Xvfb instead of Xdummy
>     by changing
>     >     the "xvfb=" line in your xpra config file.
>     >
>     >     >> Anyway, I've attempted to fix the Xorg DPI by using the
>     '--dpi=96' switch
>     >     >> on the xpra command line AND by uncommenting the 'dpi = 96'
>     line from the
>     >     >> default xpra.conf file included with the install (which I
>     have copied to
>     >     >> ~/.xpra/xpra.conf). In both cases, this does not seem to
>     have any effect,
>     >     >> and my fonts and DPI remain unreasonably small.
>     >     >>
>     >     >> What am I missing?
>     >     >>
>     >     >> Also interesting, although most likely unrelated,
>     >     It is related and very relevant, but sadly it is also ignored
>     by many
>     >     applications.
>     >
>     >     >>is the output I get when
>     >     >> running 'xrdb -q':
>     >     >>
>     >     >> gnome.Xft/DPI: 98304
>     >     >> Xft.hinting: 1
>     >     >> Xft.antialias: 1
>     >     >> Xft.dpi: 96
>     >     >> Xft.rgba: none
>     >     >> Xcursor.size: 21
>     >     >> Xft/DPI: 98304
>     >     >> Xft.hintstyle: hintmedium
>     >     >>
>     >     >> I know the DPI here is for client-side/fontconfig fonts and
>     is unrelated
>     >     >> to Xorg-rendered fonts, but I find the value of 98304 to be
>     strange here.
>     >     That's the DPI value multiplied by 1024, see:
>     >     https://wiki.debian.org/MonitorDPI
>     <https://wiki.debian.org/MonitorDPI>
>     <https://wiki.debian.org/MonitorDPI
>     <https://wiki.debian.org/MonitorDPI>>
>     >
>     >     Cheers
>     >     Antoine
>     >
>     >
>     >     >>
>     >     > _______________________________________________
>     >     > shifter-users mailing list
>     >     > shifter-users at lists.devloop.org.uk
>     <mailto:shifter-users at lists.devloop.org.uk>
>     >     <mailto:shifter-users at lists.devloop.org.uk
>     <mailto:shifter-users at lists.devloop.org.uk>>
>     >     > http://lists.devloop.org.uk/mailman/listinfo/shifter-users
>     <http://lists.devloop.org.uk/mailman/listinfo/shifter-users>
>     >     <http://lists.devloop.org.uk/mailman/listinfo/shifter-users
>     <http://lists.devloop.org.uk/mailman/listinfo/shifter-users>>
>     >     >
>     >
>     >     _______________________________________________
>     >     shifter-users mailing list
>     >     shifter-users at lists.devloop.org.uk
>     <mailto:shifter-users at lists.devloop.org.uk>
>     >     <mailto:shifter-users at lists.devloop.org.uk
>     <mailto:shifter-users at lists.devloop.org.uk>>
>     >     http://lists.devloop.org.uk/mailman/listinfo/shifter-users
>     <http://lists.devloop.org.uk/mailman/listinfo/shifter-users>
>     >     <http://lists.devloop.org.uk/mailman/listinfo/shifter-users
>     <http://lists.devloop.org.uk/mailman/listinfo/shifter-users>>
>     >
>     >
> 
> 




More information about the shifter-users mailing list