Shachar Kaufman wrote: > > On Tue, Nov 11, 2008 at 6:15 PM, Niels Roest <[EMAIL PROTECTED] > <mailto:[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? > Ok, the layer-surface coupling is done by DirectFB. You first provide a default, using i830.* as an example.. config->buffermode = DLBM_FRONTONLY; Then, if something is to change or to be displayed, DirectFB will call with something like: ovlSetRegion( ...,CoreSurface *surface,...) which contains your surface. You can also disallow changing the default by providing an implementation to: ovTestRegion() where you simply return failure to disallow clients to change the layer config. In this way you can override whatever is present in the directfbrc config.
To create a non-layer-tied HW buffer you do something like IDirectFB->CreateSurface(), and then, on the resulting surface, obtain the buffer pointer (as suggested/provided/acquired by DirectFB) you do IDirectFBSurface->Lock(). > I am also still confused about double buffering - layer has a > "buffermode" field. Surface capabilities have a "DSCAPS_DOUBLE" option. Hope the above clarified this too. > ------------------------------------------------------------------------ > > _______________________________________________ > directfb-users mailing list > directfb-users@directfb.org > http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-users > -- .------------------------------------------. | DirectFB - Hardware accelerated graphics | | http://www.directfb.org/ | "------------------------------------------" _______________________________________________ directfb-users mailing list directfb-users@directfb.org http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-users
