kicad-developers team mailing list archive
-
kicad-developers team
-
Mailing list archive
-
Message #03952
Re: wxGCDC (was Re: Re: R2217 bugs)
-
To:
kicad-devel@xxxxxxxxxxxxxxx
-
From:
"Torsten Hüter" <torstenhtr@...>
-
Date:
Tue, 19 Jan 2010 20:40:13 +0100
-
In-reply-to:
<4B54A93B.7060506@...>
Hi Dick,
> Hit testing does not have to be fast, since it is usually in response to
> a mouse click and the user can only click so fast. Using a transform in
> the hit test is not out of the question, but as I said, I would like
> some younger brain power on this.
Hit testing should be done by the application and not by the graphics backend in my opionion. You have a world and a screen coordinate system,
you need only to know the transformation. That's in our case a affine transformation, thus a simple matrix can be used. Anything else is pretty straigth forward: get the point
in screen coordinates, transform it to world coordinates and make the hit test (no big deal, there are standard algorithms for testing of a point is inside a convex polygon)
I had to write for university an 3D scanline renderer from scratch with Gouraud & Phong Shading, I'm sure that's more complex :)
Wayne,
>wxDC provides CalculateBoundingBox(), MinX(), MinY(), MaxX(), and MaxY()
>and wxGraphicsPath provides Contains() and GetBox() for hit testing.
>These are determined by where the object is drawn on the context in
>logical (drawing) coordinates.
However, that's not enough when pads are rotated or if you have irregular shapes - IMHO much better if the application manages this and the graphics backend is used really only for rendering of the graphics.
Also for detection of the distance between graphics objects there are some good algorithms existing -
I'm playing currently with one that could make perhaps the implementation of the DRC cleaner.
>1) Move all of the drawing code in gr_basic.cpp into KicadGraphicContext
>and eliminate the global variable ActiveScreen.
>2) Perform all of the scaling, Y axis polarity inversion, and transforms
>in KicadGraphicContext.
>3) Move all of the coordinate offset code calculations into
>KicadGraphicContext.
>4) Add the clipping rectangle to KicadGraphicContext and remove it form
>the parameter list of all the drawing object draw methods.
>5) Use the same wxDC method names for setting, getting, and transforming
>coordinates between device (screen in Kicad) and logical (drawing in Kicad).
Yes, that's exactly a graphics abstraction layer that I'd like, you're specify the objects in world coordinates,
the graphics layer does all the transformation, clipping and displaying. This way it should be easy to support
different backends.
--
Although I thing new a 2D library has a low priority, I'll spend my time first at the things that decrease
my working speed, like the missing hotkeys, also to get used to the KiCad code.
Bye..
Torsten
--
Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla Firefox 3.5 -
sicherer, schneller und einfacher! http://portal.gmx.net/de/go/atbrowser
Follow ups
References