Discussion

Measure everything (fonts, icons, windows) in terms of display units (DUs) Allow the user to specify how big a DU is in terms of physical units (e.g. mm, pt) Map physical units to screen pixels by reliable value of screen DPI (detected or explicitly informed)

So, where do we start?

==========

Anthony S adds: If done correctly, one of the side effects of this feature being fully implemented is that everything will remain the same actual size, regardless of what resolution is set on the screen. Many games already offer this functionality, even if the GUI of the OS they reside on does not.

I wish I knew more about the system internals, but I offer this basic outline:

1. Revise xorg to render to the screen as described above by Alex. 2. Redesign all GUI widgets and icons that are not already vector-based as vectors. 3. For a given screen size, resample all bitmap images before displaying to eliminate aliasing. This would be done once, per bitmap, per image resolution. (This could be left to compiz-fusion to reduce CPU overhead. Alternatively, the user could configure the system to not resample these images).

I'd recommend starting by discussing this with the xorg developers first. Any work done in this direction must be conducive to their development plans. They may be able to give detail about the feasibility of this concept as well. Please provide a URL to this discussion and its results. -- BryceHarrington


<alex@weej.com>

I'm wondering if Xorg even needs to know about anything other than pixels for now. I have had a play with some ideas and it seems that all you need to do is define DUs in terms of physical units, and physical units in terms of pixels (based on screen DPI). We can get away with rounding the result to integer values (read "pixels") for now to fit this into what we already have.

What we already have is:

  • (Most) users with a strong affinity towards aggressively hinted font rendering. Thankfully, fonts can be hinted at any integer size. Check.
  • Hinted icons at specific sizes (16, 24, 32, 48 pixels). Even though most of these icons are SVG, we still need to make a decision as to what to do in between sizes. For example, we can render the size 16 SVG at 18 pixels, but the line hinting will simply not work. We might as well compromise for now and just go ahead and do it without worrying about getting the artwork changed.
  • GTK theme that relies heavily on pixel width lines, etc. We can adapt the themes to round up to integer pixel widths for now.
  • Window and toolkit that relies on integer pixel dimensions and coordinates for input etc.

Hinting is, in general, completely orthogonal to resolution independence and as such will eventually have to go when we can get users used to unhinted appearance (like Mac OS X - higher DPI displays on laptops and portables is helping this).

Doing retained mode vector rendering all the way to the screen would be the next step after this, but that will definitely involve throwing hinting out and a lot of wizardry in X that I don't care to think about right now.

So in short, the default setup would be:

1 inch = 96 pixels 1 du = 1 pt (= 1/72 inch)

Font size = 10 du (10 pt = ~13.3 px < 14 px = GNOME default) Menu icon size = 12 du (= 16 px = Tango default)

The user can configure the screen DPI or have it detected automatically so that natural units are correctly represented. The user can also configure the "display unit" (du) to be of a comfortable size. People with visual impairment might like to set 1 du = 2 pt, for example. While leaving the font "size" alone, this will have the effect that everything will zoom.

Could someone please set up the wiki link for this blueprint and move the above discussion there for us to collaborate on? If this can be adequately fleshed out by October, it could be proposed for Gutsy+1 at UDS Boston. -- BryceHarrington

Looking good. A few comments... We may need to consider the performance impact of doing scaling calculations with every operation. Is there a design approach that could avoid scaling calculations? Also, can you summarize the discussion you had with Gnome about this? Have you had a chance to speak with the xorg developers about it? They might have additional ideas or plans to consider. -- BryceHarrington

Re: Scaling Calculations -- To my understanding, Mac OS X Leopard scales vector images and then saves them as bitmaps for each resolution setting. This way, the calculation does not have to be repeated for that image. -- AnthonyS2

A feature request proposal on the xorg list relating to handling of "virtual size" desktops: http://lists.freedesktop.org/archives/xorg/2007-August/027746.html -- BryceHarrington

ResolutionIndependence/Discussion (last edited 2008-08-06 16:13:52 by localhost)