utterly terrible performance of Canvas rect items

[Paul Davis <pbd op net>]

i created 7 rects on a canvas. they are all sized at 10x1000000
units. they do not overlap, they lie on the left edge of the canvas. 
the canvas is antialiased.

updating this canvas on expose events is so impossibly slow that its
hard to believe. it can take 10 seconds on a PII-450 to draw the
entire 600 pixel's worth of the canvas's visible width. my processor
loads spike dramatically. 

the performance problem goes away when we make the rects a more
"reasonable" size of just 10x1000 units. this doesn't help my problem,
since i actually need rects that are 10 x ULONG_MAX units in size.

i've looked at the code, and it all seems to devolve to the
libart_lgpl routines. these seem to be doing a large amount of work
for a rect, which could just use an extremely simple macro such as
PAINT_BOX() from one of the early versions of one of Havoc's projects
(i forget the name; it does RGB painting directly into the Canvas
buffer).

does anyone know if this has been fixed in the latest Canvas/libart
code, or is this one of those performance features that wasn't noticed
because nobody anticipated such huge (wide) canvas items?

--p