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

[muppet <scott asofyet org>]

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!

http://cpan.uwinnipeg.ca/htdocs/X11-Protocol/X11/Protocol.pm.html

> ['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,  :-)