[cairo] Subject: ImageSurfacePattern disappears with a large enough scale factor

[Michel Iwaniec]

Thank you for looking into this, but the improvements seem to do very little for my test case. While the image does not disappear any more, its position becomes random when zooming in just a little more beyond the initial test condition.

To see why I need a zoom level that might seem insanely large at first, consider this screenshot:
http://www.student.itn.liu.se/~miciw347/resample_example_mpm.png

What I have here is a high-resolution image (represented by the blue grid) that should be resampled into the low-resolution image (represented by the orange grid, and the drawn ImageSurfacePattern). So it is important for me to be able to visualize which pixels in the high-resolution image will affect a pixel in the low-resolution image.

I can certainly understand the performance argument. But since the rendered image just becomes a random mess beyond a certain upscaling, I would suggest an approach where a ROI is extracted conditionally only when the upscaling is large enough. Or maybe at least have a "prefer quality" switch somewhere that does this. My GUI doesn't have very high performance requirements and trying to implement lots of work-arounds due to bad precision seems like an akward solution.

Considering a more long-term solution, are there any plans to increase Pixman's precision anytime soon? 16.16 fixed point seems rather restrictive in this day and age.

Regards,
Michel


--- On Wed, 11/5/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: Wednesday, November 5, 2008, 12:54 PM
> On Tue, 2008-11-04 at 12:52 -0800, Michel Iwaniec wrote:
> > 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:
> >
> http://www.student.itn.liu.se/~miciw347/cairo_scaling_bug.tar.gz
> > 
> > I sure hope this precision limit can be fixed or
> worked around, rather than being a hard limit in Cairo.
> 
> At the moment, the residual source of error seems to be a
> loss-of-precision when converting to the pixman matrix.
> [pixman is the
> software renderer used by cairo when rendering to image
> surfaces and
> used by the Xserver for the unaccelerated paths.] I've
> added a test case
> that exhibits similar behaviour to your example and
> I've minimised the
> error as much as I can. The differentiation between the two
> surface
> patterns is due to the xlib backend extracting a small
> subsurface when
> presented with an image pattern which reduces the
> coordinates and
> mitigates the precision loss. Renderering via the image
> surface, the
> whole surface is used as the source [i.e. no copying or
> allocation
> involved] but then the coordinates overflow when passed to
> pixman.
> (Again I've mitigated that by splitting the coordinates
> between the
> pattern matrix and the offset). I'm not inclined to
> always extract the
> sub-surface as a work-around to this issue as it incurs a
> performance
> for the more common cases. (Though I feel like it should be
> possible to
> cheaply extract a ROI and maintain the use of small
> integers for the
> indices, though I've not yet decided where that should
> be performed.) As
> it stands with the default condition in your test-case
> I've reduced the
> error to around a 2-pixel offset.
> 
> Thanks for the test case!
> -- 
> Chris