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 -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
