High resolution displays and GNOME [LWN.net]

High resolution displays and GNOME

Posted Aug 8, 2013 9:11 UTC (Thu) by njwhite (guest, #51848)
Parent article: High resolution displays and GNOME

This whole "abstract" vs "physical" pixel thing (which CSS has also embraced) feels like a massive kludge to me. It's really weird to define the standard measurement in terms of "this is roughly 1/96 inch, potentially depending on how far from the user the screen is planned to be".

If that really is the most sensible measurement to use, then terminology clearer than "abstract pixel" should be used. Because people have an idea of what a pixel is, and it ain't that.

I like the idea of using something like CSS's 'em' as a base unit. That also ensures interfaces are likely to scale sanely if a user could benefit from an unusually large font size.

to post comments

High resolution displays and GNOME

Posted Aug 8, 2013 10:01 UTC (Thu) by alexl (guest, #19068) [Link] (2 responses)

CSS defines the term "px" for this (with a very interesting definion [1]). OSX uses "points".

Unfortunately we're in a situation where a of code already uses the term "pixel", and we're keeping that API, just making it do something slightly different. That meant it hard to apply a new name to all these existing places.

em:s are useful in some places, like maybe padding and line spacing. Not so much for e.g. border widths, raster images, etc.

[1] http://www.w3.org/TR/2013/CR-css3-values-20130730/#refere...

High resolution displays and GNOME

Posted Aug 8, 2013 10:34 UTC (Thu) by njwhite (guest, #51848) [Link] (1 responses)

> em:s are useful in some places, like maybe padding and line spacing. Not so much for e.g. border widths, raster images, etc.

True. Though reference pixels aren't a great way of describing raster images either (you'd want real pixels really, or ideally of course vector everywhere), and border widths might be better served with something like "thin" / "medium" / "thick". You'd lose a certain amount of pixel perfect expressability, but in reality you do anyway when you deal with varying pixel densities.

> Unfortunately we're in a situation where a of code already uses the term "pixel", and we're keeping that API, just making it do something slightly different.

I see that, and your abstract pixel way is a pretty clever hack to make things work well with new screens. But I wonder whether we can imagine a better way to lay things out going for the future. I haven't actually coded GTK+ much at all, or Qt (Tk and CSS are the only graphics layout engines I know well), but perhaps there are already better systems available that I'm just ignorant of.

High resolution displays and GNOME

Posted Aug 9, 2013 17:33 UTC (Fri) by zenaan (guest, #3778) [Link]

> but perhaps there are already better systems available that I'm just ignorant of.

Enlightenment's e* elibs?
My understanding is that they are all-singing all-dancing when it comes to ultimate scalability and declaratively-expressed UIs...
Just my hearsay though.

High resolution displays and GNOME

Posted Aug 8, 2013 20:39 UTC (Thu) by cladisch (✭ supporter ✭, #50193) [Link]

> I like the idea of using something like CSS's 'em' as a base unit. That also ensures interfaces are likely to scale sanely if a user could benefit from an unusually large font size.

Windows has always done this in dialog box templates. (In the times of 16-bit Windows, this was useful not for high-resolution displays but for non-square pixels on EGA/HGC cards. And nobody dared to waste memory on bitmaps.)

This would be easy to implement, but I have not found support for something like this in any cross-platform GUI toolkit except wxWindows.