Now imagine the cost of calculating the transformation for the entire screen. To solve this, critical code path contains shortcuts to minimize the instruction count as much as possible in the case of identity transformation (i.e. skip all the transformation/filtration/transparency logic and just copy the buffers). You would have to provide similar shortcuts for the viewports.
This is certainly not only an issue of code optimization and acceleration of the transformations. For optimal resolution-independent rendering the whole graphics stack should be aware of it.
For example, to make use of the fastest rendering paths possible (and also to avoid aliasing artefacts) a window should be preferably rendered in the native pixel density of the "primary" viewport (where "primary" is defined in the terms of "most actively/directly used") and only revert to transformations for the "non-primary" viewports and as a fall-back.
But this means that if the configuration of the "primary" viewport changes, the window might be notified about the change of the native pixel density and possibly (not necesarily) redraw itself with the new parameters.
This will be a slight departure from the untaint composing desktop paradigm (where the windows and viewports are completely decoupled) to a hybrid architecture where the compositor can signal the windows to optionally redraw themselves with new parameters. The key word here is "optionally" -- I am certainly not proposing to introduce the traditional on-demand painting paradigm.
A completely different approach would be a fat display server with resolution-independent server-side scene graph (anyone remembers Display PostScript?). But I guess most people would agree that this is also an idea from the past.
M.D. _______________________________________________ HelenOS-devel mailing list [email protected] http://lists.modry.cz/listinfo/helenos-devel
