Re: [webkit-dev] Table hit testing

[Fady Samuel]

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 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 R1C4 (lies above it)
> 3. R4C1 spans 4 columsn and overlaps R1C4 (lies above it)
>
> Consider the case where the paint rect is the lower right grid slot.
> Knowing that R4C1 and R1C4 overlap, we draw R1C4 first and then R4C1 (in
> that order as they both lie inside the single slot dirty rect). Now we've
> drawn R1C4 ABOVE R2C1 This results in a rendering artifact. I'm
> currently working a solution that places cells in different layers and if a
> cell is dirty, we redraw it and all layers above it. How a layer is defined
> and formed and the data structures involved to do this efficiently will be
> discussed here shortly.
>
> Fady
>
>
> On Wed, Jun 2, 2010 at 4:40 PM, Fady Samuel  wrote:
>
>> 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 optimize hit-testing to binary-search if there are no overflowing
>> cells.  (And optimize painting similarly)
>> * Fix a table layout bug
>> * created a bunch of additional simple table layout tests
>>
>> I did all the pieces locally first to make sure I understand how all the
>> parts of table rendering fit together. However, I intend to get the pieces
>> of this work out in in smaller patches to simplify the review process for
>> reviewers.
>>
>> While I still have some more work to do testing, and splitting my work up
>> into the suggested pieces, please expect bug reports and proposed patches to
>> begin appearing shortly (within the next couple of days or so).
>>
>> Thanks,
>>
>> Fady Samuel
>>
>>
>> On Wed, Jun 2, 2010 at 7:34 AM, Fady Samuel  wrote:
>>
>>> 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):

 
 R1C1R1C2>>> valign=bottom>\\
 R2C1>>> valign=bottom>//
 
 

 - Roland

 On Wed, Jun 2, 2010 at 8:58 AM, Fady Samuel  wrote:

> 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 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 that 
>> cell 7
>> is always above cell 5.  They're interleaved, so from bottom to top:
>>
>> Cell 5 background
>> Cell 7 background
>> Cell 5 foreground (the number "5" in this example)
>> Cell 7 foreground (the number "7" in this example)
>>
>> That's why if you hover over the actual number 5 in that example it
>> will light up, but if you're in the background area overlap, the number 7
>> will light up.
>>
>> http://www.w3.org/TR/CSS21/zindex.html
>>
>> Therefore you do have to know about all the cells at the position,
>> since when you're in the "foreground" phase of hit testing, cell 7 will 
>> say
>> "Nope, you're not inside my foreground", and so you then need to check 
>> cell
>> 5, which will say "Yes, you are inside my foreground."
>>
>> The grid structure just isn't expressive enough.  It needs to be
>> patched to track all cells in a given row/column instead of just the 
>> first
>> one.
>>
>> dave
>> (hy...@apple.com)
>>
>>
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
>

>>>
>>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Table hit testing

[Fady Samuel]

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 10:55 AM, Fady Samuel  wrote:

> 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 R1C4 (lies above it)
> 3. R4C1 spans 4 columsn and overlaps R1C4 (lies above it)
>
> Consider the case where the paint rect is the lower right grid slot.
> Knowing that R4C1 and R1C4 overlap, we draw R1C4 first and then R4C1 (in
> that order as they both lie inside the single slot dirty rect). Now we've
> drawn R1C4 ABOVE R2C1 This results in a rendering artifact. I'm
> currently working a solution that places cells in different layers and if a
> cell is dirty, we redraw it and all layers above it. How a layer is defined
> and formed and the data structures involved to do this efficiently will be
> discussed here shortly.
>
> Fady
>
>
> On Wed, Jun 2, 2010 at 4:40 PM, Fady Samuel  wrote:
>
>> 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 optimize hit-testing to binary-search if there are no overflowing
>> cells.  (And optimize painting similarly)
>> * Fix a table layout bug
>> * created a bunch of additional simple table layout tests
>>
>> I did all the pieces locally first to make sure I understand how all the
>> parts of table rendering fit together. However, I intend to get the pieces
>> of this work out in in smaller patches to simplify the review process for
>> reviewers.
>>
>> While I still have some more work to do testing, and splitting my work up
>> into the suggested pieces, please expect bug reports and proposed patches to
>> begin appearing shortly (within the next couple of days or so).
>>
>> Thanks,
>>
>> Fady Samuel
>>
>>
>> On Wed, Jun 2, 2010 at 7:34 AM, Fady Samuel  wrote:
>>
>>> 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):

 
 R1C1R1C2>>> valign=bottom>\\
 R2C1>>> valign=bottom>//
 
 

 - Roland

 On Wed, Jun 2, 2010 at 8:58 AM, Fady Samuel  wrote:

> 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 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 that 
>> cell 7
>> is always above cell 5.  They're interleaved, so from bottom to top:
>>
>> Cell 5 background
>> Cell 7 background
>> Cell 5 foreground (the number "5" in this example)
>> Cell 7 foreground (the number "7" in this example)
>>
>> That's why if you hover over the actual number 5 in that example it
>> will light up, but if you're in the background area overlap, the number 7
>> will light up.
>>
>> http://www.w3.org/TR/CSS21/zindex.html
>>
>> Therefore you do have to know about all the cells at the position,
>> since when you're in the "foreground" phase of hit testing, cell 7 will 
>> say
>> "Nope, you're not inside my foreground", and so you then need to check 
>> cell
>> 5, which will say "Yes, you are inside my foreground."
>>
>> The grid structure just isn't expressive enough.  It needs to be
>> patched to track all cells in a given row/column instead of just the 
>> first
>> one.
>>
>> dave
>> (hy...@apple.com)
>>
>>
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
>

>>>
>>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Table hit testing

[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 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 R1C4 (lies above it)
3. R4C1 spans 4 columsn and overlaps R1C4 (lies above it)

Consider the case where the paint rect is the lower right grid slot. Knowing
that R4C1 and R1C4 overlap, we draw R1C4 first and then R4C1 (in that order
as they both lie inside the single slot dirty rect). Now we've drawn R1C4
ABOVE R2C1 This results in a rendering artifact. I'm currently working a
solution that places cells in different layers and if a cell is dirty, we
redraw it and all layers above it. How a layer is defined and formed and the
data structures involved to do this efficiently will be discussed here
shortly.

Fady

On Wed, Jun 2, 2010 at 4:40 PM, Fady Samuel  wrote:

> 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 optimize hit-testing to binary-search if there are no overflowing
> cells.  (And optimize painting similarly)
> * Fix a table layout bug
> * created a bunch of additional simple table layout tests
>
> I did all the pieces locally first to make sure I understand how all the
> parts of table rendering fit together. However, I intend to get the pieces
> of this work out in in smaller patches to simplify the review process for
> reviewers.
>
> While I still have some more work to do testing, and splitting my work up
> into the suggested pieces, please expect bug reports and proposed patches to
> begin appearing shortly (within the next couple of days or so).
>
> Thanks,
>
> Fady Samuel
>
>
> On Wed, Jun 2, 2010 at 7:34 AM, Fady Samuel  wrote:
>
>> 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):
>>>
>>> 
>>> R1C1R1C2>> valign=bottom>\\
>>> R2C1>> valign=bottom>//
>>> 
>>> 
>>>
>>> - Roland
>>>
>>> On Wed, Jun 2, 2010 at 8:58 AM, Fady Samuel  wrote:
>>>
 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 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 that cell 
> 7
> is always above cell 5.  They're interleaved, so from bottom to top:
>
> Cell 5 background
> Cell 7 background
> Cell 5 foreground (the number "5" in this example)
> Cell 7 foreground (the number "7" in this example)
>
> That's why if you hover over the actual number 5 in that example it
> will light up, but if you're in the background area overlap, the number 7
> will light up.
>
> http://www.w3.org/TR/CSS21/zindex.html
>
> Therefore you do have to know about all the cells at the position,
> since when you're in the "foreground" phase of hit testing, cell 7 will 
> say
> "Nope, you're not inside my foreground", and so you then need to check 
> cell
> 5, which will say "Yes, you are inside my foreground."
>
> The grid structure just isn't expressive enough.  It needs to be
> patched to track all cells in a given row/column instead of just the first
> one.
>
> dave
> (hy...@apple.com)
>
>

 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


>>>
>>
>
Title: Paint bug







R1C1

 
R1C2


R1C3


R1C4




R2C1




R3C1


R3C2


R3C3




R4C1





___
webkit-dev mai

Re: [webkit-dev] Table hit testing

[Fady Samuel]

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 optimize hit-testing to binary-search if there are no overflowing
cells.  (And optimize painting similarly)
* Fix a table layout bug
* created a bunch of additional simple table layout tests

I did all the pieces locally first to make sure I understand how all the
parts of table rendering fit together. However, I intend to get the pieces
of this work out in in smaller patches to simplify the review process for
reviewers.

While I still have some more work to do testing, and splitting my work up
into the suggested pieces, please expect bug reports and proposed patches to
begin appearing shortly (within the next couple of days or so).

Thanks,

Fady Samuel


On Wed, Jun 2, 2010 at 7:34 AM, Fady Samuel  wrote:

> 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):
>>
>> 
>> R1C1R1C2\\
>> R2C1> valign=bottom>//
>> 
>> 
>>
>> - Roland
>>
>> On Wed, Jun 2, 2010 at 8:58 AM, Fady Samuel  wrote:
>>
>>> 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 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 that cell 7
 is always above cell 5.  They're interleaved, so from bottom to top:

 Cell 5 background
 Cell 7 background
 Cell 5 foreground (the number "5" in this example)
 Cell 7 foreground (the number "7" in this example)

 That's why if you hover over the actual number 5 in that example it will
 light up, but if you're in the background area overlap, the number 7 will
 light up.

 http://www.w3.org/TR/CSS21/zindex.html

 Therefore you do have to know about all the cells at the position, since
 when you're in the "foreground" phase of hit testing, cell 7 will say 
 "Nope,
 you're not inside my foreground", and so you then need to check cell 5,
 which will say "Yes, you are inside my foreground."

 The grid structure just isn't expressive enough.  It needs to be patched
 to track all cells in a given row/column instead of just the first one.

 dave
 (hy...@apple.com)


>>>
>>> ___
>>> webkit-dev mailing list
>>> webkit-dev@lists.webkit.org
>>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>>>
>>>
>>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Table hit testing

[Fady Samuel]

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):
>
> 
> R1C1R1C2\\
> R2C1 valign=bottom>//
> 
> 
>
> - Roland
>
> On Wed, Jun 2, 2010 at 8:58 AM, Fady Samuel  wrote:
>
>> 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 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 that cell 7 is
>>> always above cell 5.  They're interleaved, so from bottom to top:
>>>
>>> Cell 5 background
>>> Cell 7 background
>>> Cell 5 foreground (the number "5" in this example)
>>> Cell 7 foreground (the number "7" in this example)
>>>
>>> That's why if you hover over the actual number 5 in that example it will
>>> light up, but if you're in the background area overlap, the number 7 will
>>> light up.
>>>
>>> http://www.w3.org/TR/CSS21/zindex.html
>>>
>>> Therefore you do have to know about all the cells at the position, since
>>> when you're in the "foreground" phase of hit testing, cell 7 will say "Nope,
>>> you're not inside my foreground", and so you then need to check cell 5,
>>> which will say "Yes, you are inside my foreground."
>>>
>>> The grid structure just isn't expressive enough.  It needs to be patched
>>> to track all cells in a given row/column instead of just the first one.
>>>
>>> dave
>>> (hy...@apple.com)
>>>
>>>
>>
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org
>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>>
>>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Table hit testing

[Roland Steiner]

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 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 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 that cell 7 is
>> always above cell 5.  They're interleaved, so from bottom to top:
>>
>> Cell 5 background
>> Cell 7 background
>> Cell 5 foreground (the number "5" in this example)
>> Cell 7 foreground (the number "7" in this example)
>>
>> That's why if you hover over the actual number 5 in that example it will
>> light up, but if you're in the background area overlap, the number 7 will
>> light up.
>>
>> http://www.w3.org/TR/CSS21/zindex.html
>>
>> Therefore you do have to know about all the cells at the position, since
>> when you're in the "foreground" phase of hit testing, cell 7 will say "Nope,
>> you're not inside my foreground", and so you then need to check cell 5,
>> which will say "Yes, you are inside my foreground."
>>
>> The grid structure just isn't expressive enough.  It needs to be patched
>> to track all cells in a given row/column instead of just the first one.
>>
>> dave
>> (hy...@apple.com)
>>
>>
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Table hit testing

[Fady Samuel]

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 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 that cell 7 is
> always above cell 5.  They're interleaved, so from bottom to top:
>
> Cell 5 background
> Cell 7 background
> Cell 5 foreground (the number "5" in this example)
> Cell 7 foreground (the number "7" in this example)
>
> That's why if you hover over the actual number 5 in that example it will
> light up, but if you're in the background area overlap, the number 7 will
> light up.
>
> http://www.w3.org/TR/CSS21/zindex.html
>
> Therefore you do have to know about all the cells at the position, since
> when you're in the "foreground" phase of hit testing, cell 7 will say "Nope,
> you're not inside my foreground", and so you then need to check cell 5,
> which will say "Yes, you are inside my foreground."
>
> The grid structure just isn't expressive enough.  It needs to be patched to
> track all cells in a given row/column instead of just the first one.
>
> dave
> (hy...@apple.com)
>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Table hit testing

[David Hyatt]

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 that cell 7 is 
always above cell 5.  They're interleaved, so from bottom to top:

Cell 5 background
Cell 7 background
Cell 5 foreground (the number "5" in this example)
Cell 7 foreground (the number "7" in this example)

That's why if you hover over the actual number 5 in that example it will light 
up, but if you're in the background area overlap, the number 7 will light up.

http://www.w3.org/TR/CSS21/zindex.html

Therefore you do have to know about all the cells at the position, since when 
you're in the "foreground" phase of hit testing, cell 7 will say "Nope, you're 
not inside my foreground", and so you then need to check cell 5, which will say 
"Yes, you are inside my foreground."

The grid structure just isn't expressive enough.  It needs to be patched to 
track all cells in a given row/column instead of just the first one.

dave
(hy...@apple.com)

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Table hit testing

[David Hyatt]

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 based on document order.

dave

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Table hit testing

[David Hyatt]

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 encountered 
> into the grid. This means if you ask what cell is present in row 3 and column 
> 2 of the above example, you'll get back cell #5.
> 
> This actually makes the grid unsuitable for hit testing and is why I hadn't 
> converted nodeAtPoint over to use the grid yet.
> 
> The grid needs to be fixed so that it records all of the cells present at a 
> given position.  If it did that, then you could binary search as long as 
> there are no overflowing cells, since you'd then be able to see all the cells 
> that actually occupy a given grid position.
> 
> The paint method uses the grid and actually has a repaint bug, since if you 
> make the repaint rect tight enough, it won't think it has to paint the second 
> and subsequent cells that occupy a given grid position.
> 
> It sounds like your recommended steps are:
> * First fix the grid to record all the cells at a given position.  This fixes 
> a repaint bug.

Right.  The painting code would have to be patched to look at all the cells at 
that position and not just the first one obviously.

> * Then change the hit-testing to work just like painting.  This makes hit 
> testing more efficient and ensures hit testing and painting agree.

Correct.

> * Then optimize hit-testing to binary-search if there are no overflowing 
> cells.  (And optimize painting similarly?  I dunno what that would mean, 
> though--just going off the "optimize together" comment earlier.)
> 

Yes, optimize painting similarly.  You should be able to binary search your way 
through the row grid to find the first one that intersects the dirty rect.

> Is this a good summary?


Yup! 
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Table hit testing

[Fady Samuel]

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:

> 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 present in row 3 and
>> column 2 of the above example, you'll get back cell #5.
>>
>> This actually makes the grid unsuitable for hit testing and is why I
>> hadn't converted nodeAtPoint over to use the grid yet.
>>
>> The grid needs to be fixed so that it records all of the cells present at
>> a given position.  If it did that, then you could binary search as long as
>> there are no overflowing cells, since you'd then be able to see all the
>> cells that actually occupy a given grid position.
>>
>> The paint method uses the grid and actually has a repaint bug, since if
>> you make the repaint rect tight enough, it won't think it has to paint the
>> second and subsequent cells that occupy a given grid position.
>>
>
> It sounds like your recommended steps are:
> * 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 optimize hit-testing to binary-search if there are no overflowing
> cells.  (And optimize painting similarly?  I dunno what that would mean,
> though--just going off the "optimize together" comment earlier.)
>
> Is this a good summary?
>
> PK
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Table hit testing

[Peter Kasting]

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 present in row 3 and
> column 2 of the above example, you'll get back cell #5.
>
> This actually makes the grid unsuitable for hit testing and is why I hadn't
> converted nodeAtPoint over to use the grid yet.
>
> The grid needs to be fixed so that it records all of the cells present at a
> given position.  If it did that, then you could binary search as long as
> there are no overflowing cells, since you'd then be able to see all the
> cells that actually occupy a given grid position.
>
> The paint method uses the grid and actually has a repaint bug, since if you
> make the repaint rect tight enough, it won't think it has to paint the
> second and subsequent cells that occupy a given grid position.
>

It sounds like your recommended steps are:
* 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 optimize hit-testing to binary-search if there are no overflowing
cells.  (And optimize painting similarly?  I dunno what that would mean,
though--just going off the "optimize together" comment earlier.)

Is this a good summary?

PK
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Table hit testing

[David Hyatt]

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 { color: green }
> 
> 
> 1 2 3
> 4 5 6
> 7 9
> 
> 
> In this example, cell 5 and cell 7 actually overlap and share a position in 
> the grid.  You can see that hit testing works properly and gives cell 7 
> precedence over cell 5 (e.g., if you're in overlapping background areas of 
> the cell, then cell 7 wins).

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 present in row 3 and column 2 of 
the above example, you'll get back cell #5.

This actually makes the grid unsuitable for hit testing and is why I hadn't 
converted nodeAtPoint over to use the grid yet.

The grid needs to be fixed so that it records all of the cells present at a 
given position.  If it did that, then you could binary search as long as there 
are no overflowing cells, since you'd then be able to see all the cells that 
actually occupy a given grid position.

The paint method uses the grid and actually has a repaint bug, since if you 
make the repaint rect tight enough, it won't think it has to paint the second 
and subsequent cells that occupy a given grid position.

dave
(hy...@apple.com)

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Table hit testing

[Fady Samuel]

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:
>
> 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 cell 7 actually overlap and share a position in
> the grid.  You can see that hit testing works properly and gives cell 7
> precedence over cell 5 (e.g., if you're in overlapping background areas of
> the cell, then cell 7 wins).
>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Table hit testing

[David Hyatt]

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 cell 7 actually overlap and share a position in the 
grid.  You can see that hit testing works properly and gives cell 7 precedence 
over cell 5 (e.g., if you're in overlapping background areas of the cell, then 
cell 7 wins).

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Table hit testing

[David Hyatt]

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 doesn't overflow cells, the cells can actually overlap one 
another.  This happens with crazy spans in degenerate cases.  That's why the 
painting code narrows things down to a column and row range, and then makes 
sure to walk all the rows painting any cells in that column range.  In those 
degenerate cases, the paint and hit testing order does become relevant for the 
spanning cells.

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.

dave
(hy...@apple.com)

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Table hit testing

[Fady Samuel]

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 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_is_awesome_mug-168716435071981928
>
> I strongly recommend not writing code that deviates from what the paint
> methods do.  In general the nodeAtPoint version of a function should be just
> like the paint version of a function, just from last to first rather than
> first to last.
>
> Any time hit testing and painting deviate, you have a problem, since the
> painting stack order and the hit testing stack order obviously need to
> agree.
>
> Basically I'd expect a first patch to synchronize the two methods (paint
> and nodeAtPoint), and then if you want to optimize further, I'd expect to
> see optimizations to both painting and hit testing made together.
>
> dave
> (hy...@apple.com)
>
> On May 20, 2010, at 10:58 AM, Fady Samuel wrote:
>
> 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 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  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  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 

Re: [webkit-dev] Table hit testing

[David Hyatt]

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_is_awesome_mug-168716435071981928

I strongly recommend not writing code that deviates from what the paint methods 
do.  In general the nodeAtPoint version of a function should be just like the 
paint version of a function, just from last to first rather than first to last.

Any time hit testing and painting deviate, you have a problem, since the 
painting stack order and the hit testing stack order obviously need to agree.

Basically I'd expect a first patch to synchronize the two methods (paint and 
nodeAtPoint), and then if you want to optimize further, I'd expect to see 
optimizations to both painting and hit testing made together.

dave
(hy...@apple.com)

On May 20, 2010, at 10:58 AM, Fady Samuel wrote:

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

Re: [webkit-dev] Table hit testing

[Fady Samuel]

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

Re: [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  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

Re: [webkit-dev] Table hit testing

[David Hyatt]

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

[webkit-dev] Table hit testing

[Fady Samuel]

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?

Thanks,

Fady Samuel
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev