Sergio wrote: > I would like to get some feedback from you (what things you like, the thing > you dont, if you thing this is impossible) [...]
Overally, your idea for desktop environment comes at the right moment. You can basically continue where I left off. However, you should know that there is currently no hardware acceleration and both drawing library and widget toolkit have very limited features. If you want to get visually as close as possible to the mockup, expect a lot of non-trivial work to introduce some basic level of graphic acceleration and to implement new drawing functions and widgets. If you want to focus solely on desktop environment, rather imagine your mockup in a lower resolution and without transparency/shadows/gradients. Martin wrote: > Another thing to consider is resolution independence. I'm planning to > take a look at viewport handling to easily allow e.g. cloned screens to > be rendered with different native resolution (for use-case think of > low-res projector and FullHD+ laptop display rendering the same content > - e.g. vector based slides - with the resolution suitable for the > display used). I think Peter added some bits in this regard, but I have > not read the code yet and there might be differences with my vision of > how this should be implemented. Unfortunately I cannot promise that I'll > have a look at this anytime soon. For future reference, adding resolution independendence to the viewports should be possible and was considered during design phase. It was not implemented because of lack of time and concerns about the resulting performance. The idea was to equip viewport_t structure with transformation matrix and to add additional transformation step into pixel calculation. In fact, viewports would be then very similar to windows. The problem is that it would be extremely slow without acceleration. Right now, even moderately large window with non-identity transformation can fully saturate the CPU when moved over the screen. In non-accelerated qemu, transformations are not usable at all. 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. Petr _______________________________________________ HelenOS-devel mailing list [email protected] http://lists.modry.cz/listinfo/helenos-devel
