[haiku-appserver] Re: user needs to know about the clipping region?
- From: Stephan Aßmus <superstippi@xxxxxx>
- To: haiku-appserver@xxxxxxxxxxxxx
- Date: Sun, 27 Nov 2005 01:47:26 +0100
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
Other related posts: