add support for scaling to arbitrary physical resolutions (DPI)

[garycmartin]

Just having updated to the latest sugar-jhbuild and re-built sugar, the dpi setting is no longer affecting the actual UI scaling layout of sugar (home ring size, icons size, toolbar/tab size are all too small). The only thing the dpi setting is now effecting is the font size (my previous working jhbuild was about 1 month out of date, I guess).

I use a 1200x900 VirtualBox window on my screen of 133dpi and set sugar-jhbuild to run fullscreen. FWIW, I go edit ~/sugar-jhbuild/install/bin/sugar-emulator and comment out the usual dpi/screen/dimension logic and add my own hard-coded preference:

    cmd.append('-fullscreen')
    cmd.append('-dpi')
    cmd.append('133')

Whatever I've tried, the layout UI scale I get looks like it's only correct for an 800x600 display (though the fonts do correctly scale up/down).

[garycmartin]

Just cc:ing you Bernie as I seem to remember some discussion about changes in default resolution for sugar-jhbuild just prior to interface layout dpi breaking for me ;-)

[sascha_silbe]

Reassigning to sugar as sugar-jhbuild doesn't do anything with X, sugar-emulator (part of sugar) does.
I might be the one to blame (see #565), but sugar-jhbuild is not. :)

Gary, can you please post the output of
a) ps auxww|grep Xephyr
b) xdpyinfo |grep resolution
c) xrandr |head -n 2

Please note that by running inside a hardware emulator you shield X from your (physical) monitor, so the default DPI cannot be correct. 133 DPI is rather high (what model is it?), 90..100 are usual for PC monitors, with 75 and 100 being common default values.
You don't have to patch sugar-emulator, BTW - that was the whole point of my patch. You can simply run "./sugar-jhbuild run sugar-emulator -dpi 133" now (and save that invocation either as a shell function or a shell script).

[garycmartin]

Replying to sascha_silbe:

Gary, can you please post the output of

Thanks for the feedback!

OK, just using "./sugar-jhbuild run" in F10 (inside VirtualBox on a Mac), gives me a fixed window at 800x600 – FWIW not what I want to use given I have VirtualBox opening a roughly 1200x900 window for F10 to use (on a Mac screen on 1920x1200) :-) Any way here are the numbers give when allowing it to run in default windowed 800x600 mode:

a) ps auxww|grep Xephyr

Xephyr :367 -ac -screen 800x600 -dpi 96

b) xdpyinfo |grep resolution

resolution: 96x96 dots per inch

c) xrandr |head -n 2

Screen 0: minimum 64 x 64, current 1208 x 920, maximum 32000 x 32000
VBOX1 connected 1208x920+0+0 0mm x 0mm

Please note that by running inside a hardware emulator you shield X from your (physical) monitor, so the default DPI cannot be correct.

Yep understood, that's why I was previously hard-coding it.

133 DPI is rather high (what model is it?), 90..100 are usual for PC monitors, with 75 and 100 being common default values.

Ahh, the joys of a 17" MacBook Pro ;-)

You don't have to patch sugar-emulator, BTW - that was the whole point of my patch. You can simply run "./sugar-jhbuild run sugar-emulator -dpi 133" now (and save that invocation either as a shell function or a shell script).

Ahh OK, thanks for the correct command example, I had been missing the sugar-emulator bit and assuming /sugar-jhbuild run and attach parameters directly. However... Here's the command equivalent, and it generates a full screen view but with incorrectly proportioned UI (i.e scale looks like it's for 800x600) but with correct font size:

./sugar-jhbuild run sugar-emulator --dpi 133 --fullscreen

Xephyr :354 -ac -fullscreen -screen 800x600 -dpi 96

resolution: 96x96 dots per inch

Screen 0: minimum 64 x 64, current 1208 x 920, maximum 32000 x 32000
VBOX1 connected 1208x920+0+0 0mm x 0mm

Hmmm, so looks like Xephyr is run with both -fullscreen and -screen 800x600. I tried forcing the correct resolution with the below command but got sugar-emulator: error no such option: --screen

/sugar-jhbuild run sugar-emulator --dpi 133 --fullscreen --screen 1208x920

[sascha_silbe]

Hmmm, so looks like Xephyr is run with both -fullscreen and -screen 800x600.

That's fine as the screen size is ignored if -fullscreen is given.

/sugar-jhbuild run sugar-emulator --dpi 133 --fullscreen --screen 1208x920

For sugar-emulator it's --dimensions (was named thus even before my patch), not --screen. You can run "./sugar-jhbuild run sugar-emulator --help" to get a list of known options BTW.

Rereading your initial report, I'm now guessing my change doesn't have anything to do with it (as text is scaling fine, which I just verified myself as well). Rather I think it's got to do with the SUGAR_SCALING changes that were done (very) roughly at the same time.

AFAIK there's currently only support for two fixed scaling values (72 and 100), not a smooth scaling for all DPIs and user<->screen distances. You can try passing "--scaling 72" or "--scaling 100" to sugar-emulator.

[garycmartin]

Thanks Sascha.

I found --dimensions had no effect on fullscreen layouts, but by setting scaling to 100 (thanks that one was news to me) seemed to improve what I'm seeing, though it seem to be more by chance (in that I wanted more to emulate an XO at 1200x900 and --scaling 100 seems to do that for that dimension). I assume other arbitrary resolutions will just break or be wrong if an Activity author is trying to test their user interface for some default hardware (what would the Sugar UI look like if I ever managed to boot Soas on my MacBook Pro at 1920x1200 fullscreen):

./sugar-jhbuild run sugar-emulator --dpi 133 --fullscreen --scaling 100

Will attach screen shot.

[garycmartin]

Looks good using --scaling 100 but I think only by luck that I wanted ~1200x900 window for my testing environment.

[sascha_silbe]

Fullscreen means using the whole screen, so --fullscreen and --dimensions are more or less mutually exclusive (fullscreen will always take preference).
I guess what you want is Sugar using the given dimensions (i.e. restricted to a part of the screen) and the borders being black? Maybe you can convince your window manager to do that (as it's about window decorations and the other stuff modern "desktop systems" display, not about Xephyr going fullscreen). In ion3 (with the Windows key configured for all window manager shortcuts), I simply press Win+Return ("Toggle client window group full-screen mode") to accomplish that.

[garycmartin]

Hi Sascha, --fullscreen takes up the full (emulated in VirtualBox) screen space, which it does very nicely, no decorations and fills the ~1200x900 VirtualBox window that was otherwise running basic Fedora 10. The problem is that for some daft reason even though it fills the whole ~1200x900 virtual 'screen' Xepher seems to be being told (and shows) the layout scaled for a fixed 800x600 screen size. Tiny frame, minute home ring, tiny tiny tabs in activities, and other funky and overly small Sugar layout issues. Using the extra --scaling 100 is pretty darn close to what I'd expect to see. But I'm guessing this is just luck for me and users or authors working in resolutions other than fixed 800x600 or 1200x900 will not be seeing what they should. Many thanks for the --scaling trick! That does seems like the magic bullet here, but a pity it only does 72 or 100 as it won't work for other larger/smaller/in-between screen resolutions.

[garycmartin]

Just another data point here, I finally managed to build a booting Soas, and even more amazingly managed to boot it on a 1997 Del PC (266mhz, 128Mb ram, USB1)! It sure is slow, but it runs ;-) The font size seemed ok, but the general Sugar layout seemed a little small (home ring layout diameter only about 1/3 of full height, activity naming dialogues are 1/3 empty white space at the bottom, Journal detail view the same). This dell is plugged into an old 21" CRT:

xdpyinfo | grep resolution
resolution: 75x75 dots per inch

xrandr | head -n 2
Screen 0: minimum 320 x 200, current 1152 x 864, maximum 1152 x 864
default connected 1152x864+0+0 0mm x 0mm

Do you know what the design behaviour expectation is; that the UI layouts scale up to fill the available screen area, or that larger screens just display more open/empty space? I guess I'm currently looking at scaling=72 on this screen (rather than the closer scaling=100 for the resolution). Is there a way for me to check what Sugar/Soas has chosen?

Wondering, if the maths/logic is too non-obvious to automate, perhaps it's a candidate for a display settings control panel so that folks can adjust the scaling for their screen size?

[tomeu]

I we have only 72 and 100 is because currently we can only set appropriate values for those sizes in the .gtkrc files. We could generate at startup those .gtkrc files, but the correct solution would be running a xsettings daemon. That is also needed for changing font sizes while running.

[dnarvaez]

There has been work in gtk/wayland to support high dpi. I think we should just reuse that.

[dnarvaez]

Milestone 0.90 deleted