I'm only occasionally skimming this thread so I hope I don't disrupt
discussions by throwing in a few observations now and then...
On 11/20/2013 7:30 AM, Assaf Yavnai wrote:
Pavel,
I think that this is a very good example why touch events should be processed
separately from mouse events.
For example, if you will press a button with a touch it will remain in "hover" state
although you released the finger from the screen. This is done because the "hover" state
listen to the mouse coordinates, which is invalid for touch.
Touch events doesn't have the concept of move, only drag.
Some screens actually have a hover mode (the Galaxy Note series can detect both
finger and stylus hover, but they use a Wacom-like sensor rather than the
typical touch sensor). In those cases, one could consider a hover mode to be
similar to a mouse move event.
Even screens without hover detection have pressure detection and a light pressure below a
configurable "touch" threshold could probably also be treated as hover as well?
Even with a mouse you have the concept of "the mouse has left the building" - consider if the mouse
was moved to another screen for instance. The loss of finger/stylus hover should probably be treated
similarly, the location of the current "finger/mouse/pointer thing" is currently "nowhere near
anything" when the touch implement leaves detection range...?
On the subject of detection of proximity of points to shapes, that is actually an area
that I've tried to come up with good algorithms for the AA shaders and not had much great
success (I've come up with various approximations, but they often tend to suffer from the
points raised earlier about very wide and thin rectangles). The CAG code of the
java.awt.geom package (cloned into the FX source base) could potentially detect
intersections between an oval and an arbitrary shape, but I'm not sure of the
performance. I know that I once found the AWT team using the Area code to do picking
(with just rectangle shapes, though) until I explained to them that there are probably
some more specific algorithms that would be an order of magnitude faster for the common
case of rectangle-rectilinear math. Still, they managed to use it just fine for a bit
without noticing any performance issues. The code base also has some fairly optimized
"rectangle intersects arbitrary shape" code that!
would b
e much faster than an Area.intersect(Shape) operation. It might be generalizable to "oval
intersects arbitrary shape" with some work, or perhaps "set of rectangles or polygons
that approximate an oval intersects arbitrary shape". I don't have time right now to look
into that, but I'm throwing the suggestions out in case someone else is inspired...
...jim
