Jason BARSTOW wrote: > > > >> Are you implementing the driver on top of another API that provides its >> own allocation of the data? That's not really supported by the current >> surface core design, but a design which allows implementation even on >> top of OpenGL is being made, well, not actively right now :( > > I am allowing directFB to manage video mem allocs itself. I've provided a > primaryAllocateSurface callback and this itself calls dfb_surface_create > with CSP_VIDEOMEMORY. > However there is state I must set up for my private API to use before I can > run an accelerated operation using a Surface Buffer (eg. fill, blit etc). > I'd like to create this state object and have it bound 1:1 with the > SurfaceBuffer. Currently I can create it everytime its needed, buts this is > not efficient.
Sure. Do you think some callbacks in the graphics driver API like AddBuffer() and RemoveBuffer() or maybe RegisterBuffer() and UnregisterBuffer() would be sufficient? Do you need other notifications like buffer resized etc? > This does lead me to another question - that I was going to explore today, > but I guess I should just ask: > I believe that the design currently expects video memory to be memory > mapped (via the system backend driver), so that directFB can twiddle bits > directly (and manage video mem surfaces itself). So, I think this means > that the logical surface formats have strictly defined physical formats - > i.e. I can't represent a particular format in an arbitrary way. > Is that right? Yes, to support the software fallback routines and applications using IDirectFBSurface::Lock()/Unlock() the buffer needs to have the exact format. >>> There can't be anything faster than adding a dedicated and reserved >>> storage in the object itself :) >>> >>> Otherwise, I guess they have a fast hash table for that. > >> True, adding a storage member is faster, but it also adds complexity >> to the interface. However, if we're adding accessors to the surface >> state, then more complexity probably isn't too bad, especially if it >> allows quick operation for drivers. > > The problem I can see with using a hash map on the CoreSurface or > SurfaceBuffer ptr is that there doesn't appear to be a call back for > surface deletion - correct me if I'm wrong. > So, if the ptr might be reused this would lead to problems. Mmmm, though I > can trap that occurance in my primaryAllocateSurface callback, so perhaps > this isn't so much of a problem. The AllocateSurface() in your layer implementation is only used for allocation of the layer surface. Any other surface is handled by the surface manager only, right now. -- Best regards, Denis Oliver Kropp .------------------------------------------. | DirectFB - Hardware accelerated graphics | | http://www.directfb.org/ | "------------------------------------------" _______________________________________________ directfb-dev mailing list [email protected] http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-dev
