Hi Andre,
thanks again for the patches you're sending.
Just had a quick swirl with this one but I am a little puzzled.
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.
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?
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).
Any thoughts anyone?
Greets
Niels
Andre DRASZIK wrote:
Attached an updated patch...
On Thu, 2009-12-10 at 19:52 +0000, Andre Draszik wrote:
Hi,
Using libjpeg's raw decode facility, we can make it output planar YUV
4:4:4 (the new DSPF_YUV444P) or 4:2:0 (DSPF_I420) and then use the
graphics card to do the YUV->RGB conversion.
This will greatly increase speed when this type of acceleration is
available in the gfxdriver.
Andre'
------------------------------------------------------------------------
_______________________________________________
directfb-dev mailing list
directfb-dev@directfb.org
http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-dev
--
.------------------------------------------.
| DirectFB - Hardware accelerated graphics |
| http://www.directfb.org/ |
"------------------------------------------"
_______________________________________________
directfb-dev mailing list
directfb-dev@directfb.org
http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-dev
