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:
>
> <STYLE>
> TD:hover { color: green }
> </STYLE >
> <TABLE border="1">
> <TR><TD>1 <TD>2 <TD>3
> <TR><TD>4 <TD rowspan="2">5 <TD>6
> <TR><TD colspan="2">7 <TD>9
> </TABLE>
>
> 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
([email protected])
_______________________________________________
webkit-dev mailing list
[email protected]
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
