Hi, "Henric Andersson" <[EMAIL PROTECTED]> writes:
> 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* ! you could flip only the changed regions instead. This will copy them from the back to the frontbuffer. If the area updated between two flips is reasonably small, this approach shouldn't be too slow. > > 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? It can be used thru DirectFB. Take a look at the API reference; there are quite a few commands dealing with multiple display layers. Display layers are escecially interesting for OSD displays and thus some cards offer to display video in a dedicated video display layer. Most of the typical PC graphics cards don't have additional display layers however or their use is poorly documented. Salut, Sven -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe directfb-dev" as subject.
