On Tue, Nov 11, 2008 at 6:15 PM, Niels Roest <[EMAIL PROTECTED]> wrote:
> A surface manager is used to manage surfaces, not buffers. You can not > manage buffers separately. > The concept is layered. > At the top is the screen - what you are watching. > Below are the layer(s) - these are normally the display layers of your > hardware. > Then you get the surfaces. Surfaces are flexible, so they can be tied to a > layer - one surface to one layer - or they can be used as a generic drawing > canvas. Example: you create a surface, fill it with tux.png, and then blit > from this surface to a layer surface as much penguins as you like (df_andi). > A surface manager can manage these surfaces. In a complex system you can > have multiple types of memory, like GPU, CPU, different memory speeds; you > can define a surface manager for each of these cases, and DirectFB will, > when a surface is created by the user, look for the optimal manager to query > for a surface (+buffer(s)). I'm still missing something here: 1. I can control the configuration of the screen (capabilities including number of layers etc') by providing my own callbacks with the "my_screen = dfb_screens_register(..)" which I use in my "driver_init_driver". 2. I can control the configuration of layers for that screen (including number of regions but nothing about surfaces that I noticed) by providing my own callbacks with "dfb_layers_register(my_screen, ...)" But where do I then control surfaces for the layer? How do I have a layer "tied" as you say to a certain surface, and how do I let DFB create the "off-screen" (using X nomenclature) surfaces on my non-layer-tied HW buffer? I am also still confused about double buffering - layer has a "buffermode" field. Surface capabilities have a "DSCAPS_DOUBLE" option.
_______________________________________________ directfb-users mailing list directfb-users@directfb.org http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-users
