Hi,
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).
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...
You really think decorator it would look so bad without AA corners?
Adi.
