Hi, Denis Oliver Kropp wrote: > On 12/16/2010 06:32 AM, Strelchun, Timothy wrote: >>> Unless a rectangle is too large to fit into a hardware's >>> limitations, why do you think switching between CPU/GPU would >>> be something that happens regularly? >> Well fallbacks have been a viable way to handle odd cases like >> the one you mentioned, or if there's a precision issue when a >> dest rect is not fully inside a dest surface's area. The >> frequency of specifying a configuration a graphic driver might >> not handle well is highly dependent on end user content and >> scenario driven, not too mention how skilled a developers is, >> or how much time a developer has to perform performance >> optimizations, or even have good knowledge of DFB or the DFB >> app that is being ported. These considerations lead me to >> think it ideal to make the best performance as automated as >> possible. > > That's true. I just had an application that was drawing with > alpha of zero (SrcOver), which is not discarded by DirectFB.
But the batch operations don't change the state. The state is either accelerated or not. Except for areas that are too big h/w acceleration will work, once the state was set. So I don't see why the code should be more complicated... In addition, the correct approach would be to fully make use of the card capabilities. There are fields to define the max. sizes of rectangles a driver supports. DirectFB could use these to split huge rectangles into smaller ones >> path of StretchBlit. It would simply allow a graphics driver >> to indicate if it needs the 1:1 rects specified in a >> BatchStretchBlit to be handled by the standard 1:1 Blit code >> path. > > I'd prefer to have some driver flag like CCF_STRETCHBLIT_AS_GOOD_AS_BLIT :) ok, I'll add that... Cheers, Andre' _______________________________________________ directfb-dev mailing list directfb-dev@directfb.org http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-dev
