Mathieu Routhier wrote: > Hi guys, > > > > I would like to draw your attention to a problem in the DirectFB > interfaces that can become important in some situations. The problem is > that IDirectFBSurface is lacking accessor methods (“Get” functions) for > such things as Color, Clip, BlittingFlags, DrawingFlags and PorterDuff.
The idea was that an interface to a surface is used by only one party directly that knows about or can keep track of the relevant properties itself, either using the same types or more probably in a higher level form, e.g. GdkColor or AlphaComposite. > In my particular context, I’m writing a library to help with drawing > primitives inside DirectFB surfaces. What if, for instance, my library > has to: > > - set PorterDuff > > - draw something > > - restore the original PorterDuff rule for the caller I don't think (or feel) that such a model is efficient if you have lots of drawing operations compared to the overhead produced by having an additional interface (state) for the library. If you want to share the state between the application and the library you could have separate functions for transition between the lib and app usage. So the state is restored only if really required. > In this context, since it’s impossible for the lib to restore the > original state using the current interface, after the lib has done its > job of messing with the graphics state, the caller would find itself in > a different context and, hooooooo, bad things could happen. Yeah. Not if the app and lib arrange with each other for messing with it :) > While looking for a solution, I found out it was possible to create a > SubSurface in order to get a copy of the graphics context, and thus not > having to restore anything in the original surface. Although, I’m > guessing it would be faster and “straighter to the point” if there were > accessors to allow for manually restoring only the states that were > modified. Anyway, let me know what you think of adding these functions > in the current interface. Is this a good idea? I'm not sure if it's faster to restore the state everytime. Imagine this: ) library call - change - draw - restore ) library call - change - draw - restore ) library call - change - draw - restore ) library call - change - draw - restore This causes the hardware state to be programmed for the state item once for each call. But with this: ) library call - change - draw ) library call . keep - draw ) library call . keep - draw ) library call . keep - draw You save calls, state changes and only program the hardware once. However, your approach is more efficient in this scenario: - application's draw ) library call - change - draw - restore - application's draw ) library call - change - draw - restore - application's draw ) library call - change - draw - restore - application's draw ) library call - change - draw - restore - application's draw -- 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
