[cairo] 32k limit with image surface?

[Carl Worth]

On Thu, 2009-07-30 at 09:08 -0300, Ian Britten wrote:
> Chris Wilson wrote:
> > Help me... Can't resist.... WORKSFORME™.
> > 
> > So all you have to do then is run my experimental tessellator branch,
> > that also includes stroke-using-spans.
> 
> :)
> I realize I'm not running the latest/greatest HEAD, but do I gather
> that a future version (1.10?) will behave better then?  If so, I'm
> looking forward to the next major/official release then! :)

Yes, at some point in the future Chris will get his experimental stuff
cooked up and rolled into a final release. I don't know if that will
happen before 1.10, but we can certainly hope so!

> > The issue you have run across here is the 16-bit (16.16 fixed point)
> > coordinate limitation with using pixman to rasterise trapezoids. Hence
> > why by performing the rastiseration ourselves using the span polygon
> > rasteriser we avoid this particular bug, but only on this occasion.
> > 16-bit coordinates are also a fundamental limitation of the X protocol.
> 
> Sorry for the naive questions, but I'm not a cairo developer, and not
> familiar with the implementation details:
> - Does pixman use X for it's work?  I thought the image surface was
>    device/OS independent?  I'm familiar with the X limitation, but I'm
>    not using X directly myself anywhere.  Or were you just pointing out
>    the prevalence of this 32k limitation?

No, pixman doesn't use X.

But, the code that is now pixman began its life inside the X server,
(where there's a hard-and-fast, long-existing
no-image-shall-be-larger-than-16-bits-per-coordinate limit).

So this limit does affect the image backend, (which uses pixman), while
of course also affecting the xlib backend, (which uses the X server,
which also, in turn, uses pixman).

In Chris's experimental branch, he's no longer using cairo's new span
rasterizer rather than pixman's trapezoid rasterizer, and thus avoiding
the limit.

Of course, that's a side effect of other work he's doing, and not the
original intent. So it may not be that all such limits end up being
worked around even with his work.

> - I'm semi-certain I've also seen this behaviour when rendering image
>    data to an image surface, and not just vector data - Does that change
>    anything?  (I'm not sure when trapezoids are rasterized ... :P )

Image data to an image surface *might* invoke trapezoids. An easy way
for that to happen would be if you established some geometry for a clip.
But even without that, cairo might go through an optimization where it
notices that you're doing some rectangular paint() operation and it's
possible that it represents that rectangle with a trapezoid at some
point.

So it's pretty easy to bump into the limit.

> >> So the bug is surface-specific, affecting at least the image surface.
> > 
> > Cairo uses 24.8 fixed point coordinates internally (having changed over
> > from 16.16 for the 1.6 release), so will itself suffer range errors with
> > surfaces greater than ~8 million device units.
> 
> So... Are you saying (in HEAD) there is NOT a 32k limit, and that I
> should be able to make an image surface up to ~8 million pixels wide?
> (Not that I would go that big...)

Since cairo was built up around pixman originally[*], it originally used
a 16.16-bit fixed-point format for storing all coordinates internally.
For the cairo 1.6 release, we changed this to use 24.8-bit fixed-point
integers instead. This fixed many bugs.

But pixman still uses 16.16-bit fixed-point integers, so cairo has to
convert to that for some operations (such as trapezoid rasterization),
which can be buggy due to data loss as you've noticed. So to eliminate
more bugs we will want to either teach pixman to accept 24.8-bit
integers instead, or else code things up in such a way to avoid all
16.16-bit interfaces in pixman for the image backend.

[*] Well, if you want to be pedantic, cairo was originally built up
around the Xrender library which in turn talked to an X server which
included the code that would eventually get pulled out to become pixman.
So close enough.

> And on a separate note - If there is a limit present, should that not
> maybe be documented somewhere (eg: cairo_image_surface_create())?
> And, shouldn't an error be being raised if it's exceeded  (eg:
> CAIRO_STATUS_SIZE_ERROR)?

Yes, we probably should do both of these things. Care to help implement
that?

-Carl

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.cairographics.org/archives/cairo/attachments/20090731/0345ce6c/attachment.pgp