|Summary:||Coordinated Graphics: a long page is scaled vertically while loading.|
|Product:||WebKit||Reporter:||Dongseong Hwang <dongseong.hwang>|
|Component:||Layout and Rendering||Assignee:||Dongseong Hwang <dongseong.hwang>|
|Severity:||Normal||CC:||allan.jensen, cmarcelo, jturcotte, luiz, noam, webkit.review.bot|
|Version:||528+ (Nightly build)|
Description Dongseong Hwang 2013-02-12 18:19:09 PST
When loading http://www.w3.org/TR/xpath-datamodel/, Coordinated Graphics draws vertically scaled contents. It is because there is the difference between the size of a layer and the size of CoordinatedBackingStore. Currently, CoordinatedGraphicsScene notifies the size to CoordinatedBackingStore at the moment of creating, updating and removing a tile. However, it is not necessary to send tile related messages when the size of layer is changed. So this patch resets the size of CoordinatedBackingStore when receiving the message that is created when the size is changed: SyncLayerState.
Comment 2 Allan Sandfeld Jensen 2013-02-13 02:13:01 PST
While I no longer see slow stretching when loading pages that would have scaled previously, I still see fast flickinging from some kind of resize, just happening much faster, but still happening.
Comment 4 Dongseong Hwang 2013-02-13 02:43:59 PST
(In reply to comment #2) > While I no longer see slow stretching when loading pages that would have scaled previously, I still see fast flickinging from some kind of resize, just happening much faster, but still happening. Yes, you're right. Thank you for reporting. I missed this because EFL MiniBrowser hardly reproduces. But Qt MiniBrowser reproduces well. It is because there still is small difference between setting size and flushing. In detail, CoordinatedGraphicsScene::setLayerState sets size to GraphicsLayer and then flush later. But CoordinatedGraphicsScene::setLayerState sets size to CoordinatedBackingStore immediately. So both size of TextureMapperLayer and CoordinatedBackingStore can be different when painting TextureMapper. The second patch fixes it.
Comment 5 Kenneth Rohde Christiansen 2013-02-13 02:51:20 PST
Comment on attachment 188040 [details] Patch LGTM
Comment 6 Noam Rosenthal 2013-02-13 03:17:05 PST
Comment on attachment 188040 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=188040&action=review > Source/WebCore/ChangeLog:20 > + Unfortunately, I couldn't think of a way to test this in an automated > + fashion. > + I would rephrase this "There is no current way to reliably test flicker issues."
Comment 7 Dongseong Hwang 2013-02-13 17:03:27 PST
Created attachment 188226 [details] Patch for landing
Comment 8 Dongseong Hwang 2013-02-13 17:04:10 PST
(In reply to comment #6) > (From update of attachment 188040 [details]) > I would rephrase this "There is no current way to reliably test flicker issues." Thank you always.
Comment 9 WebKit Review Bot 2013-02-13 17:58:31 PST
Comment on attachment 188226 [details] Patch for landing Clearing flags on attachment: 188226 Committed r142837: <http://trac.webkit.org/changeset/142837>
Comment 10 WebKit Review Bot 2013-02-13 17:58:36 PST
All reviewed patches have been landed. Closing bug.