[webkit-dev] Table hit testing
Fady Samuel
fsamuel at google.com
Thu May 20 13:52:25 PDT 2010
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 <pkasting at google.com> wrote:
> On Thu, May 20, 2010 at 1:38 PM, David Hyatt <hyatt at apple.com> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20100520/c580147e/attachment.html>
More information about the webkit-dev
mailing list