[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 <fsamuel at google.com> 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 <fsamuel at google.com> 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 <fsamuel at google.com> wrote:
>>
>>> Ohh, I see, thanks Roland.
>>>
>>> Fady
>>>
>>>
>>> On Wed, Jun 2, 2010 at 3:25 AM, Roland Steiner <rolandsteiner at google.com
>>> > 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):
>>>>
>>>> <table border=1><tbody>
>>>> <tr><td>R1C1</td><td>R1C2</td><td rowspan=3
>>>> valign=bottom>\\\\\\</td></tr>
>>>> <tr><td>R2C1</td><td rowspan=2 colspan=2 align=right
>>>> valign=bottom>//////</td></tr>
>>>> <tr><td colspan=3 align=right>----</td></tr>
>>>> </tbody></table>
>>>>
>>>> - Roland
>>>>
>>>> On Wed, Jun 2, 2010 at 8:58 AM, Fady Samuel <fsamuel at google.com> 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 <hyatt at apple.com> 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
>>>>>> (hyatt at apple.com)
>>>>>>
>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> webkit-dev mailing list
>>>>> webkit-dev at lists.webkit.org
>>>>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>>>>>
>>>>>
>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20100609/d977ab21/attachment.html>