[cairo-bugs] [Bug 9064] Weird performance on printing weird rectangles

bugzilla-daemon at freedesktop.org bugzilla-daemon at freedesktop.org
Mon Mar 12 12:35:22 PDT 2007


http://bugs.freedesktop.org/show_bug.cgi?id=9064





------- Comment #4 from cworth at cworth.org  2007-03-12 11:35 PST -------
I'm not very familiar with the specifics of the win32 backend, but I did just
take  a quick look. And it does appear that the current implementation of the
win32 backend doesn't accept geometry for graphics very often.

For example, in the test program here, cairo will first look to see if the
cairo-win32 backend has an implementation of the backend->stroke() function.
But that entry point is NULL, (see the intialization of
cairo_win32_surface_backend near the end of cairo-win32-surface.c, for
example).

Next, cairo attempts to construct a region consisting of rectangles specified
as integers to be filled. If it can successfully do this, then it will call
into the win32 fill_rectangles() function, (which is not NULL). This may be
what is happening when you test with small integer values to cairo_rectangle().

Finally, if that fails as well, (for example, cairo computes non-integers for
the final region), then cairo will fall back to creating a giant image surface
and pushing that to the backend through its composite() backend function. This
may be what you are hitting with your test case.

Various fixes could be done for this problem. For example, simply changing the
tolerance value away from something insanely high, (such as the default 0.1
device pixels), and adding code to attempt rounding if withing the current
tolerance might let the existing fill_rectangles() path handle this case.

More interesting approaches could allow other geometry besides rectangles to be
drawn without falling all the way back to images. For example, if the win32
backend can detect that it is targeting a high-resolution output device, (that
is, a printer rather than a display device), then it might be able to use
something native to implement stroke() directly without sacrificing output
quality. But here, I'm totally guessing as I have no experience with the
capabilities of the APIs that win32 backend calls into.

The best thing I can suggest is to mail the cairo mailing list and ask for what
could be done to improve the win32 backend in some of these directions.
Subscription (which is unfortunately required before posting) instructions are
available here:

        http://cairographics.org/lists

Have fun with cairo,

-Carl


-- 
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.


More information about the cairo-bugs mailing list