Hi Adi, > (For dragging things, I think we can use the HW overlays if available - > would spear us a lot of trouble.) Yes, but let's think about how to make this work without any changes to the driver API. Because I wouldn't know how to implement those. :-) If you do, be my guest!! > This means you have to allocate a buffer as big as the screen size, > isn't it? and then start copying parts under the transparent bitmap, > when it moves. If dragging something this would work nicely, but I'm > afraid this can't be extended too much. You can't have 2 transparent > surfaces overlapping each other - which is the case with decorators. Or > have I misunderstood something? No, you understood perfectly well. This is just an optimization for server side transparent parts. Like /the/ transparent bitmap being dragged. Then maybe some parts of the decorators (on a second transparency buffer). This concept cannot be extended to transparency comming from the client. This cannot be done without dropping the region based approach and having a buffer for each window and then doing compositing of all windows. > > But for the case that something is redrawn... > > On the surface behind the transparent bitmap, right? Yes. > > My proposal: > > - get a drawing command > > - clip to non-transparency containing parts on screen > > Clip to visible region. Not quite. The visible region of a layer includes both, the parts containing no transparent overlays, and also those that have transparent overlays on top of them. Then the DrawingEngine knows about the region that contains any alpha stuff. This is where the drawing is clipped to the part of the layers visible region that has no transparent overlays (what I ment above). > > - draw those directly on screen > > - clip again to transparency containing parts on screen > > - draw those in the main memory backup (possibly having to make the backup > > first) > > But isn't there a transparent bitmap in front(in main mem buffer)? (The > composed image with the bitmap and the region from behind) There are several buffers: - graphics memory buffer with final scene - main memory buffer for drawing the solid background behind the overlays - main memory buffer with the transparent overlays all of which are in screen size, but with clipping regions to tell what parts are actually valid data. When you have drawn on the main memory "background", you can take the main memory transparency bitmap and write each composed pixel directly to the final scene in graphics mem. Should not flicker the least. > > - do the alpha compositing with the frame buffer as target > > Why alpha compositing? Shouldn't you mean 'copy'? That is clear now with what I wrote above, no? > > As you see, this saves a few (of the expensive) steps, and completely > > avoids flickering. > > If the last paragraph is true, you do alpha compositing with the frame > buffer, I can't see how flickering can be avoided as the frame buffer > must contain the region behind the transparent bitmap. See above. Note, I'm talking about a "few pixels". Like the rounded corners of the decor. Even if we don't do that, we'd still avoid the flickering like it happens in R5 and ZETA when you drag something transparent and the background changes. Maybe I should draw a few images to illustrate how I imagine this whole thing. Best regards, -Stephan