Soeren,
Soeren Sandmann wrote:
I think it should be safe to use size_t in create_bits() along with new
functions pixman_multiply/add_overflows_size() if you want to fix this.
I guess I'll try my hand at that.
However, not that pixman is still limited to 16.16 bits of coordinate
space in various places, so you wouldn't gain that much. This 16 bit
limitation is something that we would like to get rid of, however.
Out of curiosity, exactly how large are the images you are trying to create?
The first use case I had was actually only very slightly above the
limit; I tried to generate something that was about 24000x32000 pixels.
In cairo 1.10, you actually can create a 16 bit image, and it is stored
internally in a 16 bit data type.
I'll have a look at that too and perhaps use whichever way gives me the
least pain. The 16-bit data type should allow bitmaps of roughly 32k x
32k without hitting the coordinate space limit, that would already be an
advantage, and the loss of colour space would probably not be too bad
for my application.
Just to give some background, what I'm doing is creating raster street
map images from OpenStreetMap data; I generate an SVG and have it
rasterized with rsvg/cairo. If you want a full map of a large city where
all the road names are still readable, you quickly approach the sizes
I'm talking about here. I know, printing this stuff would mean we're
doing 1200 dpi on an A0 printer, but there are indeed use cases where
I'm asked to produce such extra-large images. As I said, I can get
around the limits by tweaking the SVG viewport, rendering a few tiles
and pasting them (and one day I'll probably script that...) but somehow
I sat there and wondered why I have to do that if the machine has
endless RAM and 64 bit addressing.
Bye
Frederik
--
Frederik Ramm ## eMail frede...@remote.org ## N49°00'09" E008°23'33"
_______________________________________________
Pixman mailing list
Pixman@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/pixman
