[Webkit-unassigned] [Bug 95094] [Chromium] Remove contentsScale from GraphicsLayerChromium and WebContentLayer

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=95094


Jeff Timanus <twiz at chromium.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
 Attachment #161337|                            |review-, commit-queue-
               Flag|                            |




--- Comment #2 from Jeff Timanus <twiz at chromium.org>  2012-08-29 15:43:27 PST ---
Created an attachment (id=161337)
 --> (https://bugs.webkit.org/attachment.cgi?id=161337&action=review)
Piping appliesPageScale to LayerChromium from GraphicsLayer.

This patch implements the basic idea of how we can move the contentsScale code from GraphicsLayer{Chromium} to LayerChromium.

Essentially this change removes the assignment of contents scale at the GraphicsLayer level, and instead performs it during CCLayerTreeHost::updateLayers.

The GraphicsLayer::appliesPageScale property is pushed to the LayerChromium owned by the GraphicsLayer, and used to control the page scale semantics at the LayerChromium level.

There are a few issues I wonder about with this change:
 - I'm currently assigning the page scale to all LayerChromium instances in the tree, where as the old path only assigned the scale to the layer associated with the path.  I had been hoping that the appliesPageScale selective application of the contentsScale would filter out layers that should not be scaled.
 - There are several layout tests that fail with a result of this patch.  (Attachment forthcoming.)

Is this approach at all sane?  I feel that the complexity of all the different zoom/scale factors is an indication that this is not the right direction.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.