[haiku-appserver] Re: user needs to know about the clipping region?
- From: Adi Oanca <adioanca@xxxxxxxxx>
- To: haiku-appserver@xxxxxxxxxxxxx
- Date: Sun, 27 Nov 2005 00:30:13 +0200
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:
