Shachar Kaufman wrote: > Thanks Niels, you answers shed a lot of new light on the topics I've > been confused about. > Let me see if I got this straight now: We're getting there :) > > 1. If I want to enforce special allocation limitations for layer-tied > surfaces (or allocate them differently altogether from non-tied > surfaces) I should register surface pool callbacks with > "dfb_surface_pool_initialize" during "driver_init_device", handle > allocation similarly to fbdev surface pool, falling back to the core > directfb surface manager for surfaces which are not layer-tied (that > is, surfaces of type layer)? and the core manager simply allocates > from a chunk of contiguous given to it, adhering to card limitations > of offset and pitch alignment? (since I'm using the devmem system, > who's surface pool always falls back to the core manager, I must > register my own surface pool callbacks) > Basically, yes. At InitPool() you need to fill CoreSurfacePoolDescription with your specific restrictions. pitch and offset alignment I'm not 100% sure. > 2. SetRegion simply binds a layer to a layer typed surface? > Yes, afaik. > 3. So layer typed surfaces inherit the double-buffered-ness of the > layer they are tied to? > Yes, you can say that. Since you have 1 surface tied to 1 layer carrying 1-2-3 buffers, it's a matter of definition who's inheriting what.
-- .------------------------------------------. | 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
