[webkit-dev] Proposal: Rect based HitTest for a better touch experience

[Antonio Gomes (:tonikitoo)]

Hi,

As Grace pointed out in the spun-off thread,  bug 40197 was filed and
a patch was put up for feedback there. I looked over the patch, and
since it took a different path from what I had in mind to fix the
problem, I also took a couple of days and implemented mine prototype.

I explained details of my approach in
https://bugs.webkit.org/show_bug.cgi?id=40197#c7 and also explained
the difference between both approaches in
https://bugs.webkit.org/show_bug.cgi?id=40197#c8 - see it pasted
below.

"Although I strongly believe that both approaches here end up in the
same results (even as-are), I will try to summarize the basic
difference between grace's (attachment 57980 [details]) and mine
(attachment 58324 [details]).

>From my understanding, the former makes the HitTest system
"rect-aware" in the sense that it keeps the core logic of nodeAtPoint
methods as point-based, but adjusts them to take a rect (a point + a
padding area) into consideration.

On the other hand, the later makes the HitTest really rect-based in
the sense that it changes all nodeAtPoint existent methods to be
nodeAtArea ones, and of course their method bodies were changed where
needed.

The difference is silly, but exists. We have just to decide how to
proceed from that point on. Whatever direction is decided, I am up to
join efforts with Grace to fix it."

In summary, first patch keeps passing a "point" plus a new "padding
rect" to build up the HitTestResult instance. The later makes any
point passed to fallback to a IntRect(point, IntSize(1,1)) and changes
the rest of the HitTest system to be rect-based (see more details in
#c7).

Comments welcomed.

Regards

On Sun, Jun 6, 2010 at 3:40 PM, Antti Koivisto <koivisto at iki.fi> wrote:
> On Wed, Jun 2, 2010 at 11:22 PM, David Hyatt <hyatt at apple.com> wrote:
>
>> I really don't think hit testing needs to be modified to get what you want.  You can do a scattershot sampling using multiple candidate points within the rect and apply whatever heuristics you want to choose a node.  I'm also not convinced that we should be complicating core hit testing code in this way, since I suspect this is one of those areas where mobile platforms will each want to do their own slightly different thing anyway.
>
> The problem with hit testing by multisampling is that it is
> ridiculously slow. You need to take at least a dozen samples for
> decent results. With a complex document on a mobile platform doing
> those can take several hundreds of milliseconds. That is pretty far
> from what is needed for good responsiveness. I think area hit testing
> would make a lot of sense.
>
> With WebKit2 it might actually be a good idea to track all event
> sensitive areas in the document. This way at least partial (no
> hit/maybe hit) testing could be done entirely in the UI process side.
>
>
>  antti
>
>> dave
>> (hyatt at apple.com)
>>
>> _______________________________________________
>> webkit-dev mailing list
>> webkit-dev at lists.webkit.org
>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>>
>



-- 
--Antonio Gomes