Re: Drawing graphics and responding to events

John,

Thanks for the reply.  The case I have is a very simple one - all the
shapes are on a grid and there is no overlap.  The circles cannot be
moved at runtime.  As far as the bounding rectangles go, I'm not sure I
follow you.  If the mouse moves over the area of a bounding rectangle
that is outside a circle - you know, the area between the bounding
rectangle corner and the circle edge - than no circle should be
'selected'.

As far as the GraphicsPath thing goes, you are right in that it does not
seem to be that responsive.  Of course, it depends to some extent on the
number of circles in the grid (its obviously faster if I have a grid of
4x4 circles instead of a grid of 20x20 circles).

As far as UI constraints, yes, flicker is about the only thing (well,
responsiveness is important, of course).

The user will interact with this 'grid' by selecting circles they want
to include for further processing.  They should be able to 'select' a
circle by either clicking on it or by 'dragging a border around a group
of circles.

Peter

-----Original Message-----
From: Discussion forum for developers using Windows Forms to build apps
and controls [mailto:[email protected]] On Behalf Of
John Brett
Sent: Wednesday, April 25, 2007 5:04 AM
To: [email protected]
Subject: Re: [DOTNET-WINFORMS] Drawing graphics and responding to events

This may be an obvious comment, but it is worth caching the last
selected Circle object and optimizing the very common case in which
the mouse has moved but is still within the same circle.

You don't state any of the constraints on the locations of your
circles - are they
static locations or can they move at run-time? Do the circles ever
overlap their
bounding rectangles, or overlap each other?

If the locations of the circles is static, then you should be able to
speed up the searching process by designating bounding rectangles
around discrete sets of circles - e.g if the circles are approximately
on a grid, then put 20 bounding rectangles around rows of 20 circles.
You can then search the outer bounding rectangles to find the row to
search, and then search only that. This would cut down the number of
comparisons from ~(20*20)/2 to ~(20+20)/2.

If your circles don't ever overlap their bounding rectangles, then
testing the point for inclusion within the rectangle is going to be
the easiest option.

If the bounding rectangles can overlap, then you can determine whether
a point is within a circle by calculating the distance between the
point and the centre, and comparing it with the radius.

<eMail-code>
PointF circlePos;
PointF mousePos;

double distX= (circlePos.X - mousePos.X);
double distY= (circlePos.Y - mousePos.Y);
double distSquared= distX*distX + distY*distY;

if (distSquared < radiusSquared)
{
   // point within circle.
}
</eMail-code>

If the circles can overlap then you need to manage some sort of
Z-order & arbitration if the mouse is over two or more circles.

Using a GraphicsPath gives aesthetically pleasing code, but I doubt
it's going to be as quick as comparing co-ordinates (given that it has
to deal with arbitrarily complex shapes, and you're working with about
the easiest shape to optimise).
BTW - what are your efficiency constraints? Given that this is appears
to be a UI issue, then I'd suggest that the only criteria that matters
is whether the user perceives any flickering or delay whilst moving
the mouse.

John