[Qt][WK2] Draw tiles of previous contents-scale for opaque layers if they don't intersect with previous tiles
Created attachment 127834 [details] Patch
Comment on attachment 127834 [details] Patch I don't get it fully. Maybe previous tile is a too overloaded word.
To reproduce, open the morphing-cubes demo in Qt's MiniBrowser, and change the content scale. The cube sides always disappear and then reappear - that's because they're painted with semi-transparency and the tiles from the previous contents scale are discarded before the new ones are ready.
Yeah I understand the issue, but just not disregarding ones not intersecting sounds like it only solves this in some cases. What do you do when they infact do intersect and you still don't have the new content ready? clip it?
Comment on attachment 127834 [details] Patch Would be nice with a few better comments in the code, but r=me
Comment on attachment 127834 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=127834&action=review > Source/WebKit2/UIProcess/qt/LayerBackingStore.cpp:120 > + coveredRect.unite(tile.rect()); Why do you need to count the previous scale tiles in the covered rect?
(In reply to comment #6) > (From update of attachment 127834 [details]) > View in context: https://bugs.webkit.org/attachment.cgi?id=127834&action=review > > > Source/WebKit2/UIProcess/qt/LayerBackingStore.cpp:120 > > + coveredRect.unite(tile.rect()); > > Why do you need to count the previous scale tiles in the covered rect? hmm... I guess that line is unnecessary.
(In reply to comment #7) > (In reply to comment #6) > > (From update of attachment 127834 [details] [details]) > > View in context: https://bugs.webkit.org/attachment.cgi?id=127834&action=review > > > > > Source/WebKit2/UIProcess/qt/LayerBackingStore.cpp:120 > > > + coveredRect.unite(tile.rect()); > > > > Why do you need to count the previous scale tiles in the covered rect? > > hmm... I guess that line is unnecessary. Though if things are fast enough there might be a situation where we have previous tiles from several scales... in that case we would still want to discard them if there's opacity.
(In reply to comment #8) > Though if things are fast enough there might be a situation where we have previous tiles from several scales... in that case we would still want to discard them if there's opacity. I think that would be weird, since we should only send createTile while rendering tiles and normally at this point the previous backing store should already have sent all the removeTile messages for its tiles, once its smart pointer was reset. It would also mean that you would discard tiles randomly from one scale or the other depending on which one sets the coveredRect first, and mix them. So I think we should avoid it if it really can happen.
(In reply to comment #9) > (In reply to comment #8) > > Though if things are fast enough there might be a situation where we have previous tiles from several scales... in that case we would still want to discard them if there's opacity. > > I think that would be weird, since we should only send createTile while rendering tiles and normally at this point the previous backing store should already have sent all the removeTile messages for its tiles, once its smart pointer was reset. > > It would also mean that you would discard tiles randomly from one scale or the other depending on which one sets the coveredRect first, and mix them. So I think we should avoid it if it really can happen. OK, I see what you mean. But that line is harmless, and I use it in the next patch to make sure we clip if we painted tiles that are not contained in the targetRect. Otherwise I need to calculate two coverRects, which seems like an overkill. Any objection to submitting the patch as is?
(In reply to comment #10) > Any objection to submitting the patch as is? Sorry no problem, I just wanted to make sure that it has more use than it's costing :)
Created attachment 127996 [details] Patch
Comment on attachment 127996 [details] Patch Clearing flags on attachment: 127996 Committed r108408: <http://trac.webkit.org/changeset/108408>
All reviewed patches have been landed. Closing bug.