nanogui: Thread: [Nano-X] PolygonRegion


[<<] [<] Page 1 of 1 [>] [>>]
Subject: [Nano-X] PolygonRegion
From: Murphy Chen ####@####.####
Date: 6 Jun 2000 15:51:28 -0000
Message-Id: <Pine.LNX.4.10.10006062343260.8097-100000@pc120105.ccl.itri.org.tw>

Dear Greg,

	I've added wrapper functions for CreateRegion, DestroyRegion,
	UnionRectWithRegion, UnionRegion and IntersectRegion.
	When I started to add wrapper function for PolygonRegion, I
	found that there's no corresponding function in devrgn.c.
	So, I need to implement one.
	However, current definition of clipping regions is based
	on rectangles.
	In this way, I think it is not easy to implement PolygonRegion.
	I suggest use bitmap for clipping regions instead.
	What do you think about that?

With regards,
Murphy


Subject: Re: [Nano-X] PolygonRegion
From: "Greg Haerr" ####@####.####
Date: 6 Jun 2000 20:59:09 -0000
Message-Id: <072701bfcffa$6db18f70$3017dbd0@censoft.com>

: When I started to add wrapper function for PolygonRegion, I
: found that there's no corresponding function in devrgn.c.
: So, I need to implement one.
: However, current definition of clipping regions is based
: on rectangles.
: In this way, I think it is not easy to implement PolygonRegion.
: I suggest use bitmap for clipping regions instead.
: What do you think about that?

Murphy - 
    No, we don't want to use bitmaps for clipping regions.  The
y-x-banding clip region code is perfectly capable of creating
a polygon-based region.  Think of many rectangles all tiling
the interior area of the polygon.  It is important to always
use the MWCLIPREGION structure for regions, since then
arbitrary regions can always be and/or/xor/excluded from
any other using the existing routines.  So the real problem
is creating the MWCLIPREGION from a set of lines
(polygons).  I can find you some code for this if you are
interested.

Regards,

Greg


Subject: Re: [Nano-X] PolygonRegion
From: Murphy Chen ####@####.####
Date: 7 Jun 2000 00:58:09 -0000
Message-Id: <Pine.LNX.4.10.10006070838460.8578-100000@pc120105.ccl.itri.org.tw>

Dear Greg,

>     No, we don't want to use bitmaps for clipping regions.  The
> y-x-banding clip region code is perfectly capable of creating
> a polygon-based region.  Think of many rectangles all tiling
> the interior area of the polygon.  It is important to always

	My concern is:
	Say, if the polygon region is composed of a triangle shape,
	wouldn't there be too many rectangles for filling
	the triangle? 

> use the MWCLIPREGION structure for regions, since then
> arbitrary regions can always be and/or/xor/excluded from
> any other using the existing routines.  So the real problem
> is creating the MWCLIPREGION from a set of lines
> (polygons).  I can find you some code for this if you are
> interested.

	Great, please send me some. :)

With regards,
Murphy


Subject: Re: [Nano-X] PolygonRegion
From: "tanghao" ####@####.####
Date: 7 Jun 2000 01:46:29 -0000
Message-Id: <009101bfd022$1d9ae860$ba64a8c0@tanghao>

hi,
    Can i share the code? i am interesting on add the wrapper function of region and clip.
when i ported the fltk to nano-x api. it had some problems ,for not having the region function 
in client nano-x api.   

> (polygons).  I can find you some code for this if you are
> interested.
> 
    could youp send me too,thanks .

btw, if interesting ,see my fltk port code at http://townhall.top263.net/fltk-1.0.7.NanoX.s.tar.gz


> : When I started to add wrapper function for PolygonRegion, I
> : found that there's no corresponding function in devrgn.c.
> : So, I need to implement one.
> : However, current definition of clipping regions is based
> : on rectangles.
> : In this way, I think it is not easy to implement PolygonRegion.
> : I suggest use bitmap for clipping regions instead.
> : What do you think about that?
> 
> Murphy - 
>     No, we don't want to use bitmaps for clipping regions.  The
> y-x-banding clip region code is perfectly capable of creating
> a polygon-based region.  Think of many rectangles all tiling
> the interior area of the polygon.  It is important to always
> use the MWCLIPREGION structure for regions, since then
> arbitrary regions can always be and/or/xor/excluded from
> any other using the existing routines.  So the real problem
> is creating the MWCLIPREGION from a set of lines
> (polygons).  I can find you some code for this if you are
> interested.
> 
> Regards,
> 
> Greg
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ####@####.####
> For additional commands, e-mail: ####@####.####
Subject: Re: [Nano-X] PolygonRegion
From: "Greg Haerr" ####@####.####
Date: 7 Jun 2000 02:00:40 -0000
Message-Id: <002001bfd024$8372c480$15320cd0@gregh>

: My concern is:
: Say, if the polygon region is composed of a triangle shape,
: wouldn't there be too many rectangles for filling
: the triangle? 
: 

No - this is how it's done with many windowing systems,
including X11.  At first it seems strange, but then you realize
that absolutely any region can be specified in this manner.  And
the benefit is that you have a single set of region handling routines
that work for all region code in the entire system; as well as getting
tested and/or/xor/exclude code, which is very hard to debug.

At first I used different region handling code for Microwindows.
But then as I was debugging some of the more obscure (no pun
intended) aspects of the system, I realized how cool the y-x-banding
algorithm that X uses is.  The rectangle list is always kept in
y then x sorted order, and no rectangle overlaps another.  In
this way, simpler routines can be used for the region intersection
calculations, and they're actually quite fast, as the y values can be 
skipped over in a quick for loop while not intersection.  Yes,
complex shapes take more memory, but not really that much.  An
interesting test is to printf the size member of the MWCLIPREGION
struct just for kicks using complex shapes.  Also, the way
that Microwindows now works, it recalculates a new MWCLIPREGION
every time that a program wants to display something.  In this
way, the clip region allocation is reused alot between windows.  At
some point, I'm still planning on implementing separate clip regions
per window, which would speed drawing somewhat, at a potentially
larger memory requirement...


: > (polygons).  I can find you some code for this if you are
: > interested.
: 
: Great, please send me some. :)

Ok!  Since your hacking, I better hurry up and find them!

Regards,

Greg



Subject: Re: [Nano-X] PolygonRegion
From: "Greg Haerr" ####@####.####
Date: 7 Jun 2000 02:02:34 -0000
Message-Id: <003301bfd024$c03ebb80$15320cd0@gregh>

: btw, if interesting ,see my fltk port code at
http://townhall.top263.net/fltk-1.0.7.NanoX.s.tar.gz

I am very impressed!  I will definitely add your changes into our
FLTK port that's underway.  Let me know what else you need to
make it work well with Nano-X.

Regards,

Greg


Subject: Re: [Nano-X] PolygonRegion
From: Murphy Chen ####@####.####
Date: 7 Jun 2000 03:06:44 -0000
Message-Id: <Pine.LNX.4.10.10006071051370.8578-101000@pc120105.ccl.itri.org.tw>

Dear TangHao,

>     Can i share the code? i am interesting on add the wrapper function of
> region and clip.

	Here you go.
	Note that the codes currently compiled, but are not tested yet.
	Currently the clipping region related function include:
GR_REGION_ID    GrNewRegion(void);
void            GrDestroyRegion(GR_REGION_ID region);
void            GrUnionRectWithRegion(GR_REGION_ID region, MWRECT *rect);
void            GrUnionRegion(GR_REGION_ID dst_rgn, GR_REGION_ID src_rgn1,
                        GR_REGION_ID src_rgn2);
void            GrIntersectRegion(GR_REGION_ID dst_rgn, GR_REGION_ID src_rgn1,
                        GR_REGION_ID src_rgn2);
void            GrSetGCRegion(GR_GC_ID gc, GR_REGION_ID region);

With regards,
Murphy

Subject: Re: [Nano-X] PolygonRegion
From: "tanghao" ####@####.####
Date: 8 Jun 2000 11:41:12 -0000
Message-Id: <000d01bfd13e$5c60d290$ba64a8c0@tanghao>

hi,    
    i try to use use the Wrapper  api of Region .but actually it alway dump ,when i use every original sample. i think some pointer operation may have problem.but i don't know where.do you find the problems .

and ,i think it maybe should add the following code 

{GrNewRegionWrapper, "GrNewRegion"},
 {GrDestroyRegionWrapper, "GrDestroyRegion"},
 {GrUnionRectWithRegionWrapper, "GrUnionRectWithRegion"},
 {GrUnionRegionWrapper, "GrUnionRegion"},
 {GrIntersectRegionWrapper, "GrIntersectRegion"},
 {GrSetGCRegionWrapper, "GrSetGCRegion"},
 
below the code segment :

struct GrFunction {
 void  (*func)(void *);
 GR_FUNC_NAME  name;
} GrFunctions[] = {

in the file "srvnet.c".

and in the file "srvutil.c"
you add :
regionp = GsFindRegion(gcp->regionid);
GdSetClipRegion(pp->psd, regionp->pregion);

i changed to 
regionp = GsFindRegion(gcp->regionid);
if(regionp)
{
    if(pp)
    GdSetClipRegion(pp->psd, regionp->pregion);
    else
    GdSetClipRegion(wp->psd, regionp->pregion);
}

after those changes ,it don't dump ,but when i added the region clip support "GrSetGCRegion"to the sample "t1demo"
it dump .in the GdDestroyRegion.when free(rgn->rects);

i  trace the code several hours ,but do not find where the problem is.

        regards 
                                                                tanghao


> Dear TangHao,
> 
> >     Can i share the code? i am interesting on add the wrapper function of
> > region and clip.
> 
> Here you go.
> Note that the codes currently compiled, but are not tested yet.
> Currently the clipping region related function include:
> GR_REGION_ID    GrNewRegion(void);
> void            GrDestroyRegion(GR_REGION_ID region);
> void            GrUnionRectWithRegion(GR_REGION_ID region, MWRECT *rect);
> void            GrUnionRegion(GR_REGION_ID dst_rgn, GR_REGION_ID src_rgn1,
>                         GR_REGION_ID src_rgn2);
> void            GrIntersectRegion(GR_REGION_ID dst_rgn, GR_REGION_ID src_rgn1,
>                         GR_REGION_ID src_rgn2);
> void            GrSetGCRegion(GR_GC_ID gc, GR_REGION_ID region);
> 
> With regards,
> Murphy
> 
> 
> 


--------------------------------------------------------------------------------


> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ####@####.####
> For additional commands, e-mail: ####@####.####

[<<] [<] Page 1 of 1 [>] [>>]


Powered by ezmlm-browse 0.20.