So I have an implementation that seems to be working (still testing edge cases). I found that m_grid, in RenderTableSection, is a Vector<RowStruct> and each RowStruct contains a row which knows about the columns of that row.
Thus this is effectively a dense 2D table of Cells. I use this for hit testing. By the time nodeAtPoint has been called we've already computed the dimensions and location of the rows and cells and all RenderTableCells are reachable through m_grid. Thus, I do a binary search on the rows, comparing their y position with the mouse's y pos to find which row to consider. Then once a row has been picked, I do a binsearch on the columns within that row, looking at the x positions, and then I pass the event to the nearest cell. Of course, the actual mouse position may fall just outside of a cell (it may lie over spacing between cells for example) but in that case the RenderTableCell node would simply ignore the event. I'm still doing testing (regression + perf). For cells with rowspan > 1, it seems that the a pointer to the Cell node is placed in each row its associated with in m_grid. For cells with colspan > 1, it seems that only the first column that the cell occupies is not NULL...so I just linear scan back to the first non NULL position if I encounter that. I suppose I could optimize that further by filling all of m_grid appropriately and changing code elsewhere to accommodate. CSS transformations on tables seem to all automagically work, it seems all the coordinate system transformation code all happens before we reach RenderTableSection::nodeAtPoint. Does it sound like I'm missing anything important? I've just started playing with the webkit source a couple of weeks ago, so I may have missed something silly. Thanks, Fady On Tue, May 18, 2010 at 3:03 PM, Fady Samuel <fsam...@google.com> wrote: > 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