Bug 7533 - cairo_surface_set_fallback_resolution is extremely broken in cairo 1.2.0
Summary: cairo_surface_set_fallback_resolution is extremely broken in cairo 1.2.0
Status: RESOLVED FIXED
Alias: None
Product: cairo
Classification: Unclassified
Component: svg backend (show other bugs)
Version: 1.2.0
Hardware: x86 (IA32) Linux (All)
: high blocker
Assignee: Emmanuel Pacaud
QA Contact: cairo-bugs mailing list
URL:
Whiteboard:
Keywords:
: 7571 (view as bug list)
Depends on:
Blocks:
 
Reported: 2006-07-15 10:51 UTC by Michael Urman
Modified: 2006-08-03 19:30 UTC (History)
2 users (show)

See Also:
i915 platform:
i915 features:


Attachments
Original test case ported to C (782 bytes, text/plain)
2006-07-28 13:31 UTC, Carl Worth
Details

Description Michael Urman 2006-07-15 10:51:08 UTC
The following python code sample creates two files: matrixbug.png and
matrixbug.svg. The png is correct, and the svg is transformed incorrectly.
Comment the second stroke to remove the need for an image fallback, and they
both appear identical in eog.

#! /usr/bin/env python

import cairo

surface = cairo.SVGSurface('matrixbug.svg', 120, 120)
cr = cairo.Context(surface)

# this is not necessary to repro; premultiplied coords too.
cr.scale(120, 120)

cr.set_source_rgb(0, 0, 0)
cr.rectangle(0.25, 0.25, 0.5, 0.5)
cr.set_line_width(0.125)
cr.stroke_preserve()

# comment out this stroke to see the png and svg appear the same
cr.set_operator(cairo.OPERATOR_SOURCE)
cr.set_source_rgba(0, 0, 0, 0)
cr.set_line_width(0.0625)
cr.stroke()

surface.write_to_png('matrixbug.png')
cr.show_page()
Comment 1 Carl Worth 2006-07-28 13:31:16 UTC
Created attachment 6381 [details]
Original test case ported to C

Thanks for the report. I ported your test case to C just to make it easier to
look closely with a debugger, (it's nice to see how similar the test is in both
languages).

So I'll actually be doing that closer look very soon.

-Carl
Comment 2 Carl Worth 2006-08-02 17:18:48 UTC
Oh, this bug is worse than I thought.

We actually have a testcase in the test suite already that exercises this bug.
It's the fallback-resolution test. Unfortunately, it's one of those few tests
where we don't do automatic checking, but instead rely on manual verification
that the results are correct, (which we obviously neglected to do before 1.2.0).

The commit that broke this test is the following, just a couple of days before
cairo 1.2.0 was released:

http://gitweb.freedesktop.org/?p=cairo;a=commit;h=bd92eb7f3c58fdcbe05f67b9a879798246c616bc

We need to fix this if we have any hope of cairo-based printing working well at all.

-Carl
Comment 3 Carl Worth 2006-08-03 07:22:50 UTC
*** Bug 7571 has been marked as a duplicate of this bug. ***
Comment 4 Paul Sephton 2006-08-03 08:01:18 UTC
Sorry for submitting duplicates folks, although I saw this report I didn't
realise it was a duplicate.  If you can tell me what needs doing, I can see what
I can do about fixing it.  Afraid I don't know the code very well.
Comment 5 Carl Worth 2006-08-03 09:03:03 UTC
(In reply to comment #4)
> Sorry for submitting duplicates folks, although I saw this report I didn't
> realise it was a duplicate.

Oh, no apology necessary at all. I hadn't realized it was a duplicate either.
Nor had I realized that we had such a bad bug in 1.2. It's all a bit
embarrassing really.

>                             If you can tell me what needs doing, I can see what
> I can do about fixing it.  Afraid I don't know the code very well.

I'll be working on a fix for this right away. I just need to satisfy two
constraints at the same time, (the bug fix the commit above was intending, and
the fallback_resolution behavior the commit above broke). So we have code for
satisfying either constraint separately. And we just need to come up with code
that will satisfy both at the same time.

Behdad suggested perhaps making the meta-surface replay code go through the
gstate interface rather than the surface interface. That might be the cleanest
approach to get correctness in all cases. It might not be the most efficient,
but then again, we already have a lot of inefficiency in the meta-surface code
paths, (like always copying source surfaces), so maybe it wouldn't matter too much.

Again, I'll be looking into this closer today, so don't worry if the above makes
no sense.

And again, thanks for the report!

-Carl
Comment 6 Paul Sephton 2006-08-03 13:44:54 UTC
Nevertheless, I think the meta surface is one of the more brilliant innovations
in cairo, and well done to whoever came up with that idea.  Perhaps, as you say,
the loss in efficiency is worth the gain in symmetry.  These things normally
have a way of panning out when one takes a simple or intuitive approach.  A bit
of extra abstraction goes a long way to eliminating bugs...

Just gotta say, wow guys, well done on cairo!  It's an excellent and well
thought out model, and incredibly easy to use.  Soooo glad it's not irrevocably
tied into pango.
Comment 7 Behdad Esfahbod 2006-08-03 16:31:19 UTC
Pango builds on top of Cairo.  How do you expect cairo to be tied to Pango? :)
Comment 8 Paul Sephton 2006-08-03 16:52:40 UTC
(In reply to comment #7)
> Pango builds on top of Cairo.  How do you expect cairo to be tied to Pango? :)

It's not, and I'm very glad for the fact.  I use cairo primarily for it's
graphics ability, not for it's text.

It's just that I know how much some people have been agitating for adding better
font support- ala pango, and the end of that road is a bloat nightmare (not to
mention idiotic).

I'm very happy with what I have, thanks :)
Comment 9 Carl Worth 2006-08-03 19:30:52 UTC
I've pushed out a fix for this now:

http://gitweb.freedesktop.org/?p=cairo;a=commit;h=1feb4291cf7813494355459bb547eec604c54ffb

It fixes the fallback-resolution test case and I verified it also fixes the test
case attached to this bug. Please verify it fixes any other cases of interest.

-Carl

PS. As it turns out, we didn't pipe meta-surface replaying through the gstate
layer. Instead we just put the old device_transform code from the surface layer
into the replay itself. It was all quite easy in fact.


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.