[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?


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

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

Other related posts: