nanogui: nanoX coordinate system
Subject:
nanoX coordinate system
From:
Greg Haerr ####@####.####
Date:
10 May 1999 17:11:33 -0000
Message-Id: <01BE9AD6.25CEA0D0.greg@censoft.com>
There are some issues to be resolved with the nanoX coordinate system.
I thought I'd post this, although Ben and I are working to resolve this.
Graphics coordinate systems typically come in one of two flavors:
DrawLine(x1, y1, x2, y2); - draw a line from (x1, y1) to (x2, y2)
Type 1 systems draw a line *including* (x2, y2)
Type 2 systems draw a line *not including* the last point (x2, y2)
FillRect(x1, y1, x2, y2) - fill a rectangle defined by upper left and lower right corners.
Type 1 systems define the rectangle's width and height to include
the point (x2, y2). This means that
width = x2 - x1 + 1;
height = y2 - y1 + 1;
Type 2 systems use the x1,y1 and x2,y2 as a "bounding rectangle" that
"encloses" the rectangle. This means that:
width = x2 - x1;
height = y2 - y1;
NanoX currently uses type 1. Bogl uses Type 2. For comparison,
MS-Windows uses type 2. I don't know what X uses.
For upper level api's there is a third type, that has width and height passed
rather than using x2, y2. NanoX uses this, but I plan to change it. this goes
for Ellipse specification as well.
My feeling is that type 2 systems are the way to go, because rectangles
are described by two points in a bounding box, rather than width and height. Also,
in 0-based coordinate systems, x2,y2 is the width and height, rather than having to
calculate it. Ms-Windows gdi programming is easy because of this.
Currently, nanoX uses the type 1 specification, and we need the flexibility of using
drivers that are written to type 2.
Ben: bogl currently aborts() when I try this. Check out BOGL_fillrect for details.
Comments?
Greg
