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...
On the surface behind the transparent bitmap, right?
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
Clip to visible region.
- 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
Why alpha compositing? Shouldn't you mean 'copy'?
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.