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

[Antonio Gomes (:tonikitoo)]

Hi, as a follow up on this and based on a quick chat with hyatt on
irc, the minimalistic approach seems to be the way to go.

<tonikitoo> dhyatt, david, could you join the discussion about rect
based hit test on bug 40197
<dhyatt> just need me to make a decision on the right naming?
<tonikitoo> dhyatt, not that simple. Basically we have to decide if we
are going to have nodeAtArea methods throughout the code, and make
only base classes have nodeAtPoint methods, failing back to
nodeAtArea. Or if we are going to keep passing x and y to HitTest
methods, and HitTestResult will have a padding rect, so each
nodeAtPoint method could work with it
<dhyatt> huge fan of grace's approach i have to say
<dhyatt> very minimal on how intrusive it is
<tonikitoo> right, it is simpler and and works equally
<dhyatt> yeah i kind of like the idea of slop around the point as the
approach though
<dhyatt> rather than patching every method name
<dhyatt> both patches need to stop using a vector for the node list
and use a hashset heh

On Thu, Jun 10, 2010 at 11:21 AM, Antonio Gomes (:tonikitoo)
<tonikitoo at gmail.com> wrote:
> 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
>



-- 
--Antonio Gomes