[winswitch] neither --dpi switch or dpi setting in xpra.conf allows me to set the DPI to fixed value
Thomas Esposito
tmesposito00 at gmail.com
Thu Oct 6 03:20:00 BST 2016
Just to add a bit more info...
I've tried x264, lz4, and png (32, 8, and gray scale) encodings and none of
these approach the responsiveness and perceived performance of TigerVNC
with Tight encoding.
When I look at the stats and graphs under session info, I see lots of
latency spikes, particularly under Damage latency, which spikes into
several seconds.
I've also tried this on a Microsoft Azure Ubuntu VM that I've been playing
around with via a free trial account. The performance seems better (same
encodings), but occasionally gets pretty bad. Maybe it's just intermittent
network issues. I haven't been able to get VNC working on this VM...
On Oct 5, 2016 3:14 PM, "Thomas Esposito" <tmesposito00 at gmail.com> 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!
>
> 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.
>
> 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.
>
>
>
> On Tue, Oct 4, 2016 at 11:23 AM, Antoine Martin <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>> 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>> 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>
>> > 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/Monit
>> orDPI>
>> >
>> > Cheers
>> > Antoine
>> >
>> >
>> > >>
>> > > _______________________________________________
>> > > shifter-users mailing list
>> > > 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>
>> > >
>> >
>> > _______________________________________________
>> > shifter-users mailing list
>> > 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>
>> >
>> >
>>
>>
>
More information about the shifter-users
mailing list