[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 <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/20100608/9c94a206/attachment.html>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20100608/9c94a206/attachment-0001.html>