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.