Speed optimizations

[GoogleCodeExporter]

Speed optimizations

[GoogleCodeExporter]

One speed optimization I just committed was to add -O3 to the lib compile flags 
and compile to arm rather than thumb.  

Can you attach a file where the problem occurs?

Original comment by arpruss on 25 Jul 2011 at 5:37

[GoogleCodeExporter]

All pdf files containing JPEG images are slow to render.
I started to work on this a few months ago, and found that the jpeg idct may 
not be optimized for arm...

Original comment by [email protected] on 27 Jul 2011 at 2:43

[GoogleCodeExporter]

I switched jpeglib to the fast (but less accurate) idct.  I didn't benchmark, 
but it feels slightly faster.  I tried the floating point, but it seemed slower.

Original comment by arpruss on 31 Jul 2011 at 2:50

[GoogleCodeExporter]

Here is a NEON-optimized libjpeg: http://sourceforge.net/projects/libjpeg-turbo/

We'd need to add detection for NEON, and this would only go in the armv7-a 
version of the library.

Original comment by arpruss on 31 Jul 2011 at 3:15

[GoogleCodeExporter]

There was a problem in the threading model which caused the same tiles to get 
rendered multiple times.  The problem was that the cache was checked when the 
tiles were fed to a worker thread rather than just before rendering.  I fixed 
this.

Original comment by arpruss on 31 Jul 2011 at 3:22

[GoogleCodeExporter]

I think that by default, the fast idct is used. But maybe on some CPUs, the fp 
idct is faster ? (good to hear that you found a bug in the cache, I was 
suspecting this but I didn't spot it !)

Original comment by [email protected] on 2 Aug 2011 at 12:26

[GoogleCodeExporter]

I think you're right: the fast one was used.  I switched to float on CPUs that 
have an FPU--I don't know if that improved performance, but at least it should 
improve quality.

Original comment by arpruss on 3 Aug 2011 at 2:48