Linked by Thom Holwerda on Thu 7th Aug 2008 13:48 UTC, submitted by jcornuz
GTK+ Red Hat's David Zeuthen blogged today about the huge patch he submitted to GTK+ that will allow the toolkit to achieve resolution independence - widget and font size adapting to your screen's real estate; no more tiny application lost in the corner of your high resolution screen. Although more work is obviously required, Zeuthen's idea is to use RI as the hot-new-feature selling point of the upcoming 3.0 GTK+ release. Discussion is going on in the gtk-devel mailing list and there is an ogg video of the feature in action.
Permalink for comment 326086
To read all comments associated with this story, please click here.
RE: Resolution independence
by Morin on Thu 7th Aug 2008 14:54 UTC in reply to "Resolution independence"
Morin
Member since:
2005-12-31

> So, in the future atleast all icon sets have to also include information
> about their desired DPI so GTK+ knows how to transform them.

They could define a "standard resolution" in which all media has its intrinsic size, and scale according to the factor to the current resolution (taking aspect ratio into account, of course, so icons don't get horizontally stretched on wide screens).

Media size would still scale with overall display size (as opposed to resolution), but unless you're doing publishing work, you often want that. And an overall scale argument is still possible as a counter-measure.

> Also, how about the performance? Are all those icons/images et al
> transformed in software or do they try to accelerate that process via
> OpenGL or X acceleration?

Depends. On the one hand, graphics hardware can do really fast transformations. On the other hand, its resampling mechanics are far from perfect - this could be done much better in software. Fortunately, scaling and resampling must be done only once at application load time, since the screen resolution usually don't change often.

The only scenario where speed would actually suffer is when doing software scaling and resampling during run-time (i.e. with every draw operation), but I don't see any advantage of doing so.

Reply Parent Score: 3