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 <[email protected]> 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 <[email protected]> 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 <[email protected]> wrote: >> >>> Ohh, I see, thanks Roland. >>> >>> Fady >>> >>> >>> On Wed, Jun 2, 2010 at 3:25 AM, Roland Steiner <[email protected] >>> > 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 <[email protected]> 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 <[email protected]> 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 >>>>>> ([email protected]) >>>>>> >>>>>> >>>>> >>>>> _______________________________________________ >>>>> webkit-dev mailing list >>>>> [email protected] >>>>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev >>>>> >>>>> >>>> >>> >> >
_______________________________________________ webkit-dev mailing list [email protected] http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
