Tweak the QueueOptimizer to recognize OPS.paintImageMaskXObject operators as *repeated* when the "skew" transformation matrix elements are non-zero (issue 8078)
#12016
Conversation
…perators as *repeated* when the "skew" transformation matrix elements are non-zero (issue 8078) *First of all, I should mention that my understanding of the finer details of the `QueueOptimizer` (and its related `CanvasGraphics` methods) is somewhat limited.* Hence I'm not sure if there's actually a very good reason for *only* considering ImageMasks where the "skew" transformation matrix elements are zero as *repeated*, however simply looking at the code I just don't see why these elements cannot be non-zero as long as they are *all identical* for the ImageMasks. Furthermore, looking at the *group* case (which is what we're currently falling back to), there's no particular limitation placed upon the transformation matrix elements. While this patch obviously isn't enough to *completely* fix the issue, since there should be a visible Pattern rendered as well[1], it seem (at least to me) like enough of an improvement that submitting this is justified. With these changes the referenced PDF document will no longer hang the *entire* browser, and rendering also finishes in a *reasonable* time (< 10 seconds for me) which seem fine given the *huge* number of identical inline images present.[2] --- [1] Temporarily changing the Pattern to a solid color *does* render the correct/expected area, which suggests that the remaining problem is a pre-existing issue related to the Pattern-handling itself rather than the `QueueOptimizer` functionality. [2] The document isn't exactly rendered immediately in e.g. Adobe Reader either.
Snuffleupagus
changed the title
QueueOptimizer to recognize repeated OPS.paintImageMaskXObject operators as *repeated* when the "skew" transformation matrix elements are non-zero (issue 8078)QueueOptimizer to recognize OPS.paintImageMaskXObject operators as *repeated* when the "skew" transformation matrix elements are non-zero (issue 8078)
Snuffleupagus
force-pushed
the
issue-8078
branch
from
4adfe12 to
e18fa3f
Compare
|
/botio-linux preview |
From: Bot.io (Linux m4)ReceivedCommand cmd_preview from @Snuffleupagus received. Current queue size: 0 Live output at: http://54.67.70.0:8877/3fb1f331ab88e39/output.txt |
From: Bot.io (Linux m4)SuccessFull output at http://54.67.70.0:8877/3fb1f331ab88e39/output.txt Total script time: 3.40 mins Published |
|
/botio test |
From: Bot.io (Linux m4)ReceivedCommand cmd_test from @Snuffleupagus received. Current queue size: 0 Live output at: http://54.67.70.0:8877/0fb13af53a3eb98/output.txt |
From: Bot.io (Windows)ReceivedCommand cmd_test from @Snuffleupagus received. Current queue size: 0 Live output at: http://54.215.176.217:8877/6ab8786b1493c4d/output.txt |
From: Bot.io (Linux m4)FailedFull output at http://54.67.70.0:8877/0fb13af53a3eb98/output.txt Total script time: 25.72 mins
Image differences available at: http://54.67.70.0:8877/0fb13af53a3eb98/reftest-analyzer.html#web=eq.log |
From: Bot.io (Windows)FailedFull output at http://54.215.176.217:8877/6ab8786b1493c4d/output.txt Total script time: 29.29 mins
Image differences available at: http://54.215.176.217:8877/6ab8786b1493c4d/reftest-analyzer.html#web=eq.log |
|
This is a clear improvement in rendering time. Thank you! /botio makeref |
From: Bot.io (Linux m4)ReceivedCommand cmd_makeref from @timvandermeij received. Current queue size: 0 Live output at: http://54.67.70.0:8877/bb95301a171f3b9/output.txt |
From: Bot.io (Windows)ReceivedCommand cmd_makeref from @timvandermeij received. Current queue size: 1 Live output at: http://54.215.176.217:8877/d2bd0791d5bb61c/output.txt |
From: Bot.io (Linux m4)SuccessFull output at http://54.67.70.0:8877/bb95301a171f3b9/output.txt Total script time: 24.21 mins
|
From: Bot.io (Windows)SuccessFull output at http://54.215.176.217:8877/d2bd0791d5bb61c/output.txt Total script time: 26.25 mins
|
First of all, I should mention that my understanding of the finer details of the
QueueOptimizer(and its relatedCanvasGraphicsmethods) is somewhat limited.Hence I'm not sure if there's actually a very good reason for only considering ImageMasks where the "skew" transformation matrix elements are zero as repeated, however simply looking at the code I just don't see why these elements cannot be non-zero as long as they are all identical for the ImageMasks.
Furthermore, looking at the group case (which is what we're currently falling back to), there's no particular limitation placed upon the transformation matrix elements.
While this patch obviously isn't enough to completely fix the issue, since there should be a visible Pattern rendered as well[1], it seem (at least to me) like enough of an improvement that submitting this is justified.
With these changes the referenced PDF document will no longer hang the entire browser, and rendering also finishes in a reasonable time (< 10 seconds for me) which seem fine given the huge number of identical inline images present.[2]
[1] Temporarily changing the Pattern to a solid color does render the correct/expected area, which suggests that the remaining problem is a pre-existing issue related to the Pattern-handling itself rather than the
QueueOptimizerfunctionality.[2] The document isn't exactly rendered immediately in e.g. Adobe Reader either.