Re: [webkit-dev] Proposal: Rect based HitTest for a better touch experience
In the later sample output, note that it did not reach body , whose boundary obvious intersects any possible given Z rect. That would happen if the div in case encloses the rect Z completely, and it would be the stop point for the hit test. In Mozilla's implementation, nodesFromRect does not care if a node encloses the hit test rect completely or partially. The test will continue until the body. What would be the preferable behavior for our implementation? The latter behavior may actually make the method useful for things other than hit testing, if that sways your decision at all. I can imagine page authors finding it useful to be able to find out all the elements that are under a given point (which in turn suggests that elementsFromRect with zero padding should still find all the hit elements in z-order). Exactly the point. For hit test matters, stopping as soon as it gets fully enclosed makes total sense to me. On the other hand, as you said, I bet there might be use cases like give me all nodes under X, Y, with padding W, H (where they can be '0'). I thought about making this stop an optional flag for HitTestResult or HitTestRequest. Would it be acceptable? I'd resist adding this until we have a use case for it. Maybe you've already have a internal use case (see below :) Jun 16 18:04:01 dhyatttonikitoo: i need to talk to some people here at apple too Jun 16 18:04:12 dhyatttonikitoo: we've gotten a request for e.g., all the nodes that intersect the visible rect Jun 16 18:04:16 dhyattthat's a common desire Jun 16 18:04:20 dhyattthis api kind of does that Jun 16 18:04:29 dhyatti think other browsers would be interested too etc It would be great it we could use this opportunity to address this request. But, well, in order to make it work that way (give *all* nodes under rect X), there would be some less simple changes needed, so we can go first for with what we have working at the moment. Cheers, -- --Antonio Gomes ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Proposal: Rect based HitTest for a better touch experience
If we want to return all the nodes, it is actually a simple change as we just remove the code to check the enclosure. But this may affect the hit test performance. thanks, Grace On Wed, Jul 7, 2010 at 5:59 AM, Antonio Gomes (:tonikitoo) toniki...@gmail.com wrote: In the later sample output, note that it did not reach body , whose boundary obvious intersects any possible given Z rect. That would happen if the div in case encloses the rect Z completely, and it would be the stop point for the hit test. In Mozilla's implementation, nodesFromRect does not care if a node encloses the hit test rect completely or partially. The test will continue until the body. What would be the preferable behavior for our implementation? The latter behavior may actually make the method useful for things other than hit testing, if that sways your decision at all. I can imagine page authors finding it useful to be able to find out all the elements that are under a given point (which in turn suggests that elementsFromRect with zero padding should still find all the hit elements in z-order). Exactly the point. For hit test matters, stopping as soon as it gets fully enclosed makes total sense to me. On the other hand, as you said, I bet there might be use cases like give me all nodes under X, Y, with padding W, H (where they can be '0'). I thought about making this stop an optional flag for HitTestResult or HitTestRequest. Would it be acceptable? I'd resist adding this until we have a use case for it. Maybe you've already have a internal use case (see below :) Jun 16 18:04:01 dhyatt tonikitoo: i need to talk to some people here at apple too Jun 16 18:04:12 dhyatt tonikitoo: we've gotten a request for e.g., all the nodes that intersect the visible rect Jun 16 18:04:16 dhyatt that's a common desire Jun 16 18:04:20 dhyatt this api kind of does that Jun 16 18:04:29 dhyatt i think other browsers would be interested too etc It would be great it we could use this opportunity to address this request. But, well, in order to make it work that way (give *all* nodes under rect X), there would be some less simple changes needed, so we can go first for with what we have working at the moment. Cheers, -- --Antonio Gomes ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Proposal: Rect based HitTest for a better touch experience
Hi Simon. Thank you join the discussion! On Tue, Jul 6, 2010 at 1:46 AM, Simon Fraser simon.fra...@apple.com wrote: On Jul 5, 2010, at 7:35 PM, Antonio Gomes (:tonikitoo) wrote: * adds a Document::nodesFromRect method, exposing the functionality to the dom. It returns a NodeList with all nodes that intersect the given hit-tested area. Is there a reason to use different terminology from the existing elementFromPoint, which would suggest that yours be named elementsFromRect? We (dhyatt and I) originally considered that on irc, but for now it was decided to keep it as nodesFromRect, specially because text nodes are being returned, which is interesting for hit testing matters, in fact. Do you see other objections against the naming, apart from the terminology discrepancy with elementFromPoint? As-is nodesFromRect will be store all nodes whose area intersects the given rect hit test 'til it finds a node whose boundary encloses it completely. At this point hit test will stop at any node in the tree hierarchy. Sample outputs of nodesFromRect for an hypothetical rect X and a html Y are [p , div, body]. For another hypothetical rect Z and the same html Y, nodesFromRect might return [span,div] I assume the nodes are listed in front-to-back z-order? They are, yes. In the later sample output, note that it did not reach body , whose boundary obvious intersects any possible given Z rect. That would happen if the div in case encloses the rect Z completely, and it would be the stop point for the hit test. In Mozilla's implementation, nodesFromRect does not care if a node encloses the hit test rect completely or partially. The test will continue until the body. What would be the preferable behavior for our implementation? The latter behavior may actually make the method useful for things other than hit testing, if that sways your decision at all. I can imagine page authors finding it useful to be able to find out all the elements that are under a given point (which in turn suggests that elementsFromRect with zero padding should still find all the hit elements in z-order). Exactly the point. For hit test matters, stopping as soon as it gets fully enclosed makes total sense to me. On the other hand, as you said, I bet there might be use cases like give me all nodes under X, Y, with padding W, H (where they can be '0'). I thought about making this stop an optional flag for HitTestResult or HitTestRequest. Would it be acceptable? One thing that this functionality does not allow you to do is to find the *closest* node to the given point that matches some set of criteria (like being clickable). This might be a more useful thing for a mobile browser. Right, as for mozilla's implementation, this method main goal is to provide the list of nodes. Any post-processing over the resulting list would be responsibility of the caller site, including calculating the shortest distance rect, or consider the more frequently visited elements (in case of links), etc. -- --Antonio Gomes ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Proposal: Rect based HitTest for a better touch experience
On Jul 6, 2010, at 5:54 AM, Antonio Gomes (:tonikitoo) wrote: Hi Simon. Thank you join the discussion! On Tue, Jul 6, 2010 at 1:46 AM, Simon Fraser simon.fra...@apple.com wrote: On Jul 5, 2010, at 7:35 PM, Antonio Gomes (:tonikitoo) wrote: * adds a Document::nodesFromRect method, exposing the functionality to the dom. It returns a NodeList with all nodes that intersect the given hit-tested area. Is there a reason to use different terminology from the existing elementFromPoint, which would suggest that yours be named elementsFromRect? We (dhyatt and I) originally considered that on irc, but for now it was decided to keep it as nodesFromRect, specially because text nodes are being returned, which is interesting for hit testing matters, in fact. Do you see other objections against the naming, apart from the terminology discrepancy with elementFromPoint? If it's a considered decision, I'm OK with it. In the later sample output, note that it did not reach body , whose boundary obvious intersects any possible given Z rect. That would happen if the div in case encloses the rect Z completely, and it would be the stop point for the hit test. In Mozilla's implementation, nodesFromRect does not care if a node encloses the hit test rect completely or partially. The test will continue until the body. What would be the preferable behavior for our implementation? The latter behavior may actually make the method useful for things other than hit testing, if that sways your decision at all. I can imagine page authors finding it useful to be able to find out all the elements that are under a given point (which in turn suggests that elementsFromRect with zero padding should still find all the hit elements in z-order). Exactly the point. For hit test matters, stopping as soon as it gets fully enclosed makes total sense to me. On the other hand, as you said, I bet there might be use cases like give me all nodes under X, Y, with padding W, H (where they can be '0'). I thought about making this stop an optional flag for HitTestResult or HitTestRequest. Would it be acceptable? I'd resist adding this until we have a use case for it. One thing that this functionality does not allow you to do is to find the *closest* node to the given point that matches some set of criteria (like being clickable). This might be a more useful thing for a mobile browser. Right, as for mozilla's implementation, this method main goal is to provide the list of nodes. Any post-processing over the resulting list would be responsibility of the caller site, including calculating the shortest distance rect, or consider the more frequently visited elements (in case of links), etc. Got it. What you have sounds fine. Simon ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Proposal: Rect based HitTest for a better touch experience
Hi guys. We've uploaded a patch for review in bug https://bugs.webkit.org/show_bug.cgi?id=40197 (attachment https://bugs.webkit.org/attachment.cgi?id=59789 - chromium build fixed in r61955) - Grace and I joint effort in fixing this issue. As ways to expose the functionality, the patch: * extends hitTestResultAtPoint method of the EventHandler with an extra 'padding' parameter, defaulting to IntSize(0,0). The rect-based hit test is performed when a non-zero padding is passed in; * adds a Document::nodesFromRect method, exposing the functionality to the dom. It returns a NodeList with all nodes that intersect the given hit-tested area. I would like to discuss how the later should work. As-is nodesFromRect will be store all nodes whose area intersects the given rect hit test 'til it finds a node whose boundary encloses it completely. At this point hit test will stop at any node in the tree hierarchy. Sample outputs of nodesFromRect for an hypothetical rect X and a html Y are [p , div, body]. For another hypothetical rect Z and the same html Y, nodesFromRect might return [span,div]. In the later sample output, note that it did not reach body , whose boundary obvious intersects any possible given Z rect. That would happen if the div in case encloses the rect Z completely, and it would be the stop point for the hit test. In Mozilla's implementation, nodesFromRect does not care if a node encloses the hit test rect completely or partially. The test will continue until the body. What would be the preferable behavior for our implementation? Cheers, --Antonio ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Proposal: Rect based HitTest for a better touch experience
On Jul 5, 2010, at 7:35 PM, Antonio Gomes (:tonikitoo) wrote: * adds a Document::nodesFromRect method, exposing the functionality to the dom. It returns a NodeList with all nodes that intersect the given hit-tested area. Is there a reason to use different terminology from the existing elementFromPoint, which would suggest that yours be named elementsFromRect? As-is nodesFromRect will be store all nodes whose area intersects the given rect hit test 'til it finds a node whose boundary encloses it completely. At this point hit test will stop at any node in the tree hierarchy. Sample outputs of nodesFromRect for an hypothetical rect X and a html Y are [p , div, body]. For another hypothetical rect Z and the same html Y, nodesFromRect might return [span,div] I assume the nodes are listed in front-to-back z-order? In the later sample output, note that it did not reach body , whose boundary obvious intersects any possible given Z rect. That would happen if the div in case encloses the rect Z completely, and it would be the stop point for the hit test. In Mozilla's implementation, nodesFromRect does not care if a node encloses the hit test rect completely or partially. The test will continue until the body. What would be the preferable behavior for our implementation? The latter behavior may actually make the method useful for things other than hit testing, if that sways your decision at all. I can imagine page authors finding it useful to be able to find out all the elements that are under a given point (which in turn suggests that elementsFromRect with zero padding should still find all the hit elements in z-order). One thing that this functionality does not allow you to do is to find the *closest* node to the given point that matches some set of criteria (like being clickable). This might be a more useful thing for a mobile browser. Simon ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Proposal: Rect based HitTest for a better touch experience
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 koivi...@iki.fi wrote: On Wed, Jun 2, 2010 at 11:22 PM, David Hyatt hy...@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 (hy...@apple.com) ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev -- --Antonio Gomes ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Proposal: Rect based HitTest for a better touch experience
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) toniki...@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 koivi...@iki.fi wrote: On Wed, Jun 2, 2010 at 11:22 PM, David Hyatt hy...@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 (hy...@apple.com) ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev -- --Antonio Gomes -- --Antonio Gomes ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Proposal: Rect based HitTest for a better touch experience
Yes, I got schooled on this days ago, but welcome to the party! ;) dave On Jun 10, 2010, at 6:00 PM, Maciej Stachowiak wrote: On Jun 2, 2010, at 1:22 PM, David Hyatt 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. I suspect hit testing a rect against the render tree could be done more efficiently than scattershot sampling. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Proposal: Rect based HitTest for a better touch experience
On Wed, Jun 2, 2010 at 11:22 PM, David Hyatt hy...@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 (hy...@apple.com) ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Proposal: Rect based HitTest for a better touch experience
We (Android) are also looking at this area. We are working on a patch. Will file a bug and provide a patch for the feedback. thanks, Grace ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Proposal: Rect based HitTest for a better touch experience
Hi,
As most of you have experienced, the precision of a mouse click on
Desktop applications, including Web browsers, is much higher than the
precision of a touch tap on a mobile device. It is not a new problem,
and many solutions have been proposed to improve that situation. One
of the common solutions is to make a small target’s tap-sensitive area
larger, invisibly, than the visible target itself. Of course, it would
not work on a mobile Web browser, since it'd end up breaking the
desired layout of any non-simple Web site.
Mozilla has addressed this problem by implementing the SmartTap
feature [1]. The solution is simple: a nodesFromRect method is
available for applications {fennec, firefox, etc}. As the name
implies, given a rect (corresponding to tapped area), it returns a
list of candidate mouse clickable target nodes for the tap. This
list is sorted by z-order, larger intersection area, most visited (in
case of links), etc. Call sites can then pick the first element on the
list, or use any different heuristic to choose the target.
[1] https://bugzilla.mozilla.org/show_bug.cgi?id=489127
After some initial research, mostly understanding the HitTest system
of WebCore, I am sure we can provide something similar as a cross
platform solution for the problem.
For the moment, my plan is to use better hit testing to make it easier
for users to click focus hyperlinks and input fields. For that, the
HitTest system would have to be modified to receive a Rect as input,
instead of a Point. It would also have to hold a list of possible
target candidate nodes, instead of only a single target node as it
does currently. In deep, the many ::nodeAtPoint implementations would
have to be adjusted to work with a Rect, not a Point, and probably
renamed to something similar to nodesAtRect. Much of the current
HitTest logic in RenderLayer would not need changes, though.
To keep the current mouse behavior (which is clearly point-based), we
could just pass rects with width and height equal to 1, so a Rect(x,
y, 1, 1) would behavior equally or very similarly to Point(x, y).
Before going this way, I would like to know of any known problem or
show stoppers.
Cheers,
--
--Antonio Gomes
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Proposal: Rect based HitTest for a better touch experience
On Jun 2, 2010, at 2:46 PM, Antonio Gomes (:tonikitoo) wrote:
Hi,
As most of you have experienced, the precision of a mouse click on
Desktop applications, including Web browsers, is much higher than the
precision of a touch tap on a mobile device. It is not a new problem,
and many solutions have been proposed to improve that situation. One
of the common solutions is to make a small target’s tap-sensitive area
larger, invisibly, than the visible target itself. Of course, it would
not work on a mobile Web browser, since it'd end up breaking the
desired layout of any non-simple Web site.
Mozilla has addressed this problem by implementing the SmartTap
feature [1]. The solution is simple: a nodesFromRect method is
available for applications {fennec, firefox, etc}. As the name
implies, given a rect (corresponding to tapped area), it returns a
list of candidate mouse clickable target nodes for the tap. This
list is sorted by z-order, larger intersection area, most visited (in
case of links), etc. Call sites can then pick the first element on the
list, or use any different heuristic to choose the target.
[1] https://bugzilla.mozilla.org/show_bug.cgi?id=489127
After some initial research, mostly understanding the HitTest system
of WebCore, I am sure we can provide something similar as a cross
platform solution for the problem.
For the moment, my plan is to use better hit testing to make it easier
for users to click focus hyperlinks and input fields. For that, the
HitTest system would have to be modified to receive a Rect as input,
instead of a Point. It would also have to hold a list of possible
target candidate nodes, instead of only a single target node as it
does currently. In deep, the many ::nodeAtPoint implementations would
have to be adjusted to work with a Rect, not a Point, and probably
renamed to something similar to nodesAtRect. Much of the current
HitTest logic in RenderLayer would not need changes, though.
To keep the current mouse behavior (which is clearly point-based), we
could just pass rects with width and height equal to 1, so a Rect(x,
y, 1, 1) would behavior equally or very similarly to Point(x, y).
Before going this way, I would like to know of any known problem or
show stoppers.
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.
dave
(hy...@apple.com)
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Proposal: Rect based HitTest for a better touch experience
On Wed, Jun 2, 2010 at 1:52 PM, Antonio Gomes (:tonikitoo) toniki...@gmail.com wrote: If a port do not want to take advantage of the new support, the current functionality should and would be kept, i.e. Rect(x,y,1,1,) would do the trick. Be careful to check whether you really want 1, 1 or 0, 0 as the size in your new API. PK ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Proposal: Rect based HitTest for a better touch experience
He would want 1,1. dave On Jun 2, 2010, at 3:58 PM, Peter Kasting wrote: On Wed, Jun 2, 2010 at 1:52 PM, Antonio Gomes (:tonikitoo) toniki...@gmail.com wrote: If a port do not want to take advantage of the new support, the current functionality should and would be kept, i.e. Rect(x,y,1,1,) would do the trick. Be careful to check whether you really want 1, 1 or 0, 0 as the size in your new API. PK ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
