[haiku-appserver] Re: Overlay support

  • From: jonathanthompson@xxxxxxxxxxxxxxxxxxxxxxx
  • To: <haiku-appserver@xxxxxxxxxxxxx>
  • To: <haiku-appserver@xxxxxxxxxxxxx>
  • Date: Sun, 23 Apr 2006 21:17:13 -0400

The earlier discussions of a time value being used and causing things to fail 
just strikes me as sick and wrong, if things aren't available.

I'll use the example scenario in mind, based on the conversation:

1.  A user starts up an application that requires overlay, and it works in a 
given resolution setting.

2.  The user decides to change to a different workspace or resolution in the 
workspace(s) that use the overlay, but for whatever reason, the hardware can't 
accommodate that switch, or requires renegotiating everything.  From what I've 
read, it seems that if there isn't a response within a given amount of time, 
that the application using the overlay is killed, either by choice or by 
default due to things being changed out from under it.  Well, frankly, this 
shouldn't be remotely time-based, at least, not without user intervention.

The scenario there is an effective way of punishing applications that are 
inflexible into an early death, and quite possibly allowing the user to lose 
data, or at least sanity, for doing something they thought they could do 
without harm, such as changing to a different workspace temporarily, or 
changing the resolution of the current workspace, or whatever it is that caused 
the snafu that's limited by reality.  If an application is going to die, even 
when written correctly, the user should always have a choice of choosing to do 
that, or rejecting the change in modes that would force that death: the system 
should not cause a problem where avoidable.

Quite possibly the system is very busy, and the application can't process a 
message ASAP, which may be directly related to the fact that it needed the 
overlay in the first place.  What should have the highest priority?  I say the 
user should choose, and be given that choice if/when they need to make that 
choice.  I feel that it'd be best to keep from yanking the rug out from under 
an application that currently has the overlay, the application that has the 
overlay must explicitly call something that states "Yes, I give up the overlay" 
so it can continue in a sufficiently graceful manner, so things are done in a 
synchronous manner where no race conditions can occur.  Barring the application 
giving explicit permission (this is where the older applications come in) have 
the app_server explicitly ask the user (or take the settings from a 
configuration file for user-defined choices ahead of time) to allow the 
app_server to rip the rug out from under the application, and let the memory 
chips fall where they may.  Thus, the scenario originally shown would change to 

1.  An application has an overlay that it is using.
2.  Something causes that resource to be in conflict to where it has to be 
reallocated, or is no longer available, such as a workspace switch to one with 
a different resolution/color depth.
3.  The app_server sends the message to the application that owns the overlay, 
to warn it of the impending change.
4.  Depending on whether it is an old application or not, it responds by either 
calling the new API function release_overlay() in a timely manner, or the 
app_server asks the user (or consults preferences and finds the one for 
overlays) and acts accordingly, either ripping the rug out from under the 
application, or failing the attempted mode switch that would cause the 
application from losing the overlay.

That is how I see it making sense to work in the most 
backwards-compatible-and-forwards-sensible fashion.

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

Other related posts: