Repository navigation
Print: send 24bpp bands so v4 (XPS) drivers don't get RGBA images - #6395
Merged
Merged
Conversation
A 32bpp band is spooled as an RGBA PNG by the GDI-to-XPS conversion even though print renders are opaque; v4 drivers render that more slowly than RGB. Pass bands through PixmapToBgr(); palette DIBs are unchanged.
prompt: fix nits in PR 6395 and merge it Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Member
|
Merged, thanks! The spool measurements made this easy to evaluate. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
With a v4 (XPS-based) printer driver, Windows converts each bitmap SumatraPDF blits into a PNG in the XPS spool file. A 32bpp band becomes an RGBA PNG even though every pixel is opaque, and the driver renders RGBA images more slowly than RGB ones.
This passes each rendered band through the existing
PixmapToBgr()beforeBlitPixmap(), so the driver gets 24bpp bits and the spool holds RGB PNGs. Print renders carry no transparency (keepAlphaandtransparentBackdropare off for print), so the pixels are the same. 8bpp palette DIBs come back fromPixmapToBgr()unchanged.This changes the GDI path (
-print-to, the classic dialog, selections). The Windows 11 dialog renders through Direct2D and is not changed.Measurements. Master at 80d7528, x64 Release. A 9-page Letter PDF (text and photos) printed with
-print-toat 600 dpi to an HP Color LaserJet M555 queue with HP's v4 driver ("HP Color LaserJet M554-M555 PCL-6") on a FILE: port. The queue was paused while SumatraPDF spooled and resumed afterwards, to time the two parts separately (2 runs each):Sending each spool file to the queue again unchanged, 5 times each: master 20.3-32.0 s (median 26.3 s), this PR 13.5-25.3 s (median 14.3 s).
Printing normally (the driver renders while SumatraPDF spools), whole job: master 41.1-47.9 s (3 runs), this PR 38.9-41.3 s (2 runs); on this machine spooling hides most of the driver's time.
With
-print-settings stretch(bands go throughStretchDIBitsinstead ofStretchBlt), whole job, one run each: master 74.3 s, this PR 39.2 s.Output is unchanged. At 1:1, each spool holds 66 band images of 5100x822: the 65 RGBA bands in master's spool (alpha 255 everywhere) are RGB in this PR's spool with identical pixels, and the one 8-bit palette band is the same in both. With stretch, all 64 band images are identical as well.
Related: #373. With 3.6.1, which sends one full-page 32bpp bitmap per page, this document's spool took 229 s to render on the same driver, and 7 s with only the alpha channel removed from its PNGs (one run each).