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 <hy...@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
> (hy...@apple.com)
>
>
_______________________________________________
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
