| Summary: | slow rendering with gradient pattern | ||
|---|---|---|---|
| Product: | cairo | Reporter: | tristan <kiwitargetgranule> |
| Component: | pdf backend | Assignee: | Adrian Johnson <ajohnson> |
| Status: | RESOLVED FIXED | QA Contact: | cairo-bugs mailing list <cairo-bugs> |
| Severity: | normal | ||
| Priority: | medium | ||
| Version: | 1.8.10 | ||
| Hardware: | x86-64 (AMD64) | ||
| OS: | Linux (All) | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
| Attachments: | testcase | ||
If one circle is not inside the other circle in a radial gradient a fallback image is used in PDF output. This is because in PDF the radial gradients with one circle not inside the other are not the same as the image backend. Fallback images are embedded to ensure the PDF output renders the same as the image. Some PDF viewers are not very efficient at rendering pages with a large number of images. (In reply to comment #1) > If one circle is not inside the other circle in a radial gradient a fallback > image is used in PDF output. This is because in PDF the radial gradients with > one circle not inside the other are not the same as the image backend. Fallback > images are embedded to ensure the PDF output renders the same as the image. > Some PDF viewers are not very efficient at rendering pages with a large number > of images. The rendering in PDF is slow, but the program execution too. Is it normal with those fall-back images mechanism ? Yes it is normal. The fallback images have to be first rendered to an image surface within cairo then embedded in the PDF file. Fixed by: commit 20ef062511e224ef098671c923a4cd4d461139c2 Author: Andrea Canciani <ranma42@gmail.com> Date: Fri Nov 19 20:16:16 2010 +0100 pdf: Unify gradient emitters and support all extend modes. To draw repeated gradients in pdf, which only supports none and pad extended gradients, we need an appropriate reparametrization of the gradients that will cover the whole clip region without needing repeats. This commit adds support for the drawing of reflect/repeat-extended radial gradients through native pdf patterns using pad-extension and no fallbacks. This fixes https://bugs.freedesktop.org/show_bug.cgi?id=28870 Reviewed-by: M Joonas Pihlaja <jpihlaja@cc.helsinki.fi> |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.
Created attachment 36658 [details] testcase With specific gradient pattern parameter and current transformation matrix, the render is slow. Valgrind say {{{ ==3618== Memcheck, a memory error detector ==3618== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al. ==3618== Using Valgrind-3.6.0.SVN-Debian and LibVEX; rerun with -h for copyright info ==3618== Command: ./test ==3618== ==3618== Syscall param write(buf) points to uninitialised byte(s) ==3618== at 0x51904C0: __write_nocancel (syscall-template.S:82) ==3618== by 0x512B132: _IO_file_write@@GLIBC_2.2.5 (fileops.c:1276) ==3618== by 0x512C784: _IO_do_write@@GLIBC_2.2.5 (fileops.c:530) ==3618== by 0x512AD9D: _IO_file_xsputn@@GLIBC_2.2.5 (fileops.c:1358) ==3618== by 0x5120FBC: fwrite (iofwrite.c:45) ==3618== by 0x4E4DC19: stdio_write (cairo-output-stream.c:558) ==3618== by 0x4E4D645: _cairo_output_stream_write (cairo-output-stream.c:266) ==3618== by 0x4E4DFF0: _cairo_output_stream_vprintf (cairo-output-stream.c:515) ==3618== by 0x4E4E5E7: _cairo_output_stream_printf (cairo-output-stream.c:526) ==3618== by 0x4E8CEDA: _cairo_pdf_surface_close_stream (cairo-pdf-surface.c:1104) ==3618== by 0x4E91930: _cairo_pdf_surface_emit_surface_pattern (cairo-pdf-surface.c:1604) ==3618== by 0x4E9309D: _cairo_pdf_surface_show_page (cairo-pdf-surface.c:2982) ==3618== Address 0x4022405 is not stack'd, malloc'd or (recently) free'd ==3618== ==3618== ==3618== HEAP SUMMARY: ==3618== in use at exit: 8,912 bytes in 9 blocks ==3618== total heap usage: 14,188 allocs, 14,179 frees, 460,178,220 bytes allocated ==3618== ==3618== LEAK SUMMARY: ==3618== definitely lost: 0 bytes in 0 blocks ==3618== indirectly lost: 0 bytes in 0 blocks ==3618== possibly lost: 0 bytes in 0 blocks ==3618== still reachable: 8,912 bytes in 9 blocks ==3618== suppressed: 0 bytes in 0 blocks ==3618== Rerun with --leak-check=full to see details of leaked memory ==3618== ==3618== For counts of detected and suppressed errors, rerun with: -v ==3618== Use --track-origins=yes to see where uninitialised values come from ==3618== ERROR SUMMARY: 213 errors from 1 contexts (suppressed: 56148 from 25) }}}