On Tue, 2002-11-05 at 05:54, Henric Andersson wrote: > > > This is getting stranger still... It seems that the FlipBuffer function > in > > > the savage driver isn't used. Instead, it falls back to the generic > > > framebuffer thingy. Whats more, savagefb has primary and a secondary > layer > > > ?? And only the primary layer is used (it seems) and that would explain > some > > > of the strange behaviour. But not all... far from it. The secondary > layer > > > seems to "lock" the user into 640x480 display? Go figure.... > > > > > > Does someone know what all this means? The source isn't exactly filled > with > > > comments :( > > > > > The primary Layer is the framebuffer. Other layers are extras that are > > not supported by fbdev, for instance Video Overlay. > > Ah... well, that explains why I found it... started to get a bit confused > especially since I couldn't find any documentation on this at all :) > > > So all DirectFB drivers will have a Primary layer, and the default flip > > command is fbdev's pan_display, if supported. > > Which it is... the drawback of this is that any changes currently visible > will disappear and be replaced with the new changes on the nonvisible > buffer. It makes kinda sense now that I think of it (remembering the good > old Amiga & AMOS Double Buffer command combined with Swap Buffer :)) > > So essentially, when the pan display command doesn't work, the emulation > isn't correct since the display shouldn't be copied, it should be exchanged. > This is truely a pain in the ------ since I now have to rewrite most of my > program to work this way *DOH* ! > The preferred behavior, as Sven mentioned, is case #1. To support case #1 with a driver that does not support display panning will be too expensive. Ie, you will need a triple buffering scheme (copy front to third, copy back to front, copy third to back).
If you do want the behavior of case #2, then issue a Flip with a DSFLIP_BLIT flag. (See Sven's reply). This does negate the benefits of the flip though. > > Other layers, because they are extras, need to have device-specific > > hooks. In this case the FlipBuffer() function that you see is probably > > for the Secondary Layer. Most of drivers that has a secondary layer > > issues a dfb_surface_flip_buffers() before doing anything else. This > > does _not_ call pan_display, but just swap the front and backbuffer > > pointers. The actual flip will be done by the driver itself. > > So, the secondary layer cannot be used when running in framebuffer then? Or > am I mistaken? Explicitly request for it. When you enumerate all the layers/surfaces, anything with an id != 0 is not Primary (I think). Get the surface capabilities of each, and if it suits your application, request for it. Tony -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe directfb-dev" as subject.
