| hit-test support for overlapping shapes [message #169679] |
Fri, 25 February 2005 12:25  |
Eclipse User |
|
|
|
Originally posted by: alnospammajor.noboxspamspoon.com
i have a situation where i need to hit-test shapes with overlapping
bounding rectangles. i want to find the shape which is the "closest" to
the cursor based on distance from the shape outline to the cursor.
i imagine this must be a common enough requirement. has anyone got code
that does this?
regards,
al
|
|
|
| Re: hit-test support for overlapping shapes [message #169687 is a reply to message #169679] |
Fri, 25 February 2005 12:35  |
| Eclipse User |
|
|
|
Originally posted by: alnospammajor.noboxspamspoon.com
Al Major wrote:
> i have a situation where i need to hit-test shapes with overlapping
> bounding rectangles. i want to find the shape which is the "closest" to
> the cursor based on distance from the shape outline to the cursor.
>
> i imagine this must be a common enough requirement. has anyone got code
> that does this?
>
> regards,
>
> al
let me clarify this a bit. i want to find a shape whose outline is
within (a small) distance X from the cursor. this requires finding the
minimum distance from the cursor to each shape in the collection.
regards,
al
|
|
|
|
| Re: hit-test support for overlapping shapes [message #169740 is a reply to message #169679] |
Sat, 26 February 2005 09:27 |
| Eclipse User |
|
|
|
Originally posted by: alnospammajor.noboxspamspoon.com
having looked through the code for Figure, i'm assuming that
hit-test'ing on lines and curves (shape outline) does not come
out-of-the-box. so i'll probably have to roll my own.
am i correct in assuming that i need to sub-class Figure and override
one or more of
findFigureAt
findDescendantAtExcluding
findMouseEventTargetAt
findMouseEventTargetInDescendantsAt
regards,
al
|
|
|
| Re: hit-test support for overlapping shapes [message #169770 is a reply to message #169740] |
Sun, 27 February 2005 02:29 |
| Eclipse User |
|
|
|
Originally posted by: none.us.ibm.com
A non-rectangular figure needs to override containsPoint().
To find shapes near the cursor, you could try various points around the
cursor, perhaps in the shape of an X, and then compare all of the results.
A custom figure search can be used to generate a "pick list" if multiple
shapes full under a given point. The technique would be to never accept one
single figure, but build up a list of all figures under a given point.
"Al Major" <alnospammajor@noboxspamspoon.com> wrote in message
news:cvpfff$h7a$1@www.eclipse.org...
> having looked through the code for Figure, i'm assuming that hit-test'ing
> on lines and curves (shape outline) does not come out-of-the-box. so i'll
> probably have to roll my own.
>
> am i correct in assuming that i need to sub-class Figure and override one
> or more of
>
> findFigureAt
> findDescendantAtExcluding
> findMouseEventTargetAt
> findMouseEventTargetInDescendantsAt
>
> regards,
>
> al
|
|
|
| Re: hit-test support for overlapping shapes [message #169778 is a reply to message #169770] |
Sun, 27 February 2005 05:47 |
| Eclipse User |
|
|
|
Originally posted by: alnospammajor.noboxspamspoon.com
Randy Hudson wrote:
> A non-rectangular figure needs to override containsPoint().
>
i'm not sure this is sufficient. the semantics seem tricky. i have the
impression that GEF implicitly constrains the descendants of a figure to
lie within the area of the figure (or at least it's bounding rectangle).
the problem is that in in my case, i want to hit-test the _outline_
rather than the _area contained in_. if i rewrite containsPoint() to
test against the outline, it may return false even if the location lies
within the bounds of the figure. the way that findFigureAt currently
works, it will immediately return when containsPoint returns false. so
the children of the figure will never be hit-tested, even when they
should be.
so i think i wind up rewriting one or more of
>>
>>findFigureAt
>>findDescendantAtExcluding
>>findMouseEventTargetAt
>>findMouseEventTargetInDescendantsAt
>>
anyway, even after re-implementing containsPoint.
are there other parts of GEF that assume that containsPoint implies
2d-geometric containment rather than hit-testing? from looking at the
code, it seems not, but i don't know if there's implicit assumptions i'm
missing.
i notice Polyline appears to have an implementation of "containsPoint"
that's effectively a "hitTestOnLine". i imagine this is not a problem as
long as Polyline shapes don't have any child figures. confusingly,
Polygon, which is a sub-class of Polyline apparently goes back to
geometric containment, and could have children.
> To find shapes near the cursor, you could try various points around the
> cursor, perhaps in the shape of an X, and then compare all of the results.
> A custom figure search can be used to generate a "pick list" if multiple
> shapes full under a given point. The technique would be to never accept one
> single figure, but build up a list of all figures under a given point.
>
a custom figure search involves a rewrite of the findXXX methods
mentioned above, correct? specifically findFigureAt. there's a few
issues with this
a) since it's called recursively in a DFS of the figure hierarchy, one
has to be quite careful with memory/resource allocation.
b) if i want to re-use the shape classes (or any other existing
figure), i may need to create specialized sub-classes which re-implement
containsPoint and/or findFigureAt. so i'm introducing leaf classes
whereas the functionality really belongs in the root class.
from my perspective, the "real" solution is to introduce a new
non-final method hittest(x,y) into IFigure2 which makes no assumptions
about geometric containment, and have Figure implement both IFigure and
IFigure2. containsPoint should be deprecated and replaced by
geometricallyContains(x,y) which has containment semantics.
regards,
al
|
|
|
| Re: hit-test support for overlapping shapes [message #169786 is a reply to message #169778] |
Sun, 27 February 2005 07:36 |
| Eclipse User |
|
|
|
Originally posted by: alnospammajor.noboxspamspoon.com
> b) if i want to re-use the shape classes (or any other existing
> figure), i may need to create specialized sub-classes which re-implement
> containsPoint and/or findFigureAt. so i'm introducing leaf classes
> whereas the functionality really belongs in the root class.
>
i don't think i made this this point clearly. here's what i mean:
in order to override findFigureAt, i need to create a new subclass of
Figure:
class BaseFigure extends Figure {
// override findFigureAt
public IFigure findFigureAt ...
}
from which all my figures are derived.
now if i also need to re-implement containsPoint on the Shape classes,
i'll need to derive from them:
class DerivedShape extends Shape {
// override containsPoint
}
for each Shape.
unfortunately, there's no way to inject BaseFigure::findFigureAt into
DerivedShape, so i need to re-implement findFigureAt for each of the
DerivedShape.
alternatively, i can create my own Shape hierarchy derived from
BaseFigure instead of Figure and copy all the Shape code into this
hierarchy.
as you can this starts getting ugly.
my suggestion on separating hit-testing from containment only works
because it makes it unnecessary to change the search code.
regards,
al
|
|
|
| Re: hit-test support for overlapping shapes [message #169794 is a reply to message #169786] |
Sun, 27 February 2005 11:12 |
| Eclipse User |
|
|
|
Originally posted by: alnospammajor.noboxspamspoon.com
>
> unfortunately, there's no way to inject BaseFigure::findFigureAt into
> DerivedShape, so i need to re-implement findFigureAt for each of the
> DerivedShape.
>
> alternatively, i can create my own Shape hierarchy derived from
> BaseFigure instead of Figure and copy all the Shape code into this
> hierarchy.
>
there's yet another alternative which seems to be the cleanest of all.
have a BaseFigure class that forms the root of my model hierarchy.
BaseFigure will implement the custom findFigureAt method.
for each Shape (or other Figure) that is needed from the main draw2d
module, create a delegator class that extends BaseFigure
public DelegatingShape extends BaseFigure {
private Shape delegatee;
...
public void foo () {
delegatee.foo ()
}
...
}
we wind up with a bunch of methods that do very little, and lose the
inheritance hierarchy of Shape, but it should function correctly.
i still think that hitTest and containsPoint are two different functions
and should be separated in the main Figure class. i also suspect that
there's a number of applications out there that will need "outline hit
testing". so it should be incorporated into the library.
but with this workaround i may be able to get by without any GEF changes.
regards,
al
|
|
|
| Re: hit-test support for overlapping shapes [message #171256 is a reply to message #169794] |
Thu, 10 March 2005 20:40 |
| Eclipse User |
|
|
|
Originally posted by: none.us.ibm.com
Have you looked at TreeSearch? This should flexible enough to do any type
of hittesting you can think of.
"Al Major" <alnospammajor@noboxspamspoon.com> wrote in message
news:cvsa04$i2$1@www.eclipse.org...
>>
>> unfortunately, there's no way to inject BaseFigure::findFigureAt into
>> DerivedShape, so i need to re-implement findFigureAt for each of the
>> DerivedShape.
>>
>> alternatively, i can create my own Shape hierarchy derived from
>> BaseFigure instead of Figure and copy all the Shape code into this
>> hierarchy.
>>
> there's yet another alternative which seems to be the cleanest of all.
>
> have a BaseFigure class that forms the root of my model hierarchy.
> BaseFigure will implement the custom findFigureAt method.
>
> for each Shape (or other Figure) that is needed from the main draw2d
> module, create a delegator class that extends BaseFigure
>
> public DelegatingShape extends BaseFigure {
> private Shape delegatee;
> ...
>
|
|
|
Powered by
FUDForum. Page generated in 0.03700 seconds
] 
Search
Help
Register
Login
Home
