Jason BARSTOW wrote: > > > > I'm looking at the function void dfb_gfxcard_batchblit( DFBRectangle > *rects, DFBPoint *points, int num, CardState *state ) > It appears that for the HW path all blits must succeed or none. > > This is because > a) the SW path would (re)iterate all entries > b) and the var 'hw' is only returned from the last hw path blit anyway.
That's right, it's not correctly implemented. It should switch to sw mode and back to hw mode in case an entry is not supported. > I have a surface format for which I may not be able to support overlapped > blits, I thought for BatchBlit I might have been able to punt just the ones > that overlapped. > It seems though that I will have to provide a BatchBlit function > handler/implementation and validate the whole list in my gfxdriver (for > this format) - punting all or none. > Is my conclusion correct? Having a BatchBlit() in the driver API might be a good idea anyways, but I think it would be nicer to accelerate those entries supported instead of falling back to software completely... unless these are very small blits causing too much overhead switching hw/sw, especially because of the hw sync each time. -- 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
