Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Speed optimizations #33

Open
GoogleCodeExporter opened this issue Mar 24, 2015 · 7 comments
Open

Speed optimizations #33

GoogleCodeExporter opened this issue Mar 24, 2015 · 7 comments

Comments

@GoogleCodeExporter
Copy link

APV is usually fast, and sometimes slow on some PDF files.
It may be related to jpeg decompression.
Maybe some options in libjpeg can be activated to speed up APV (or add an arm 
optimized idct)

Original issue reported on code.google.com by ldro...@gmail.com on 23 Nov 2010 at 10:13

@GoogleCodeExporter
Copy link
Author

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
Copy link
Author

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

@GoogleCodeExporter
Copy link
Author

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
Copy link
Author

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
Copy link
Author

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
Copy link
Author

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

@GoogleCodeExporter
Copy link
Author

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant