[<<] [<] Page 1 of 1 [>] [>>] | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
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 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Subject:
Re: nanoX coordinate system
From: Ben Pfaff ####@####.#### Date: 10 May 1999 17:31:32 -0000 Message-Id: <876760q137.fsf@pfaffben.user.msu.edu> Greg Haerr ####@####.#### writes: 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) In my experience, Type 2 systems are usually more convenient for geometric arithmetic; i.e., you only need to say `x2 - x1' to find a dimension, which results in fewer off-by-one adjustments. One way to think of a type 2 system is that the points are between the gridlines rather than centered on the grid intersections. 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. That's the way that X specifies rectangles, actually (width, height). 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. When you try what? Do you mean I should look at a wrapper routine to see something you worked around? | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Subject:
RE: nanoX coordinate system
From: Greg Haerr ####@####.#### Date: 10 May 1999 18:18:00 -0000 Message-Id: <01BE9ADF.5AD733B0.greg@censoft.com> My comments follow... gh On Monday, May 10, 1999 11:36 AM, Ben Pfaff ####@####.#### wrote: > Greg Haerr ####@####.#### writes: > > 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) > > In my experience, Type 2 systems are usually more convenient for > geometric arithmetic; i.e., you only need to say `x2 - x1' to find a > dimension, which results in fewer off-by-one adjustments. > I agree. > One way to think of a type 2 system is that the points are between the > gridlines rather than centered on the grid intersections. Yep. > > 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. > > That's the way that X specifies rectangles, actually (width, height). I kind of like the way that MSWindows specifies them, eg: Ellipse(x1, y1, x2, y2); The two points are the bounding box for the Ellipse. I plan on making this change in internals to nanoX. We will want to keep the upper level API very X-compliant. (I have sneaky plans to implement nanoWin - a small windowing system that implements that Win32 API... This would run on many small systems) > > 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. > > When you try what? Do you mean I should look at a wrapper routine to > see something you worked around? Two things: 1. Uncomment the BOGL_clear() code in drivers/scr_bogl.c. This uses my included bogl driver. It fails on an assert that I didn't have time to look at this morning. 2. Change the LIBBOGL line in the master makefile to use one of your most recent bogl libaries. I would like to use unmodified bogl libraries. Note there are two bugs: 1. recent bogl libraries don't use bogl_ncols anymore. I still use it. 2. bogl_text requres the yy parameter to be adjusted down by font->height. This is because text 0,0 is at the upper left, *not* lower left as you have it. (see drivers/bogl/bogl-cfb8.c for details) Greg > > --------------------------------------------------------------------- > To unsubscribe, e-mail: ####@####.#### > For additional commands, e-mail: ####@####.#### > > | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
[<<] [<] Page 1 of 1 [>] [>>] |