Axel, > Yeah, now that the app_server is done and stable ;-P Cool :) > 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? > > 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!) Although no mediaplayer ever yet actually implemented this, and this is (also) the reason Be's mediaplayer tends to crash on modeswitches (sometimes). > 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. Rudolf.