With GL based desktops, how relevant in screen resolution?

[Adam Jackson]

On Fri, 2006-12-15 at 13:29 +1100, Rodd Clarkson wrote:
> (These aren't completely new thoughts, I've heard them discussed before,
> but I thought that with the advent of a GL based desktop for Fedora it
> might be interesting to have this discussion.)
> 
> How relevant is screen resolution now that my desktop is now GL based.

Let's not go wild here.  Your desktop is _not_ a vector UI yet.  You're
rendering to textures, which do have finite numbers of pixels; they are
not vector maps.  If you scale them up (by a non-integer factor), they
will look fuzzy.

> For example, rather than having to pick a new resolution to make my
> desktop (fonts, titlebars, etc.) look bigger or smaller, couldn't we now
> just have a slider that makes the desktop appear bigger or smaller?

This has always been possible.  Just remember that all intermediate
rendering results within the X server are collections of pixels; if
you're going to rasterize a vector representation (like say, a font),
you can get measurably better results by knowing how large your output
pixels are going to be.  Until your screen starts scanning out something
other than pixels, this will continue to be true.

Therefore: you want as many pixels as possible, and you want them all to
be _tiny_.  The better your pixels approximate Platonic points, the
better your rasterization will look.  Just because we're using GL to
compose the scene doesn't mean we're not rasterizing.

The problem of then making GTK and Gnome into something resembling a
vector API is... well, let's just say "harder".

> Another example.  (This is what got me thinking about this).  If I've
> got an application that works at a particular size (say 800x600 in the
> old measure) and I want it a different size, what's stopping us from
> being able to proportionally re-size a window to make it smaller or
> larger?  This might be useful for games, or if you want to resize a
> mozilla window to make the fonts larger, but keep the layout
> proportional including images.

Technically there's nothing hard about this.  The UI seems difficult
though, you really don't want to overload the resize handles on the
window frame.  Maybe a decoration button of a magnifying glass (two, one
+ and one - maybe), that triggers the compositor to do an integer scale?

Shrug.  I'm not a good UI designer.  Hopefully someone else is.

Basically, in the rest state where your compositor isn't animating a
transition, you generally want all your windows to have one texel of
their output correspond to exactly one pixel on the screen, because that
looks best.  The challenge is getting all your apps to scale their UI
elements to be a consistent size.  GTK is not using GL internally to
render widgets, so there's no direct scaling available there; you'll
still need to scale up inside GTK in terms of pixels.  Also insert
something handwavey here about GL font rendering not being good enough
yet to switch.  So we're still dealing with rasterized temporaries for a
while to come.

The full other end of the spectrum would be representing all UI elements
as a vector-format scene graph.  In this model, none of your apps render
in terms of pixels at all.  If they really need to (say, to draw an icon
that only exists in pixmap format), they specify a box to draw it in and
the renderer takes care of scaling it.  Heavy lifting required.  Plus,
the old raster API would still need to work, since ABI compatibility is
a harsh mistress.

In the middle you've got something like a global zoom factor slider with
appropriate scaling done at all levels of GTK.  Gets good results fast,
and relatively straightforward to implement, once you find someone to
implement it.  In fact we _almost_ have this, in the bogglingly
inaccurately named "Resolution" setting in the Fonts preferences, and it
would work pretty well if the rest of the stack would scale its UI to
match.  The tricky parts are things like picking icon size, scaling the
panels, etc.

So to answer your question: resolution is still very relevant.  And will
always _be_ relevant to the app doing the final rasterization, unless
screens start rendering things other than pixels.  But we can make the
rest of the pipeline more pixel-agnostic, and it's generally a good
thing to do.

- ajax