Seeking advice - how to handle mouse events on custom drawn shapes

  • Thread starter Thread starter trant
  • Start date Start date
T

trant

I have a program which draws rectangular ships onto a very large image.

To accomplish this the best way I knew how was to extend a Panel into a
custom panel and I overrode the Paint method. I draw all my shapes to an
image in another method and then w/ double buffering draw that prepared image
everytime Paint is called.

Now I'd like to implement mouse events for my shapes and am wondering what
would be the best approach - most economical and easiest.

The rendered image is always sufficiently larger than the viewable area
meaning scrollbars will always come into play. So the brute force method of
just iterating through all my shapes and seeing if the mouse x,Y is inside
their boundaries seems quite the poor choice but I dont really know a better
way without much experience in this.

What would you do in this situation?
 
trant said:
I have a program which draws rectangular ships onto a very large image.

To accomplish this the best way I knew how was to extend a Panel into a
custom panel and I overrode the Paint method. I draw all my shapes to an
image in another method and then w/ double buffering draw that prepared image
everytime Paint is called.

Now I'd like to implement mouse events for my shapes and am wondering what
would be the best approach - most economical and easiest.

The rendered image is always sufficiently larger than the viewable area
meaning scrollbars will always come into play. So the brute force method of
just iterating through all my shapes and seeing if the mouse x,Y is inside
their boundaries seems quite the poor choice but I dont really know a better
way without much experience in this.

What would you do in this situation?
Click to expand...

The presence or lack of scroll-bars doesn't really affect your
hit-testing overhead per se. Once you normalize the mouse coordinates
to your world coordinate system for your image, it's as if the
scrollbars aren't even there.

I would implement the brute-force approach first and see if it's okay.
Your cost of hit-testing rectangles is affected mainly by the number of
rectangles, not their distribution across the image. Granted, a larger
image may support more rectangles, but you should be able to enumerate a
very large number of rectangles for hit-testing before it becomes a
significant processing load (hundreds, maybe even thousands, shouldn't
really be an issue).

If after implementing the brute-force approach, you find you have
performance problems related to the hit-testing, then you can look at
things like partitioning your rectangles for hit-testing, so that you
have to examine only a smaller subset (e.g. use some kind of quad-tree
so that you can rapidly isolate those that are visible, or calculate the
visible subset during rendering, and then only hit-test rectangles you
know are on-screen, that sort of thing).

Pete
 
Back
Top