Chromium compositor change implementing page-scale driven pinch-zoom.

cc/LayerChromium.h

 // Copyright 2010 The Chromium Authors. All rights reserved.
 // Use of this source code is governed by a BSD-style license that can be
 // found in the LICENSE file.
 
 
 #ifndef LayerChromium_h
 #define LayerChromium_h
 
 #if USE(ACCELERATED_COMPOSITING)
 
@@ skipping 130 matching lines @@
     void setNonFastScrollableRegionChanged() { m_nonFastScrollableRegionChanged = true; }
     void setLayerScrollClient(WebKit::WebLayerScrollClient* layerScrollClient) { m_layerScrollClient = layerScrollClient; }
 
     void setDrawCheckerboardForMissingTiles(bool);
     bool drawCheckerboardForMissingTiles() const { return m_drawCheckerboardForMissingTiles; }
 
     bool forceRenderSurface() const { return m_forceRenderSurface; }
     void setForceRenderSurface(bool);
 
     IntSize scrollDelta() const { return IntSize(); }
+    FloatSize localOffset() const { return FloatSize(); }

[enne (OOO), 2012/09/13 19:40:54]

This seriously needs a comment describing what this variable is.  localOffset is
also not a particularly intuitive name.

[aelias_OOO_until_Jul13, 2012/09/13 19:47:41]

In the WebKit bug, I proposed collapsing m_localOffset, m_pageScaleDelta and
m_pageScaleFactor (in CCLayerImpl) into a new matrix called "m_implTransform" (a
transformation which is only computed and applied on the impl-side).  What do
you think?

[Jeff Timanus, 2012/09/13 19:58:50]

I'm working on wrapping all of these transforms as Alexandre suggests.

 
     float pageScaleDelta() const { return 1; }
+    float pageScaleFactor() const { return 1; }

[enne (OOO), 2012/09/13 19:40:54]

Why is the page scale factor 1 on the main thread? I'm guessing this is due to
your previous concerns about the wrong tiles getting invalidated.  I'd like to
lean on the prepainting system here to paint the correct set of tiles rather
than having a fake scale on the main thread.

[aelias_OOO_until_Jul13, 2012/09/13 19:47:41]

I would also like us to get the right scale on the main thread to make sure we
paint the right set of tiles.  This will be a blocker to ship this on Android,
and I suspect you won't be happy with the overpainting on low-end Windows
tablets and Chromebooks either.  It might be easier to solve this problem on the
first pass instead of rejiggering the math in the future.

[Jeff Timanus, 2012/09/13 19:58:50]

The page scale factor is 1 because of the change suggested by Dana on the wk
patch.  Previously, I was passing the scale and blue-box offset to the main
thread so that only those tiles that are visible from the pinched viewport would
be painted.

By passing a scale factor of 1, all of the tiles in the 'red box' are being
prepared at the scaled resolution.

The intent was to land the patch as is, and then correct the pre-painting
behaviour to only prepare the necessary tiles.
I'm fine with fixing this in this patch.  It would be a straight-forward follow
up patch as well.

 
     void setDoubleSided(bool);
     bool doubleSided() const { return m_doubleSided; }
 
     void setPreserves3D(bool preserve3D) { m_preserves3D = preserve3D; }
     bool preserves3D() const { return m_preserves3D; }
 
     void setUseParentBackfaceVisibility(bool useParentBackfaceVisibility) { m_useParentBackfaceVisibility = useParentBackfaceVisibility; }
     bool useParentBackfaceVisibility() const { return m_useParentBackfaceVisibility; }
 
@@ skipping 203 matching lines @@
     WebKit::WebAnimationDelegate* m_layerAnimationDelegate;
     WebKit::WebLayerScrollClient* m_layerScrollClient;
 };
 
 void sortLayers(Vector<RefPtr<LayerChromium> >::iterator, Vector<RefPtr<LayerChromium> >::iterator, void*);
 
 }
 #endif // USE(ACCELERATED_COMPOSITING)
 
 #endif