Re: is 32767 the maximum dimension for a pixmap, drawingarea, or what?

On Oct 30, 2006, at 1:42 PM, zentara wrote:

I unexpectedly ran into this limit of 32767 pixels when trying to make a huge pixmap graph on a DrawingArea.

I figure it must be in the c libs somewhere. Can someone point out to me if other objects are limited in size, or is it just the pixmap?

See attached example, which runs at 32767, but not 32768.

This is, of course, the behavior of overflowing a signed 16-bit integer.

I see to recall that the windows port of gtk+ has to do some interesting things to work around 16 bit window size limits on win9x. I'm unaware of such limits on X11, and can't find evidence in a quick search of the gtk+ source, but they might be there. The manpage for XCreatePixmap() says the width and height parameters are normal ints.

But, aha!

['CreatePixmap', sub {
     my $self = shift;
     my($pixmap, $drawable, $depth, $w, $h) = @_;
     return pack("LLSS", $pixmap, $drawable, $w, $h), $depth;

This is the source a perl module that implements the X11 wire protocol directly in perl code. He's packing the width and height as "S", or unsigned short, which implies that there is a limit of 16 bits on the size of pixmaps (similarly for windows, ifyou look at CreateWindow).

Now, this is unsigned 16 bit, whose limit is 65535, and you're seeing signed 16 bit behavior, so i don't know what's up there, but it's certainly likely that *somewhere* in the stack somebody's using the unsigned value as a signed and losing you that last (most- significant) bit of size.

Of course, you don't *really* want to create a huge pixmap like that. Pixmaps are server side resources, and it's not cool to create memory-eaters like that. It might actually be that you're failing a malloc() or overflowing in multiplication or something like that in the server. I've found that i get much better performance by implementing a widget that knows how to scroll natively, and updates the exposed regions on demand. This is how the gimp's display window works, for example -- the X window is only as big as the display portion that you see, and everything is rendered and exposed on demand. This is not trivial, but it can be fun and interesting, :-)

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]