[Waba-spec] More on the graphics bug

[Sean L. <se...@cs...>]

I've checked to see what various JVMs do with regard to metrics for 
rects, ovals, arcs, lines, and roundRects.  The spec is a little obtuse, 
but here's what it appears to say:

0. Clips and filled objects go from (x,y) to (x+width-1,y+width-1) 
INCLUSIVE
1. Filled objects go from (x,y) to (x+width,y+width) INCLUSIVE

While practically every JVM is a little buggy with regard to the extents 
of roundrects, ovals, and arcs (!!), EVERY SINGLE JVM is consistent with 
regard to rects.  Unfortunately, Waba is not.  Waba presently implements 
its drawRect() as going from (x,y) to (x+width,y+width) inclusive.  I 
don't know if this was a bug or an intentional decision, but it's not a 
good thing, that's for dang sure.  Unfortunately, most Waba apps assume 
the incorrect measurements, while all portable Java apps assume the 
correct measurements, which means we may be royally screwed here.

I have created some Java code for people to test with.  The code draws a 
"bounds area", and then draws various objects such that they're supposed 
to fit just within the bounds area so that they just touch (but don't 
overwrite) the bounds area lines.  The objects are first drawn and then 
filled.  The filled version is supposed to fit just inside the drawn 
version and not overwrite it.

Waba for the Newton also appears to not handle clips right -- it's off 
by 1 on the top and left.  I don't know if this is a Newton bug or if 
it's a Waba bug (I only have Newtons); could someone run the code on a 
Palm/WinCE box and let me know?

Here's a version that you can compile and run on your JVM and see what 
it does.  I'd be interested in knowing about how Microsoft JVMs draw the 
ovals, arcs, and roundrects, because all I have here are Solaris, MacOS 
9, and MacOS X 10.1.  Send me some screenshots!