FreeLists / haiku-appserver / [haiku-appserver] Re: Overlay support

["Axel Dörfler" <axeld@xxxxxxxxxxxxxxxx>]

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