On 6/14/07, Chris Bore <[EMAIL PROTECTED]> wrote: > Thanks. > > I was actually thinking of the pointer in DFBSurfaceDescription: > > *data; data pointer of existing buffer > > If I GetSurfaceDescription for a Provider then does this give me a pointer > to their data buffer?
Ah... for image providers, this doesn't give you a data pointer, as the data won't likely exist until you call RenderTo on it. You have to look at the flags field of the surface description to see what items in it are valid, so unless PREALLOCATED is set, that data pointer is garbage. > That seemed a bit to bypass the methods. > Lock() seems fine, although that also might be thought a backdoor way to get > at internal data - at least it is explicit. > > I am also not sure (not having used it this way) what is the risk of > providing an 'existing buffer' when creating a surface? > (I presume the data pointer is null by default and is then ignored). We use "preallocated" surface descriptions a lot in our system... some of our UI widgets use bitmaps that are embedded directly in the library using the directfb-csource tool to go from PNG to header file. _______________________________________________ directfb-users mailing list directfb-users@directfb.org http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-users
