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

Ola!

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

    No need to do that. :-) There is support for that already.
enum {
 B_BITMAP_CLEAR_TO_WHITE        = 0x00000001,
 B_BITMAP_ACCEPTS_VIEWS         = 0x00000002,
 B_BITMAP_IS_AREA               = 0x00000004,
 B_BITMAP_IS_LOCKED             = 0x00000008 | B_BITMAP_IS_AREA,
 B_BITMAP_IS_CONTIGUOUS         = 0x00000010 | B_BITMAP_IS_LOCKED,
 B_BITMAP_IS_OFFSCREEN          = 0x00000020,
(*) B_BITMAP_WILL_OVERLAY       = 0x00000040 | B_BITMAP_IS_OFFSCREEN,
(*) B_BITMAP_RESERVE_OVERLAY_CHANNEL = 0x00000080
};

Because I wouldn't know how to implement those. :-) If you do, be my guest!!

Never played with those, but if there is support from the driver(every decent driver should have that IMO), it's just a matter of creating a Bitmap with those 2 flags.
Marcus should know of this, I think. (media player and VLC use overlays to play movies)

(both, Thomas' and Rudolf's drivers support overlays)
More info I know: Rudolf's drivers support a maximum of 3 overlays for triple buffering during movies. If another movie is played, it will use normal bitmaps because those 3 overlays are reserved by the first instance of media player.
Now, if one plays a movie and the overlays are reserved we must have a fail-safe solution when dragging something. So we still have to implement transparency by software, I just wanted to point a simpler approach when possible.

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

    I understand.

- draw those directly on screen 

    Yes.

- 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

:-) Ah, but you didn't mention the 3rd buffer. ;-)
To be sure: the 2nd main memory buffer holds the final scene - a region copied from the first buffer composed with the transparent bitmaps above it.

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. 

    Yes, it will not flicker.
        Sounds quite complicated... I don't know what do say...


bye,
Adi.

Other related posts: