nanogui: Thread: nanoX coordinate system


[<<] [<] 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 [>] [>>]


Powered by ezmlm-browse 0.20.