Morning from Holland :) > "Rudolf" <drivers.be-hold@xxxxxxxxxxxx> wrote: > > Hi, about that engine count hook for overlay: > > > > It must be that this should be used by app_Server to find out if a > > new > > mode will support overlay or not: so it can inform the app using > > overlay? > > Sure, it could be used for that, but B_ALLOCATE_OVERLAY will also > just > fail when they ran out of options :-) Very true. > > I can imagine I should check the mode, and (VIA example) return > > zero > > if > > the driver can't do it because of RAM constraints? (size, speed) > > Just a thought. > > Note that this hook is never called yet though. > > I'll still need to revise the way B_BITMAP_RESERVE_OVERLAY_CHANNEL is > handled in the app_server, so I might even end up using that call for > that - dunno yet, though. If I can get around it, I will (to keep the > driver interface as clean and small as possible). What I understand of this flag is this: - there are two ways to work with overlay. 1.You create 3 (doublebuffered) ovelray BBitmaps of which the first has the RESERVE_OVERLAY_CHANNEL flag set. Now you can show them onscreen, by calling BView.SetViewOverlay() with the B_OVERLAY_TRANSFER_CHANNEL flag set. 2.You create 3 (doublebuffered) overlay BBitmaps, none of them has the RESERVER_OVERLAY_CHANNEL flag set. Now you can show them onscreen, by calling BView.SetViewOverlay() with the B_OVERLAY_TRANSFER_CHANNEL flag set. The app_server will now automatically 'reserve the ovelray channel' before 'showing the bitmap'. For the first method only _one_ bitmap may have the RESERVE_OVERLAY_CHANNEL flag set, because you want to use one ovelray engine. Every time you set that flag when a bitmap is created, you ask for an extra engine. Since most cards just have one engine (and there are no drivers for multiple engines yet) creating the second and third bitmap will _fail_. Just ventilating what tests have shown me in the past, because it can't hurt to have a knowledge 'doubecheck' in place . :) Bye! Rudolf.