> 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?
I'll provide some more context:
My backend API funcs look like this:
MyBlit( CMyBuffer* pBuffer, ... )
Currently I must create a CMyBuffer struct that represents the
SurfaceBuffer - the state it encompasses is video addr, width, height,
format, stride.
If any of these change I must recreate or at least update the CMyBuffer
struct.
Considerations:
A. How to map CMyBuffer to SurfaceBuffer:
i. Use hash map and manage lifetimes privately.
ii. Private void* member ptr in SurfaceBuffer
B. How to know when SurfaceBuffer is in existance:
i. Create CMyBuffer for new occurance of SurfaceBuffer (if
SurfaceBuffer void* pDriverPrv is NULL or not found in hash map table).
- BUT! How to know when SurfaceBuffer is destroyed.
ii. DFB core provides registration callbacks:
RegisterBuffer,UnregisterBuffer.
C. How to know if SurfaceBuffer state changes:
i. Check state on any use - and recreate CMyBuffer on any change.
ii. DFB core to provide callbacks for specific state changes (e.g.
ResizeBuffer)
iii. DFB core to provide a single callback for any state change (e.g.
ReconfigureBuffer).
Personally, I like Aii, Bii and Ciii.
i.e.
Private void* member in SurfaceBuffer
Registration callbacks: RegisterBuffer, UnregisterBuffer
Reconfig callbacks: ReconfigureBuffer
Hope this makes sense.
Regards,
Jason Barstow.
_______________________________________________
directfb-dev mailing list
[email protected]
http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-dev
