[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 15:08:58 +0100
Hi Adi,
> 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.
Adi, you're confusing something. Simple statement: overlay bitmaps cannot be
used in this way. A "video overlay" with respect to movies means something
completely different from what we're talking about (transparent overlays).
I'm sorry, but please understand, it's something completely different.
Also, there is no support in the driver API to allocate something in the
unused graphics memory. At least Rudolf said this, and I have not seen
anything usable either while working briefly on AccelerantHWInterface.
> > 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.
Look what I have written above. No, only the buffer in the graphics memory
holds the final scene. The first main memory buffer and the second main
memory buffer are composed, and the result is written to the graphics buffer
on the fly. The background and the transparent overlay stay apart in two
different buffers. The client can draw to the background, while the
transparency buffer is maintained in the app_server only (where order of
drawing can be enforced).
> > 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...
Well. It is something we can try in the new prototype anyways. At least,
after we completed it as far as the current requirements go. It would be fun
to see Stubears designs possible with the Haiku architecture. Sometimes... In
the future...
Best regards,
-Stephan
Other related posts:
