Bug 103136 - [Regression] Cairo 1.14 downscaling very slow in poppler 0.60.1
Summary: [Regression] Cairo 1.14 downscaling very slow in poppler 0.60.1
Status: RESOLVED FIXED
Alias: None
Product: poppler
Classification: Unclassified
Component: cairo backend (show other bugs)
Version: unspecified
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: poppler-bugs
QA Contact:
URL:
Whiteboard:
Keywords:
: 107225 (view as bug list)
Depends on:
Blocks:
 
Reported: 2017-10-07 14:38 UTC by Emilio Reggi
Modified: 2018-07-27 15:16 UTC (History)
4 users (show)

See Also:
i915 platform:
i915 features:


Attachments
Test File (430.96 KB, application/pdf)
2017-10-10 20:32 UTC, Emilio Reggi
Details
use custom downscaling if scale < 0.5 (1.09 KB, patch)
2017-10-13 21:26 UTC, Adrian Johnson
Details | Splinter Review
Example Document #2 (134.47 KB, application/pdf)
2017-10-16 10:13 UTC, Emilio Reggi
Details

Description Emilio Reggi 2017-10-07 14:38:07 UTC
Summary: Rendering PDF files which contain JBIG2 or CCITT encoded images is comparably slower under poppler 0.60.1 than under 0.56.1

Description: See above. I am using evince 3.26.0. Rendering is considerably slower, that is about 3-4 seconds compared to <1 second with poppler 0.56.1. Downgrading to poppler 0.56.1 resolves this problem.
Comment 1 Albert Astals Cid 2017-10-10 20:05:28 UTC
Attach such a file
Comment 2 Emilio Reggi 2017-10-10 20:32:08 UTC
Created attachment 134782 [details]
Test File

Here is an example file containing JBIG2 images.
Comment 3 Albert Astals Cid 2017-10-12 22:37:11 UTC
cairo backend regression, splash still works fine
Comment 4 Emilio Reggi 2017-10-13 11:49:49 UTC
Thank you for looking into this. How do I use the splash backend instead of cairo?
Comment 5 Adrian Johnson 2017-10-13 21:25:32 UTC
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.
Comment 6 Adrian Johnson 2017-10-13 21:26:39 UTC
Created attachment 134836 [details] [review]
use custom downscaling if scale < 0.5

This patch uses custom downscaling when scale is < 0.5.
Comment 7 Emilio Reggi 2017-10-16 10:13:11 UTC
Created attachment 134861 [details]
Example Document #2
Comment 8 Emilio Reggi 2017-10-16 10:13:48 UTC
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.
Comment 9 Albert Astals Cid 2017-10-16 22:04:06 UTC
@Adrian can you fix the bug title since from your description it seems it has nothing to do with JBIG2/CCITT at all
Comment 10 Carlos Garcia Campos 2017-10-17 10:29:57 UTC
Maybe we should just switch to use GOOD instead of BEST?
Comment 11 Josiah Schwab 2017-11-17 23:52:31 UTC
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?
Comment 12 Carlos Garcia Campos 2018-01-28 08:10:03 UTC
Adrian, what do you think about using GOOD instead of BEST by default?
Comment 13 Attila Schler 2018-02-03 22:29:31 UTC
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.
Comment 14 Attila Schler 2018-02-03 23:23:44 UTC
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.
Comment 15 Josiah Schwab 2018-02-26 21:49:44 UTC
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,
Comment 16 Carlos Garcia Campos 2018-03-04 09:30:55 UTC
Ok, I've switched to use GOOD instead of BEST by default.
Comment 17 code 2018-07-27 15:16:33 UTC
*** Bug 107225 has been marked as a duplicate of this bug. ***


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.