Re: [lmi] Headless GUI tests on corporate server

[Vadim Zeitlin]

On Sat, 13 Nov 2021 23:45:23 +0000 Greg Chicares <gchicares@sbcglobal.net> 
wrote:

GC> On my own machine, I had been using
GC>   Xvfb :1 -screen 0 1280x960x24
GC> But who else today uses a 4x3 aspect ratio, which is perfect
GC> for doing actual work but not ideal for playing games and
GC> watching movies?

 Unfortunately nobody does, my (three) old 1600x1200 monitors are simply
irreplaceable and the new 4K displays are 3840x2160, i.e. only 1920x1080 in
logical units. This is progress, I guess.

GC> And who else uses 192 DPI, which is unpopular though ideal?

 This is pretty popular, however, as basically everybody uses this on 4K
displays, as this is exactly what 200% DPI scaling means. Somewhat to my
dismay, I've also learnt, while working on high DPI support in wxWidgets,
that people also use 120 and 168 DPI (125% and 175% respectively), let
alone relatively sane 144 (a.k.a. 150%). Oh, and one guy used 288 DPI too.

 For the record, while the new scaling code in wx tries to do its best to
support all of those DPIs, and everything in between, it still gives best
results for 192 DPI (or 96...), so please keep using this DPI, at least
until we replace all lmi PNG icons with SVGs.

GC> That's what I was thinking, so I decided to use
GC> "the default screen configuration" from the manpage:
GC> 
GC> https://linux.die.net/man/1/xvfb
GC> |
GC> | Xvfb -pixdepths 3 27 -fbdir /var/tmp
GC> |    The server will listen for connections as server number 0,
GC> |    will have the default screen configuration (one screen,
GC> |    1280x1024x8), will also support pixmap depths of 3 and 27,
GC> |    and will use memory mapped files in /var/tmp for the
GC> |    framebuffer. 
GC> 
GC> because, obviously, defaults must work robustly.

 I see, thanks. I completely forgot/missed that they used 8bpp in the
example.

GC> But if I instead follow your advice, everything just works,

 To conclude this, I'd like to say that it might actually be a good idea to
run the GUI tests in smaller screen resolution, i.e. maybe 1080 vertically
(if not 1024 or 960), as there could conceivably be some real problems at
such screen sizes, e.g. windows not fitting on screen and being truncated
etc. But I'd rather not bother with 8bpp (and 16bpp) modes, unless we
really need them (and the only realistic situation in which this might
happen would be when using RDP over slow connections, so it's not totally
impossible neither, but. again, I'd rather wait until it really turns out
to be a problem before fixing it).

 In any case, thanks for confirming that the tests pass now!
VZ

pgpTSzMeuKWbM.pgp
Description: PGP signature