davy@pur-ee.UUCP (03/10/87)
<5705@pur-ee.UUCP> cancelled from rn.
davy@pur-ee.UUCP (03/10/87)
[Hopefully the first version of this didn't go out; my apologies to
those of you who see it twice. The corrections involve a bunch of
subtitutions of the word "bitmap" for the word "icon".]
We've been playing with "setxroot" lately, and have come up with a
couple of questions. (For those of you unfamiliar with it, xsetroot
allows you to specify a bitmap to be used as a tiling pattern in the
root window, instead of the default grey.)
The first question involves the size restriction imposed by xsetroot
itself. We wanted to use some of our icons as tiling patterns, and
xsetroot refused to let us use anything larger than 16x16. However,
when we removed this restriction (it's two lines of code in an "else"
clause), things worked perfectly, and we got the expected results. (We
even used a 99x99 bitmap, just for the hell of it, and everything worked
fine.) So, the first question is:
Why does xsetroot impose a limit of 16x16 on the bitmap size?
Our initial thought was that it was intended to be a limit on the size
of the cursor (which xsetroot also allows you to set). Is it just an
error that the check is always performed, or is there some real reason
for this limitation?
The second question deals with bitmap size limitations. In the "bitmap"
manual page, it says that bitmaps are limited to 99x99. The only thing
we could find which enforced this was the XReadBitmapFile subroutine,
which does a
scanf("#define %s_height %2d", ...)
to get the size of the bitmap. We hacked the code to change the "%2d"
to a plain "%d", which allows us to use arbitrary sizes. The main
reason for this was that we wanted to use the rasters for suntools
backgrounds in X (we don't want something suntools can do that X can't,
for Pete's sake!). After writing a program to convert the rasterfile(5)
format to bitmap(1) format, you end up with a bitmap that's 1152x900 or
so. Using xsetroot again, everything seems to work just fine. The
program reads in the bitmap, and displays it perfectly. Granted, the X
server grows in memory size by about half a meg, but it does work.
So, the second question is
Why is 99x99 the limit on bitmap size?
Is there a good reason for this, or did someone just arbitrarily decide
that "that's big enough"? As an aside, it does seem that bitmap(1) does
not work well with bitmaps this big -- the "dot" used as a cursor won't
fit into the teeny-tiny squares when the bitmap is that large.
We'd like to install our changes and send them back to the X folks for
merging into the software, but before we do so we'd like to make sure
there are no reasons not to. Does anyone have any wisdom to impart on this?
--Dave Curry
Purdue University
Engineering Computer Network
davy@intrepid.ecn.purdue.edu