When viewing the PDF attached to earlier bug https://bugs.ghostscript.com/show_bug.cgi?id=702993 in both mupdf applications 'mupdf-gl' and 'mupdf', then the yellow highlight shows up all right in 'mupdf-gl', while the 'pdf' viewer paints a bunch of **completely opaque** yellow strips instead. I've tried to find out what makes the difference but couldn't find it. What I did observe is that when you exchange the render order in 'mupdf' by using this order: fz_run_page_annots(app->ctx, app->page, mdev, fz_identity, &cookie); fz_run_page_contents(app->ctx, app->page, mdev, fz_identity, &cookie); in pdfapp_loadpage(), then the rendered page image matched the one rendered by mupdf-gl, at least visually. (I expect subtle differences and here I did swap the render order so the yellow highlight stripes are now part of the "background" from the rendered text -- this was a blunt hack to see if there was anything less subtle going on. While bug report https://bugs.ghostscript.com/show_bug.cgi?id=702993 has been marked as SOLVED, this (related?) issue still remains. Tested on Windows 10/64, but I expect this to be an issue across all platforms. The only difference I observed between the 2 apps which might be significant here is that 'mupdf-gl' uses a bitmap output device (gl-main.c::render_page()-->fz_new_draw_device()) while the 'mupdf' app uses a displaylist device (pdfapp.c::pdfapp_loadpage()-->fz_new_display_list())
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. [...]