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 <[email protected]> wrote: > On Thu, May 20, 2010 at 1:38 PM, David Hyatt <[email protected]> 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 [email protected] http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
