[haiku-appserver] Re: Overlay support
- From: "Axel Dörfler" <axeld@xxxxxxxxxxxxxxxx>
- To: haiku-appserver@xxxxxxxxxxxxx
- Date: Sun, 23 Apr 2006 18:31:01 +0200 CEST
"Rudolf" <drivers.be-hold@xxxxxxxxxxxx> wrote:
> > Thinking about this, this must be the LockBits() thing in BBitmap.
> > You must only access the overlay buffer when you hold the lock, and
> > you
> > must refresh its pointer everytime you locked the buffer.
> Or update the pointer after the start message from the appserver. And
> check for NULL I'd say.
My AppDefs.h (from Dano, dunno about R5) defines the following
messages:
B_ACQUIRE_OVERLAY_LOCK
B_RELEASE_OVERLAY_LOCK
which are obviously what happens in that case. All they do is asking
the application to release the lock they currently have (or ask them to
lock again if they still want to). This saves you some acquire_sem()
calls, and thus trips to the kernel.
> And you (app) must release the lock as soon as the app_server sends
> you
> the stop message, or it will make you segfault. (ah, that's why
> mediaplayer segfaults.. ;-)
Well, what an application needs is the following:
1) a hint when I must unlock the bits, and another when when I can lock
them again. This could also be understood as a hint towards pausing and
resuming rendering (ie. in case the video is hidden).
2) a notice when my overlay channel got lost (ie. because the new
display mode doesn't support overlay anymore).
While the 2 messages above solve 1), they don't touch 2) at all. I
think we have two options to deal with this:
a) let LockBits() fail - this should be a convincing hint to
renegotiate your overlay connection.
b) let Bits() return NULL
Since b) would let older correctly written apps crash, I would consider
a) the better version. We may also need to come up with a mechanism to
let applications survive that don't support the messages above (but
calling LockBits()/UnlockBits() frequently).
Ie. if the mode switches, video overlay might be gone for a fraction of
a second only - there is probably no point in unlocking the bits
between the mode switch (but that could be done, of course). OTOH if
the workspace changes, and the video is no longer visible, it wouldn't
been right to hold the lock for so long. If the application supports
the two messages this wouldn't be a problem, of course. But if its
doesn't (and I guess no existing will), we might need the application
another buffer it can play with for the time being. This could be
solved entirely client-side, though, with BBitmap allocating such a
buffer on the fly.
> I guess it might turn out interesting to reverse engineer the media
> player :)
:-)
> > But that's probably not what most implementations do. Anyway, I'll
> > implement it like this, does that sound right to you? :-)
> With all the stuff I just told you done correctly, yes. :-)
>
> It's very true, we don't have a single correct mediaplayer outthere
> concerning overlay. This has been a problem always: there must be a
> reference design in the future. It has been tiresome at times to keep
> writing this kind of emails..
I guess proper documentation would have worked, too, though :-)
But since we're open source, we don't get around providing the
reference implementation, anyway.
Bye,
Axel.
Other related posts:
