Hi Michael, thanks for taking the time to think this through. > > Stick with the clipping based approach, but how about an offscreen > > buffer in main memory for just the parts in the frame buffer > > with transparency? > > Not that I understand every aspect here, but I think that this is not as > easy as it sounds. As far as I understand it, you need to have the > current background to draw something transparent over it. If this is > the case, this would either require to keep the whole frambuffer in > main memory (reducing this approach to a double buffer), redrawing all > parts below the new transparent area to build up the backgroud (which > would take a long time for bigger areas) or to fetch the background > from the graphics card (which is terribly slow). You don't have to have the background available to draw something underneath the transparent area unless what you draw needs to be alpha blended itself, like in some cases when drawing text or anti-aliased lines. So your observation is correct for some cases. My thinking is simple: Why does it flicker so badly in R5 or ZETA, when you drag something transparent, and stuff behind the transparent bitmap is drawn? It looks like BeOS has a backup of the background of the transparent drag bitmap in main memory, and before anything is drawn there, the background is restored, the drawing done and then the bitmap is composed back on top of it. Doesn't this sound very clumsy? There is no other explaination. In my opinion, we could introduce a mechanism to "rout" graphics calls either to the framebuffer or to main memory, depending on wether we want to show something transparent on top of it. My proposal is just an idea for the implementation. Extended from just dragging transparent bitmaps to other transparent drawing on the server side. Like anti-aliased edges of a window decor's corner. The background as it would be displayed in the framebuffer without any transparent overlays could be contained in a second main memory buffer. This way, having to transfer stuff from graphics memory to main memory would be greatly reduced. > You can only keep the "parts with transparency" in a main memory buffer > if you know beforehand what parts will have transparency. With the > example of dragging a transparent bitmap this is certainly not the > case. And getting or redrawing the background everytime when a user > starts dragging that transparent bitmap around is a bit overkill I > think. Just imagine the situation where you select something in > ShowImage and drag it out to make a bitmap clip. The background changes > with every move. > Just my concerns about this. Or do I just miss something? The implementation of dragging a ShowImage bitmap clip seems to be exactly the horror scenario that you describe :-). With the exception that you don't need to transfer parts that you have previously transfered. Assuming you have dragged the bitmap all over the screen, and no part is redrawn in the meantime, you would not have to transfer anything again. But for the case that something is redrawn... my idea is to have a special clipping for that, so that drawing commands can be routed to the main memory "backup". Current R5 implementation (from observation): - get a drawing command - ups, there is a transparent overlay where I want to draw - restore backup of that area - do the drawing - refresh backup - put the transparent overlay back on top My proposal: - get a drawing command - clip to non-transparency containing parts on screen - 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) - do the alpha compositing with the frame buffer as target As you see, this saves a few (of the expensive) steps, and completely avoids flickering. When this concept is applied to window borders, there would not have to be transfer from graphics memory. When any window frames change, the transparent region would be included in the dirty region. There would have to also be a dirty region tracking for the frame buffer backup. Ie, when there is drawing in the frame buffer for non-transparency containing parts, but we already have a backup for that area, it would simply get marked dirty. Best regards, -Stephan