Hi, On Wed, 2010-02-10 at 18:20 +0100, Niels Roest wrote: > When I correctly interpret your patch, for regular JPEGs, it will now > always use the StretchBlit for colour space conversion, whether > accelerated or not. The "old" system will only come into play for > non-444 or 420 colour spaces.
Yes. > Now my thing is this. Using df_stress (with melted.jpg instead of png) I > measured the loop containing RenderTo, both with and without your patch, > and all of a sudden it is, on X, without GLX, 5 times faster. How come? You mean with the patch? > I actually expected a little slowdown, since I assumed caching delays > caused by the separation of decoding and colour conversion (as both were > done previously in libjpeg). If df_stress destroys the provider in between its runs, and thus does a full jpeg decode each time, it would suggest that the way it works with this patch is maybe nicer to the caches? Or/And maybe libjpeg is just inefficient when doing the conversion itself? I mean DirectFB went through a lot of optimisations in the software renderer whereas libjpeg might not have. If df_stress just does multiple RenderTo()s without destroying the image provider, you are measuring different things here - actually your results would imply that dfb_scale_linear (from the old code path for this case) is slower than dfb_gfxcard_stretchblit() in the new code path. Or would the x11 system without glx still give you some kind of acceleration? (I don't think so) It is indeed much much faster if hw acceleration is available. The YUV->RGB conversion in JPEGs is one of the most time consuming parts. Cheers, Andre; _______________________________________________ directfb-dev mailing list directfb-dev@directfb.org http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-dev
