[webkit-dev] nodeAtPoint is very confusing

[David Hyatt]

Yeah this was on my list of things to do, but I stopped my big render  
tree refactoring for the sake of stability.  I think we should hold  
off on more big changes to render tree methods for now.

dave

On Apr 8, 2009, at 5:50 PM, Maciej Stachowiak wrote:

>
> On Apr 8, 2009, at 9:23 AM, Simon Fraser wrote:
>
>> On Apr 8, 2009, at 7:06 AM, Eric Seidel wrote:
>>
>>> Dave, Simon, and other rendering gurus:
>>>
>>> bool RenderObject::nodeAtPoint(const HitTestRequest&, HitTestResult&
>>> result, int _x, int _y, int tx, int ty, HitTestAction hitTestAction)
>>>
>>> _x, _y, tx, ty are very confusing.
>>>
>>> As far as I can tell, _x, _y are relative to the root layer (which  
>>> can
>>> change during hit-testing!) and tx, ty are more of the HTML  
>>> "offset to
>>> your parent" optimization which painting uses.
>>>
>>> Can you explain what the best way to convert from _x, _y to local
>>> coordinates?  And what I should rename _x, _y, and tx, ty to in a
>>> forthcoming "make hit testing readable to normal humans" cleanup
>>> patch?
>>
>> As I understand it, _x and _y are relative to tx, ty, which in turn  
>> is relative
>> to the rootLayer.
>>
>> In general tx and ty, as passed to painting and hit testing  
>> functions, are
>> the offsets that put you in the coordinate space of the parent  
>> renderer,
>> relative to the current rootLayer  being used for painting or hit  
>> testing
>> (which, as you note, gets reset for transforms, and I think should
>> also get reset for HTML/SVG boundaries).  So to get local x and y  
>> for hit testing,
>> you'll see code like:
>>
>> tx += x();
>> ty += y()
>> ...
>> updateHitTestResult(_x - tx, _y - ty)
>>
>> It is all rather confusing, but much of the complexity comes from  
>> having to
>> deal with inlines.
>
> Maybe one thing that would help would be combining (tx, ty) into an  
> IntPoint and (_x, _y) into an IntSize (since it as an offset from  
> the point established by tx, ty). Or vice versa.
>
> Regards,
> Maciej
>
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev