[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 17:25:07 +0100
On 2005-11-27 at 15:41:17 [+0100], Adi Oanca <adioanca@xxxxxxxxx> wrote:
> Hi,
>
> Stephan Aßmus wrote:
> > 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.
>
> I know. You are talking about BView overlays. AFAIUnderstood. But you
> also were talking dragging something with the mouse. And in this case
> only, HW overlays can be used.
You're confusing me. Video overlays have nothing to do with alpha blending.
They can not be used in this way. They usually even have a different
colorspace.
> > 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 is (optional)support to allocate a limited number of bitmaps in
> video mem - 3 to be more exact. We could use this for dragging things.
> Yes, this is very limited and there are no hooks to allocate additional
> graphics memory.
I don't know, we might be able to "trick" the driver into allocating stuff
for us in the unused video memory by allocating overlays, which we don't
intend to use as such. But then there is no API to alpha blend an area from
offscreen video memory to onscreen video memory. (Or is there?) And what
about the case when you actually want to use a _video_ overlay?!? Can't have
both "fake" and "real" video overlays at the same time, I'd guess.
> >>>- 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).
>
> :-) When I read your previous mail I thought in two ways. First is the
> one that I wrote in my previous mail, 2nd is the one you describe here.
> Did not wrote about it because you said: "Should not flicker the least".
> In fact it will flicker. You first have to copy the image from the 1st
> main mem buffer (the one with opaque data) and then copy from the
> transparency buffer. It will flicker.
No, you don't understand. It will not flicker. Flickering is when you first
draw something onscreen and then draw something else on top of it (like you
say, but that's not how it would work). I am meaning to draw someting only
once. A + B = C. A and B are main memory, C is graphics memory. You don't
have to do C = A; C += B. You can do A + B = C straight away. Therefor, C is
only changed once, to the final result, so there is no flickering.
> > 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?
I do think it makes quite a difference. In fact, I would not like rounded
corners without anti aliasing. Especially if the BView drawing already has
it. If it is not doable in a fast enough way, I would rather stick to hard
corners.
Best regards,
-Stephan
Other related posts:
