[cairo] Subject: ImageSurfacePattern disappears with a large enough scale factor
michel_iwaniec at yahoo.com
Tue Nov 4 12:52:27 PST 2008
I have now put together a minimal test example that shows both the bug with the ImageSurfacePattern, and the bug with the grid lines overlaid on it.
You can download it here:
I sure hope this precision limit can be fixed or worked around, rather than being a hard limit in Cairo.
--- On Mon, 11/3/08, Michel Iwaniec <michel_iwaniec at yahoo.com> wrote:
> From: Michel Iwaniec <michel_iwaniec at yahoo.com>
> Subject: Re: [cairo] Subject: ImageSurfacePattern disappears with a large enough scale factor
> To: "Chris Wilson" <chris at chris-wilson.co.uk>
> Cc: cairo at cairographics.org
> Date: Monday, November 3, 2008, 6:34 PM
> Sorry, but I'm not sure if I follow you in your
> explanation about pixman. Are you saying that this pixman
> library is used for one of the situation but not the other?
> In that case, which situation uses it? Rendering to an
> ImageSurface or rendering to an xlib surface?
> And is there some way to make Cairo use the same rendering
> code for an ImageSurface as it does for an xlib surface?
> (since rendering to an xlib surface seems to work way
> // Michel
> --- On Mon, 11/3/08, Chris Wilson
> <chris at chris-wilson.co.uk> wrote:
> > From: Chris Wilson <chris at chris-wilson.co.uk>
> > Subject: Re: [cairo] Subject: ImageSurfacePattern
> disappears with a large enough scale factor
> > To: michel_iwaniec at yahoo.com
> > Cc: cairo at cairographics.org
> > Date: Monday, November 3, 2008, 4:50 PM
> > On Mon, 2008-11-03 at 07:11 -0800, Michel Iwaniec
> > > Unfortunately, I just discovered that I declared
> > victory too early. The patch you pushed merely seems
> to have
> > reverted the situation to the one I had before
> upgrading my
> > Ubuntu distribution.
> > >
> > > Rendering to an ImageSurface instead of my
> > GtkDrawingArea still gives the same problem with the
> > ImageSurfacePattern misaligning and eventually
> > when scaled too much. Which again makes me wonder why
> > result from rendering to an ImageSurface can be so
> > from rendering to a GtkDrawingArea? Exactly what might
> > differ in how cairo handles these targets?
> > >
> > > I will try to create a repro case, but since
> > working on a closed-source application that I'm
> > allowed to share, it might take some time.
> > If you're feeling brave, in the master git branch
> > is a cairo-trace
> > tool that is installed alongside the main library.
> > currently
> > experimental (as in the replay tools are still out of
> > but you can
> > look at some WIP at
> > people.freedesktop.org/~ickle/cairo-script,
> > people.freedesktop.org/~ickle/sphinx, but those seem
> to be
> > at the mercy
> > of the fdo server presently).
> > The trace will capture everything drawn, so it still
> > contain
> > confidential information, but I would appreciate
> > else attempting
> > to use the tool and providing some feedback. :-)
> > As for your particular question: image surfaces used
> > have special
> > casing which caused the entire source to be cloned and
> > bypassed the ROI
> > optimizations and manipulation of the pattern matrix.
> > one aspect of
> > the patch was to remove that and put image surfaces on
> > par with the
> > xlib surface (i.e. the GtkDrawingArea). The second
> > of discrepancy
> > is that cairo uses a 24.8 fixed point format, but
> > (the software
> > renderer) uses a 16.16 fixed point format. In
> particular it
> > sounds like
> > you're hitting an overflow, but it's hard to
> > at this stage if it's
> > possible to workaround/mitigate that condition without
> > clear test
> > case. (Though at some point you will hit the limits of
> > cairo's fixed
> > point representation.)
> > --
> > Chris
More information about the cairo