This object is created on the main thread and used on the impl thread.
BUG=160312
Review URL: https://chromiumcodereview.appspot.com/11360178
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@167057 0039d316-1c4b-4281-b951-d872f2087c98
When the scale is < 1, then we don't save anything. The first time we
see a scale >= 1, we will save it.
Tests:
cc_unittests:LayerTreeHostCommonTest.verifySmallContentsScale
BUG=159655
R=enne,jamesr
Review URL: https://chromiumcodereview.appspot.com/11377088
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@167040 0039d316-1c4b-4281-b951-d872f2087c98
We use GL_TEXTURE0 for nearly all operations, so it's cheaper to leave this as the default
for all draws and have quads that use other texture units reset to 0.
BUG=
Review URL: https://chromiumcodereview.appspot.com/11275222
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@167030 0039d316-1c4b-4281-b951-d872f2087c98
Adds +/- operators to gfx::Rect that are applied to its origin Point.
Removes gfx::Point method a.OffsetFrom(b) in favor of (b - a).
Begin use +/- instead of Offset() in ui/gfx/ and cc/
New tests:
ui_unittests:RectTest.Offset
R=pkasting,enne
BUG=158416
Review URL: https://codereview.chromium.org/11293194
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@167012 0039d316-1c4b-4281-b951-d872f2087c98
It's not efficient (or tested), but this should be enough to start being useful
once we add the raster/upload/appendQuads path.
Next steps are probably to add tilings to the PictureLayerImpl.
R=nduca@chromium.org
BUG=155209
Review URL: https://chromiumcodereview.appspot.com/11293188
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@166999 0039d316-1c4b-4281-b951-d872f2087c98
These behave like similar methods for Rect/Point/Size.
Tests:
ui_unittests:Vector2dTest.Scale
ui_unittests:Vector3dTest.Scale
R=sky
BUG=160158
Review URL: https://codereview.chromium.org/11293193
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@166993 0039d316-1c4b-4281-b951-d872f2087c98
The video playback path needs to be able to handle cropped video frames,
e.g. for HW decoders that output to macroblock-rounded buffer sizes.
* Composite only the visible subrect from WebVideoFrame in
cc::VideoLayerImpl
* Remove some extraneous cropping logic from cc::VideoLayerImpl now that
we have exact cropping info.
* media::VideoFrame replaces "data_size_" member with "coded_size_", and
adds a "visible_rect_" gfx::Rect to indicate the sub-rect of the
entire frame that should be visible (after cropping)
* Associated changes to various decoder/capture pipelines to plumb this
through.
TEST=build, run on x86, ARM
BUG=155416,140509,chrome-os-partner:15230
Change-Id: I284bc893959db427bc9ae677aed8b07292d228ae
Review URL: https://chromiumcodereview.appspot.com/11269017
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@166988 0039d316-1c4b-4281-b951-d872f2087c98
We add gfx::ScalePoint() as a non-mutating version of the Scale method.
Tests:
ui_unittests:PointTest.Scale
R=sky
BUG=160158
Review URL: https://codereview.chromium.org/11369144
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@166979 0039d316-1c4b-4281-b951-d872f2087c98
- I moved PageScaleAnimation to work entirely at root content layer
scale, to be consistent with the new pinch zoom code. This avoids the
need for any scaling of scroll offsets. However, everything must now
be in floating point, and the complexity is moved into viewport size
calculation instead.
- I also took the opportunity to add support for two anchors instead of
just one, introducing an additional level of interpolation. This
makes the animation appear less jarring when we clamp it to document
edge, and it also removes the need for special-casing translation-only
animations.
BUG=152505
Review URL: https://chromiumcodereview.appspot.com/11090062
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@166855 0039d316-1c4b-4281-b951-d872f2087c98
This class is used as a fake, not a Mock. Move it out so it possible to use
this outside of layer_tree_host_unittest.
Covered by existing tests.
R=enne
TEST=cc_unittests
Review URL: https://chromiumcodereview.appspot.com/11312155
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@166842 0039d316-1c4b-4281-b951-d872f2087c98
mapHomgenousPoint is not cheap. We can do faster in projectClippedRect similar
to mapClippedRect.
rectSubtractRegion constructs a Region to do subtraction from. If the
subtraction's rvalue is empty, then there is nothing to do and we can
avoid creating a Region structure at all.
I measured time spent in calculateRenderPasses with a draw-heavy unit test.
Baseline: 0.001148 seconds
With these changes: 0.001116 seconds
So, about 3% reduction in time spent in calculateRenderPasses.
R=enne
BUG=159718
Review URL: https://chromiumcodereview.appspot.com/11312154
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@166841 0039d316-1c4b-4281-b951-d872f2087c98
This means that Contains(empty) is always true.
Tests:
RegionTest.Contains
R=enne
Review URL: https://chromiumcodereview.appspot.com/11368149
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@166812 0039d316-1c4b-4281-b951-d872f2087c98
This is required for the layer to occlude other things. Currently the layer
never occludes anything.
Tests:
cc_unittests:SolidColorLayerImplTest.verifyOpaqueRect
BUG=159745
R=jamesr
Review URL: https://codereview.chromium.org/11360145
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@166690 0039d316-1c4b-4281-b951-d872f2087c98
Currently we save the rasterScale for a layer the first time we see it. However,
if the layer is animating, the value we save isn't very accurate. Instead, avoid
saving the value until the animation is complete.
Tests:
cc_unittests:LayerTreeHostCommonTest.verifyContentsScaleForAnimatingLayer
R=enne
BUG=159937
Review URL: https://chromiumcodereview.appspot.com/11362151
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@166660 0039d316-1c4b-4281-b951-d872f2087c98
Constantly calling glEnable(GL_SCISSOR_TEST) costs us a few ms/frame on some hardware.
As it turns out, we never disable the scissor test so we can just leave it on all the
time.
BUG=
Review URL: https://chromiumcodereview.appspot.com/11378004
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@166632 0039d316-1c4b-4281-b951-d872f2087c98
We create a class in cc/ called Region which provides a gfx:: type-friendly API
to SkRegion, and allows for easily swapping out region implementations in the
future if required.
During the process, I removed tests dependency on a "size()" method on Region,
that used to give the number of rects in the Region's internal representation.
Instead, we always create a Region in the tests from our expected rects, and
compare the Regions directly. We use ToString() comparisons to get useful
failure outputs, similar to the unit tests of other geometry types in ui/gfx.
This uncovered a WTF::Vector holdout in the OcclusionTracker class, which is
converted to a std::vector.
Covered by existing tests; no change in behaviour.
R=enne
BUG=147395
Review URL: https://chromiumcodereview.appspot.com/11366094
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@166617 0039d316-1c4b-4281-b951-d872f2087c98
These will be used to keep track of JavaScript touch event handler on the compositor thread
and will be updated accordingly when there is a change involving adding/removing or changing
the layout of the nodes that contain the touch event handlers.
BUG=135818
Review URL: https://chromiumcodereview.appspot.com/11377013
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@166561 0039d316-1c4b-4281-b951-d872f2087c98
Now that we're in chromium, we can tell if about:tracing is enabled ot not!
Turn on overdraw metrics, and their expensive computations, only when
about:tracing is turned on.
When we do turn them on, we don't want the performance characteristics of
the system to suddenly change, or the tracing is not very meaningful! So, we
track the number of pixels read, instead of written, for overdraw (which
should mostly be the same with the new rasterScale feature). This
computation is very cheap compared to the old one.
TBR=jamesr
BUG=119126
Relanding: https://codereview.chromium.org/11293143/
Review URL: https://codereview.chromium.org/11312129
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@166521 0039d316-1c4b-4281-b951-d872f2087c98
Now that we're in chromium, we can tell if about:tracing is enabled ot not!
Turn on overdraw metrics, and their expensive computations, only when
about:tracing is turned on.
When we do turn them on, we don't want the performance characteristics of
the system to suddenly change, or the tracing is not very meaningful! So, we
track the number of pixels read, instead of written, for overdraw (which
should mostly be the same with the new rasterScale feature). This
computation is very cheap compared to the old one.
R=jamesr
BUG=119126
Review URL: https://codereview.chromium.org/11293143TBR=danakj@chromium.org
Review URL: https://codereview.chromium.org/11364132
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@166477 0039d316-1c4b-4281-b951-d872f2087c98
Now that we're in chromium, we can tell if about:tracing is enabled ot not!
Turn on overdraw metrics, and their expensive computations, only when
about:tracing is turned on.
When we do turn them on, we don't want the performance characteristics of
the system to suddenly change, or the tracing is not very meaningful! So, we
track the number of pixels read, instead of written, for overdraw (which
should mostly be the same with the new rasterScale feature). This
computation is very cheap compared to the old one.
R=jamesr
BUG=119126
Review URL: https://codereview.chromium.org/11293143
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@166464 0039d316-1c4b-4281-b951-d872f2087c98
This switches back to using if (m_resource) in pushPropertiesTo() since
it may be called before setNeedsDisplay(). Also, switch to
checking if resourceId == 0 instead of backingResourceIsDeleted() since
that asserts it's only called on the impl thread.
Review URL: https://chromiumcodereview.appspot.com/11377017
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@166399 0039d316-1c4b-4281-b951-d872f2087c98
This method exists in Skia, but is not publicly consumable/linkable with a
component build. Skia will expose this (or a similar) method through a proper
public API, and we should use it. But in the meantime, we make a copy of the
method in timing_function.cc, and use it there in place of WebCore's UnitBezier
class.
Tests:
cc_unittests:TimingFunctionTest.CubicBezierTimingFunction
This test compares the output of the timing function against baseline values
recorded with WebCore's UnitBezier class. If new methods are able to come
closer to those values, we should decrease the epsilon used in the test
accordingly.
R=jamesr
BUG=147395
Review URL: https://chromiumcodereview.appspot.com/11359077
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@166362 0039d316-1c4b-4281-b951-d872f2087c98
The hit test resulting point that the tryScroll() method gets is in content
space, since it is the result of mapping via the inverse screenSpaceTransform.
However, the nonFastScrollableRegion is in layer space, so it should not compare
the point against the region directly. We add a conversion from content to layer
space before doing the test.
This is now covered by the following tests. Because the layer is given a
contentsScale, the tests fail without the above change made to tryScroll.
Tests:
cc_unittests:LayerTreeHostImplTest.nonFastScrollableRegionBasic
cc_unittests:LayerTreeHostImplTest.nonFastScrollableRegionWithOffset
R=enne
BUG=159676
Review URL: https://chromiumcodereview.appspot.com/11377006
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@166353 0039d316-1c4b-4281-b951-d872f2087c98
This makes partialTextureUpdatesMax constant 0 when building for OS_ANDROID.
BUG=156945
TEST=manual
Review URL: https://chromiumcodereview.appspot.com/11347022
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@166347 0039d316-1c4b-4281-b951-d872f2087c98
This makes the resource update controller maintain a maximum number of
pending updates. This keeps our pipeline better filled without
theoretically increasing the risk that we delay drawing at vsync tick.
BUG=145825
TEST=cc_unittests and manual testing
Review URL: https://chromiumcodereview.appspot.com/11347019
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@166298 0039d316-1c4b-4281-b951-d872f2087c98
This doesn't do anything yet. It is assumed that ui/compositor will switch
over to using Layer directly and not WebLayer so that this switch will only
eventually affect the render process compositor.
This deliberately doesn't add an about:flags entry until this path is mildly
functional.
BUG=155209
Review URL: https://codereview.chromium.org/11375002
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@166240 0039d316-1c4b-4281-b951-d872f2087c98
The FYI bot step "Check licenses for WebView" is broken.
BUG=
TEST=android fyi bot is green
Review URL: https://chromiumcodereview.appspot.com/11368100
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@166232 0039d316-1c4b-4281-b951-d872f2087c98
Also switched to using drawBitmapRectToRect instead of drawBitmapRect since
it takes floating point rects as parameters.
Now
platform/chromium/virtual/softwarecompositing/visibility/visibility-image-layers.html
is rendering correctly (minus filtering differences between Mesa and Skia).
BUG=124671
Review URL: https://chromiumcodereview.appspot.com/11369079
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@166178 0039d316-1c4b-4281-b951-d872f2087c98
-cleaner design: less colors, text arranged above the graph, deviation number right aligned
-added transparency: FPS counter does not completely cover the webpage
-less frequent number updates: makes the numbers easier to read
-indicator line at 60fps
comparison images: https://docs.google.com/folder/d/0B8Y78t3tjy1XZk1xdWx6VjN5aFE/edit
Please download the patch and provide a screenshot from your system to test the layout.
Review URL: https://chromiumcodereview.appspot.com/11272042
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@166041 0039d316-1c4b-4281-b951-d872f2087c98
This change removes all IntPoint/FloatRect/IntSize/etc from the compositor.
There remains an indirect dependency on these types through the
WebCore::Region class, which we wrap but need to replace. However, the wrapper
there hides the WebCore types inside it, so there are now no references to the
types from anywhere else in the compositor.
I went back and forth on how to deal with scroll "positions". The name suggested
that they should be Points, and that the deltas should be Vectors. However this
lent itself to super awkward math at times. In the end, it was much cleaner to
make all scroll "positions" into scroll "offsets" and represent everything as
Vectors.
Covered by existing tests; no change in behaviour.
R=enne
BUG=147395
Relanding: https://codereview.chromium.org/11367080/
Review URL: https://codereview.chromium.org/11366089
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@166027 0039d316-1c4b-4281-b951-d872f2087c98
Make sure we have a comment at the end of the namespace for each .cc file and
that there are two spaces between the closing brace and the comment.
R=enne
Review URL: https://chromiumcodereview.appspot.com/11275153
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@166005 0039d316-1c4b-4281-b951-d872f2087c98
This change removes all IntPoint/FloatRect/IntSize/etc from the compositor.
There remains an indirect dependency on these types through the
WebCore::Region class, which we wrap but need to replace. However, the wrapper
there hides the WebCore types inside it, so there are now no references to the
types from anywhere else in the compositor.
I went back and forth on how to deal with scroll "positions". The name suggested
that they should be Points, and that the deltas should be Vectors. However this
lent itself to super awkward math at times. In the end, it was much cleaner to
make all scroll "positions" into scroll "offsets" and represent everything as
Vectors.
Covered by existing tests; no change in behaviour.
R=enne
BUG=147395
Review URL: https://codereview.chromium.org/11367080
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@165947 0039d316-1c4b-4281-b951-d872f2087c98
