[Waba-spec] More on the graphics bug
Status: Abandoned
Brought to you by:
bornet
From: Sean L. <se...@cs...> - 2001-12-02 22:25:26
|
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! |