discussion about touch events

[Jim Graham]

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