[cairo] 32k limit with image surface?

[Ian Britten]

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! :)

> 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?
- 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 )

>> 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...)

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)?

> The suggested workaround for this, similar to handling the limited
> texture sizes in OpenGL, is for the application to do its own tiling in
> a layer above a cairo surface. Not perfect, but it may actually improve
> your application's performance... (Positive spin).

Believe it or not, this is sortof what I'm working on!  :)

To simplify the final processing, I'm trying to tile using just one
tile at the desired width, and altering the height to keep the memory
use down.  Thus, I'm trying to create image surfaces in the range of
50000 x 1572 (approx 300M), but encountered this issue.

[ This approach makes it easier to call things like TIFFWriteScanline(),
passing the entire scanline at once, rather than trying to join tiles
together, or producing a tiled TIFF, which isn't wanted for this
project. ]


Many thanks for the information, and for any clarification about
improvements in upcoming releases!
Ian