gEDA-dev: PCB rendering performance

[der Mouse]

> I hope nobody has been putting many brain cycles into the PCB
> rendering slowness I mentioned a little while back.  [...]

> [...] if I [...], then the machine crashes.

I now know what's going on here, and yes, it has nothing to do with
PCB - well, except that PCB happened to tickle it.  It's a bug in the X
server, collaborating with something only partially characterized at
the OS level.  When the X server is asked to draw a line that (a) is
unusually long in the vertical direction (two or three thousand pixels
is enough in my case - this is independent of how many pixels high the
display is), (b) is wide, (c) is neither horizontal nor vertical, and
(d) is clipped by a shape more complex than a simple rectangle, then
the code path taken involves allocating some arrays on the stack,
arrays whose size is linear in the (pre-clipping) Y dimension of the
line.  The server runs out of stack and crashes; when the OS tries to
dump its core, something goes wrong that wedges the machine - I suspect
this is related to its having the framebuffer memory-mapped, and
probably the particular framebuffer in use.  Certainly setting the
coredumpsize limit for the X server process to zero makes the machine
stop wedging, just taking down the X server instead.

I am mildly curious how widespread the bug is.  If anyone has a
suitable crash-and-burn machine and would care to try it, the source to
my test program is on ftp.rodents.montreal.qc.ca:/mouse/misc/crash-X.c
(needs gcc to compile; link with -lXext -lX11 -lm).

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse at rodents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B