Summary: | annotation: highlight is rendered completely opaque in mupdf app (text is invisible under highlight area) | ||
---|---|---|---|
Product: | MuPDF | Reporter: | Ger Hobbelt <ger> |
Component: | mupdf | Assignee: | MuPDF bugs <mupdf-bugs> |
Status: | RESOLVED INVALID | ||
Severity: | normal | CC: | ger |
Priority: | P4 | ||
Version: | master | ||
Hardware: | PC | ||
OS: | Windows 10 | ||
Customer: | Word Size: | --- | |
Attachments: | the hightlight-annot PDF used for testing |
Description
Ger Hobbelt
2021-05-22 23:50:24 UTC
Created attachment 21009 [details]
the hightlight-annot PDF used for testing
here's the test PDF.
What is this 'pdf' viewer you mention? The yellow highlights render fine with mupdf-gl, mupdf-x11, and mutool draw both with and without the display list enabled. <ashamed/> I've finally found time to do a deep debug session. Turns out it's my own patch from a long time ago that caused this by (as an undesired side effect) ignoring GROUP-START nodes, while still rendering the primitives in that group. As annotations' highlight is rendered using blendmode=MULTIPLY (`FZ_BLEND_MULTIPLY`) and this is signaled in the surrounding GROUP node in the mupdf list device, my code would render the highlight in NORMAL blendmode instead, resulting in a fully opaque yellow layer of paint being applied. Sincere apologies for barking up the wrong tree in this issue and wasting your time. Git blame: Culprit commit: https://github.com/GerHobbelt/mupdf/commit/165d4088305fefc4880acf6f5535254cd8b83d5c * Work done re https://bugs.ghostscript.com/show_bug.cgi?id=701945 :: using the profiler (MSVC2019, Win10/64) it turns out that the *big* CPU consumers are the fz_knockout_begin() and fz_knockout_end() calls, clocking in at a lump sum of >92% of total CPU used. [...] |