Hi Martin,
"Does that mean that that the design of the new display server makes it harder to have transparency (or alpha blending in general) and to apply various transformations to the surfaces compared to the original compositor? Or does that mean that the functionality is simply not implemented (yet), but nothing in principle precludes it from being implemented efficiently in the future?" Semi-transparent windows are rather easy. It would be near trivial to enable color-key transparency for windows. Alpha transparency only requires adding alpha channel to the bitmap structure. To allow 'generic' transforms, you would need to replace the simple translation with 'generic' transform in the ds_window structure, the paint routine and the event transform code. It's pretty straightforward. There is nothing that would make this impossible or even difficult. I simply decided against implementing it because I didn't deem it worth the extra work and added code complexity. It could be done based on actual use case. I'd like to avoid this feature creating much overhead when not used, so I'd prefer having a special 'fast' case when simple translation can be used (and possibly completely opting out of transforms at compilation time). I simply didn't feel like adding all this complexity without actually putting it to some practical use. "" "(a) While transparency, rotating and scaling might be a fad on a desktop operating system (although I personally still believe that, with moderation, it can actually improve the user experience), it is rather essential for the UI of smartphones and other non-desktop UIs. " Possibly for a certain style of such UIs, although I don't feel competent to judge what exactly would be required of the display server to support these. In any case these kind of user interfaces have quite different style of window management which would have to be accommodated (WM is part of display server and was part of compositor). In any case general transforms are quite difficult to implement efficiently without appropriate HW acceleration, which is currently nowhere in sight. (and given our manpower and focus might quite frankly never happen). "" "What about the readiness of the new design to make use of more advanced hardware acceleration?" It should be pointed out that the current compositor-based solution, while assuming HW acceleration is available, is actually absolutely not amenable to HW acceleration. It is obvious that the author had no idea how HW acceleration works and what elements in the design are required to make use of it (in other words having a chain connecting the graphics HW with the actual resource being used by the end user, allowing to delegate the resources). In contrast, GFX is designed with acceleration in mind. gfx_bitmap_t is a HW accelerated bitmap (i.e. bitmap that can be HW accelerated), is is linked to its GC (c.f. e.g. textures in SDL 2.0). It might be necessary, though, to limit access to the bitmap's pixels as currently they can be accessed without e.g. locking the bitmap). While there are currently no provisions for direct rendering, the architecture should allow for accelerated direct or indirect rendering. While the compositor had a hinted attempt at defining some infrastructure for direct rendering, really without an actual implementation it's completely pointless. "Many current GPUs do not have dedicated blitters and other 2D acceleration facilities, everything is handled by the 3D engine. " You would need to explain more what difference that makes from software standpoint, I'm not sure what actually concerns you. Do not cling to the expression "HW blitters", what I had in mind was HW acceleration in general. Since currently the only graphics operation that we could use acceleration for is blitting bitmaps, it could well be carried on a good old fashioned SVGA blitter or by the 3D engine of a GPU (while I can image the former being easier to implement, but obviously less widely useful). Cheers, Jiri
_______________________________________________ HelenOS-devel mailing list [email protected] http://lists.modry.cz/listinfo/helenos-devel
