Bug 103136

Attach such a file

Created attachment 134782 [details]
Test File

Here is an example file containing JBIG2 images.

cairo backend regression, splash still works fine

Thank you for looking into this. How do I use the splash backend instead of cairo?

This is caused by the switch to using cairo downscaling instead of the builtin downscaling.

Running some quick tests it seems the cairo downscaling time is roughly proportional to the source image size while the custom downscaling is closer to the target size. So for downscaling to small scales we are taking a large performance hit.

Created attachment 134836 [details] [review]
use custom downscaling if scale < 0.5

This patch uses custom downscaling when scale is < 0.5.

Created attachment 134861 [details]
Example Document #2

Comment on attachment 134861 [details]
Example Document #2

Thank you very much for the patch! I applied and recompiled poppler against it.
However, it doesn't seem to do the trick; the rendering is still quite slow compared to 0.56.1.
Please find attached another document which is problematic.

@Adrian can you fix the bug title since from your description it seems it has nothing to do with JBIG2/CCITT at all

Maybe we should just switch to use GOOD instead of BEST?

I recently started seeing significant slow downs while navigating through PDF files and I believe it to be this issue.  (The timing is consistent with a upgrade to poppler version 0.61.0 on my machine.)

I began noticing this because it started taking multiple seconds and 100% CPU (core) usage to change between pages or re-zoom pages in PDFs provided by NASA's Astrophysics Data System (e.g. PDF at http://adsabs.harvard.edu/abs/1995ApJ...442..337P).

I viewed the documents attached to this message using emacs pdf-tools and evince (both of which use poppler) and confirm I see the slow behavior.

How would I go about changing GOOD to BEST to see if it helps my use case?

Adrian, what do you think about using GOOD instead of BEST by default?

I found that 0.59.0 is already very slow.
The 0.57.0 works as it should.

I was unable to find a 0.58.0 build for my system.

The problem is still there in 0.62.0.

And I observed that only applications that are using poppler-glib8 are affected like evince, xournal, zathura.

Application that are using libpoppler-qt5-1 works well, like okular, qpdfview.

After 791e024, I was finally able to build poppler.

I made the following change (which I think what was being suggested) and while things are still a bit slow compared to what I remember as the old behavior, it is now usable for me.

 poppler/CairoOutputDev.cc | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/poppler/CairoOutputDev.cc b/poppler/CairoOutputDev.cc
index bc83b807..ffb4a8ee 100644
--- a/poppler/CairoOutputDev.cc
+++ b/poppler/CairoOutputDev.cc
@@ -1970,7 +1970,7 @@ CairoOutputDev::getFilterForSurface(cairo_surface_t *image,
                                    GBool interpolate)
 {
   if (interpolate)
-    return CAIRO_FILTER_BEST;
+    return CAIRO_FILTER_GOOD;
 
   int orig_width = cairo_image_surface_get_width (image);
   int orig_height = cairo_image_surface_get_height (image);
@@ -1990,7 +1990,7 @@ CairoOutputDev::getFilterForSurface(cairo_surface_t *image,
   if (scaled_width / orig_width >= 4 || scaled_height / orig_height >= 4)
          return CAIRO_FILTER_NEAREST;
 
-  return CAIRO_FILTER_BEST;
+  return CAIRO_FILTER_GOOD;
 }
 
 void CairoOutputDev::drawImageMask(GfxState *state, Object *ref, Stream *str,

Ok, I've switched to use GOOD instead of BEST by default.

*** Bug 107225 has been marked as a duplicate of this bug. ***