[haiku-appserver] Re: user needs to know about the clipping region?

Hi,

(For dragging things, I think we can use the HW overlays if available - would spear us a lot of trouble.)

Stephan Aßmus wrote:
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.

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?

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

There are some aspects which I don't understand, so I'll say what I think you wanted to say.

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)

But isn't there a transparent bitmap in front(in main mem buffer)? (The composed image with the bitmap and the region from behind)

- 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.

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.

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.

If what I said above is wrong, I would like you to give a little more details about this.


Thanks,
Adi.

Other related posts: