Re: [webkit-dev] Table hit testing

So a first patch is now available for review here: https://bugs.webkit.org/show_bug.cgi?id=40775 Thanks, Fady 2010/6/8 Fady Samuel > So I was just about ready to post a potential patch for keeping track of > all cells that lie on a given grid sl

Re: [webkit-dev] Table hit testing

So I've been led to believe that perhaps this shouldn't be a problem if clipping is working correctly. Can anyone tell me if WebKit should be clipping updated pixels outside the clip rect or must any object that lies partially inside a clip rect be repainted in full? Fady On Tue, Jun 8, 2010 at

Re: [webkit-dev] Table hit testing

So I was just about ready to post a potential patch for keeping track of all cells that lie on a given grid slot. It seems that information is insufficient for correct rendering. Consider the attached test case: 1 R1C4 spans 4 rows, and should be drawn first. 2. R2C1 spans 4 columns and overlaps

Re: [webkit-dev] Table hit testing

So I have completed all the following things locally: * First fix the grid to record all the cells at a given position. This fixes a repaint bug. * Then change the hit-testing to work just like painting. This makes hit testing more efficient and ensures hit testing and painting agree. * Then opt

Re: [webkit-dev] Table hit testing

Ohh, I see, thanks Roland. Fady On Wed, Jun 2, 2010 at 3:25 AM, Roland Steiner wrote: > AFAICT you could have an arbitrary number up to the width or height of the > table, whichever is smaller, by combining row- and colspans - e.g. with 3 > ([v]aligns just to emphasize the overlapping): > > > R

Re: [webkit-dev] Table hit testing

AFAICT you could have an arbitrary number up to the width or height of the table, whichever is smaller, by combining row- and colspans - e.g. with 3 ([v]aligns just to emphasize the overlapping): R1C1R1C2\\ R2C1// - Roland On Wed, Jun 2, 2010 at 8:58 AM, Fady Samuel wrote: > Hi

Re: [webkit-dev] Table hit testing

Hi David, Just so I'm certain, there's no way for more than two cells to overlap in a single grid slot, is there? Thanks, Fady Samuel On Thu, May 20, 2010 at 4:43 PM, David Hyatt wrote: > On May 20, 2010, at 3:38 PM, Fady Samuel wrote: > > > So what are the rules for stacking here? do the cel

Re: [webkit-dev] Table hit testing

On May 20, 2010, at 3:38 PM, Fady Samuel wrote: > So what are the rules for stacking here? do the cells stack in the order in > which they appear in the HTML? > Correct, although note that backgrounds paint behind foregrounds, and hit testing works the same way, so it's not as simple as saying

Re: [webkit-dev] Table hit testing

On May 20, 2010, at 3:52 PM, Fady Samuel wrote: > I'm still confused about the proper ordering of painting/hit testing cells > for a given grid position. > > In the example you provided, David, WHY does cell 7 have precedence over cell > 5? Is it based on the order they're defined? Yes, it's

Re: [webkit-dev] Table hit testing

On May 20, 2010, at 3:47 PM, Peter Kasting wrote: > On Thu, May 20, 2010 at 1:38 PM, David Hyatt wrote: > This is all coming back to me now. > > When two cells occupy the same position in the grid, only one of them gets > stored at that position. The current code puts the first cell encountere

Re: [webkit-dev] Table hit testing

I'm still confused about the proper ordering of painting/hit testing cells for a given grid position. In the example you provided, David, WHY does cell 7 have precedence over cell 5? Is it based on the order they're defined? Thanks, Fady On Thu, May 20, 2010 at 4:47 PM, Peter Kasting wrote: >

Re: [webkit-dev] Table hit testing

On Thu, May 20, 2010 at 1:38 PM, David Hyatt wrote: > This is all coming back to me now. > > When two cells occupy the same position in the grid, only one of them gets > stored at that position. The current code puts the first cell encountered > into the grid. This means if you ask what cell is

Re: [webkit-dev] Table hit testing

On May 20, 2010, at 3:18 PM, David Hyatt wrote: > On May 20, 2010, at 3:07 PM, David Hyatt wrote: > >> If we could properly detect those degenerate cases, then you could probably >> get away with binary search, but until we do that, I don't think you can. > > Here's an example: > > > TD:hover

Re: [webkit-dev] Table hit testing

So what are the rules for stacking here? do the cells stack in the order in which they appear in the HTML? Cell 7 is defined after cell 5 and therefore it "owns" that position? Thanks, Fady On Thu, May 20, 2010 at 4:18 PM, David Hyatt wrote: > On May 20, 2010, at 3:07 PM, David Hyatt wrote: >

Re: [webkit-dev] Table hit testing

On May 20, 2010, at 3:07 PM, David Hyatt wrote: > If we could properly detect those degenerate cases, then you could probably > get away with binary search, but until we do that, I don't think you can. Here's an example: TD:hover { color: green } 1 2 3 4 5 6 7 9 In this example, cell 5 and

Re: [webkit-dev] Table hit testing

On May 20, 2010, at 2:54 PM, Fady Samuel wrote: > CSS is Awesome indeed :P > > So are you against fast paths? It seems if we don't have overflow, we can do > binary searches for hit testing, right? Unless I'm yet again missing > something fundamental? Sorry about that. :P Even when content doe

Re: [webkit-dev] Table hit testing

CSS is Awesome indeed :P So are you against fast paths? It seems if we don't have overflow, we can do binary searches for hit testing, right? Unless I'm yet again missing something fundamental? Sorry about that. :P Fady On Thu, May 20, 2010 at 2:56 PM, David Hyatt wrote: > You can't binary sea

Re: [webkit-dev] Table hit testing

You can't binary search if there are overflowing cells in any section. You have to go in order (from last to first) in that case, since you may hit test something. In general you won't find binary searches, etc. in most hit testing code because of overflow concerns. http://www.zazzle.com/css_

Re: [webkit-dev] Table hit testing

So I have an implementation that seems to be working (still testing edge cases). I found that m_grid, in RenderTableSection, is a Vector 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 t

Re: [webkit-dev] Table hit testing

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

Re: [webkit-dev] Table hit testing

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 > ch

[webkit-dev] Table hit testing

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 t