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

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

Hi Rudolf,

"Rudolf" <drivers.be-hold@xxxxxxxxxxxx> wrote:
> > Yeah, now that the app_server is done and stable ;-P
> Cool :)

That was actually a joke, but... well, at least it's pretty usable 
indeed :-)

> > Well, I still don't see the purpose, though. All that matters are 
> > overlay channels - and those you get by calling B_ALLOCATE_OVERLAY. 
> > This one should just fail if there aren't any more channels to give 
> > away.
> Well, it's the same mechanism as with acc engines! There is also a 
> hook 
> for this, or am i mistaken?

AFAICT it's a very different mechanism. Acquiring an engine should 
actually block when it's currently in use, while reserving an overlay 
channel will just fail - and that's the very purpose of it.

> > > BTW: please remember to ask for the hooks after every new mode 
> > > set... (just like as it is with acceleration hooks)
> > I don't think this make any sense. The overlay buffers are created 
> > when the bitmap is created - they will stay there no matter what
> > display mode is currently shown.
> No, they will be deleted, and recreated after the modeswitch: 
> courtesy 
> of app_server. The applications gets informed about modeswitches via 
> special messages sent by the app_server (try to locate them, they 
> exist!)

Ah, that's very nice! That relieves the memory management in the driver 
quite a bit.
But even if those messages exist, there is no sign of a proper locking 
scheme when this is done - which would need to be very similar than the 
direct window mechanism.
Theoretically, the app would need to acknowledge to the app_server that 
it stopped filling the overlay buffer. I also don't think that the 
BBitmap base pointer will be updated in that case, which would be just 
broken. I'll investigate into this a bit.

> Although no mediaplayer ever yet actually implemented this, and this 
> is 
> (also) the reason Be's mediaplayer tends to crash on modeswitches 
> (sometimes).

I don't understand this, though. The overlay buffer is located on the 
graphics card - it's part of the mapped frame buffer. Therefore, it 
doesn't go away on a mode change, just the relative position to the 
start of that buffer may change.

> > They will also keep there overlay channel as long as they want. The 
> > only hook that would make sense to ask again for is 
> > B_CONFIGURE_OVERLAY and B_GET_OVERLAY_CONSTRAINTS.
> > The other hooks just must stay the same 
> The overlay channel is also released and -re-aquired on modeswithces. 
> IT really must be done, since the memory map inside the drivers can 
> change drastically because of modeswitches: buffers will almost 
> certainly NOT be recreated at the same locations.

Sure, but that would just be a requirement of the driver's memory 
management - which could certainly be solved. Of course, it would be 
much easier to go the other way around.
If the overlay channel is released on mode switch there might be a race 
condition that another overlay bitmap could be created that steals it.
The real problem of B_OVERLAY_COUNT is that it has this display_mode 
argument - as if the app_server could do anything about it when the new 
mode supports a different number of overlays - it would need to trigger 
the client to renegotiate its overlay bitmaps (ie. recreate them).

Bye,
   Axel.