Returning a moment to HOSDE (it really needs a cooler name), the full specification (dont know if this is a good word for this) will be in this google drive document: https://docs.google.com/document/d/1pGrZpII9QLi5m8e13W8S9ljTn03MfcqdTULIazuD5yE/edit, if anyone wants to edit it and I will add him.
BTW, I know that both toolkit and drawing library are still in its infancy, and as said I know it will take time to catch the mockup, so I dont want the mockup to be the start but the end (wanted to say it in a beautiful way). Finally: as said HOSDE needs a cooler name (the less time this one its used the less it will be remembered) and since you are HelenOS developers/founders I will grant you the honor of naming it (of course if everyone agrees). 2013/10/15 Martin Decky <[email protected]> > 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<http://lists.modry.cz/listinfo/helenos-devel> >
_______________________________________________ HelenOS-devel mailing list [email protected] http://lists.modry.cz/listinfo/helenos-devel
