[webkit-dev] Table hit testing

[Fady Samuel]

Ohh I see, I was confused about this line in RenderTable:

1138     if (!hasOverflowClip() || overflowClipRect(tx, ty).contains(xPos,
yPos)) {

It seems that the default case is to visit all the children as
hasOverflowClip() is false.

Thanks for the explanation David.

I will look into optimizing hit testing to avoid visiting all children.

Thanks again,

Fady

On Tue, May 18, 2010 at 2:57 PM, David Hyatt <hyatt at apple.com> wrote:

>
> On May 18, 2010, at 12:52 PM, Fady Samuel wrote:
> > Hi all,
> >
> > I'm looking at table hit testing, and in all the simple test cases I've
> tried, it seems to show that RenderTable never has the flag
> m_hasOverflowClip set to true. What this means is that all the table's
> children are ALWAYS checked on all mouse events. For large tables, or pages
> with many tables, this sounds awfully taxing on the processor for no good
> reason.
> >
> > See RenderTable::nodeAtPoint in
> third_party/WebKit/WebCore/rendering/RenderTable.cpp . It seems
> "hasOverflowClip()" is always false.
> >
> > Can we not compute a bounding box for the table on layout? Are there any
> complications here that I should be aware of that resulted in this
> inefficient solution?
>
> m_hasOverflowClip is about overflow:auto/scroll/hidden.  The default value
> for overflow is visible, so that's not going to be set and isn't really
> relevant to your problem.
>
> Both RenderTable and RenderTableSection need to have their nodeAtPoint
> methods patched to be like their paint methods instead.  Both of those
> methods would get much more efficient if we did that.
>
> dave
> (hyatt at apple.com)
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20100518/6b48f3b6/attachment.html>