Bug 694585 - inefficient shading with DeviceN colorspace
Summary: inefficient shading with DeviceN colorspace
Status: RESOLVED FIXED
Alias: None
Product: MuPDF
Classification: Unclassified
Component: mupdf (show other bugs)
Version: master
Hardware: PC Windows 7
: P4 normal
Assignee: MuPDF bugs
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-09-10 13:51 UTC by zeniko
Modified: 2014-01-03 12:48 UTC (History)
1 user (show)

See Also:
Customer:
Word Size: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description zeniko 2013-09-10 13:51:34 UTC
http://www.southalabama.edu/mathstat/personal_pages/carter/And_He_Built_a_Crooked_House.pdf contains lots of shades which use a DeviceN colorspace using Type 4 (Postscript) functions. Due to repeated partitioning of the shades, the same conversion functions are called over and over again for the same values which makes MuPDF take over a minute to render whereas Adobe Reader only takes a couple of seconds.

I've experimented with a cache on the DeviceN colorspace so that the latest 32 colors where cached which sped up rendering by about factor 3. That's still far slower than Adobe Reader, though.
Comment 1 Robin Watts 2013-12-30 05:04:14 UTC
I have 2 patches in my repo that reduce the render time to about 40% of what it was.
Comment 2 Robin Watts 2014-01-03 09:42:26 UTC
The following 2 commits get this down to a reasonable speed:

commit 4f5e6c8d18ae2fe2c5aa7d0792aa6fa4e1c92719
Author: Robin Watts <robin.watts@artifex.com>
Date:   Mon Dec 30 12:51:47 2013 +0000

    Bug 694585: Further improve mesh rendering times

    Add a cached color converter mechanism. Use this for rendering meshes
    to speed repeated conversions.

    This reduces a (release build to ppm at default resolution) run from
    23.5s to 13.2 seconds.

commit a80817d4fcc27239fb2efa769ae84c542cbae904
Author: Robin Watts <robin.watts@artifex.com>
Date:   Mon Dec 30 12:30:11 2013 +0000

    Bug 694585: Slow rendering of meshes

    In the existing code for meshes, we decompose the mesh down into
    quads (or triangles) and then call a process routine to actually
    do the work. This process routine typically maps each vertexes
    position/color and plots it.

    As each vertex is used several times by neighbouring patches, this
    results in each vertex being processed several times. The fix in
    this commit is therefore to break the processing into 'prepare' and
    'process' phases. Each vertex is 'prepared' before being used in
    the 'process' phase. This cuts the number of prepare operations in
    half.

    In testing, this reduced the time for a (release build, generating ppm
    at default resolution) run from 33.4s to 23.5s.
Comment 3 Ray Johnston 2014-01-03 12:48:06 UTC
I had thought that in the past Ghostscript mesh rendering was a lot slower
than mupdf, but running mupdf -d (distribution version 1.3) it takes 25.7
seconds, and Ghostscript -sDEVICE=ppmraw -o out.ppm -r72 -dMaxBitmap=300m
(page mode, 72 dpi) takes 3.4 seconds.