Open GoogleCodeExporter opened 9 years ago
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
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 ldro...@gmail.com
on 27 Jul 2011 at 2:43
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
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
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
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 ldro...@gmail.com
on 2 Aug 2011 at 12:26
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
Original issue reported on code.google.com by
ldro...@gmail.com
on 23 Nov 2010 at 10:13