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
Accordding to Dana:
"We can probably just call SkFloatToScalar directly in those sites.
Those values should never be NaN or infinity."
BUG=147395
TEST=cc_unittests
R=enne@chromium.org,danakj@chromium.org
NOTRY=true
Review URL: https://chromiumcodereview.appspot.com/11293084
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@165889 0039d316-1c4b-4281-b951-d872f2087c98
This moves texture upload related flushing to the TextureUploader
class. This is a more appropriate place to handle this type of flushing
and makes it possible to avoid some unnecessary flushes.
BUG=
TEST=cc_unittests
Review URL: https://chromiumcodereview.appspot.com/11367054
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@165860 0039d316-1c4b-4281-b951-d872f2087c98
This is so that we can write the picklers without having to include webcore/wtf.
This also changes the resource transfer functions to avoid copies.
BUG=146080
Review URL: https://chromiumcodereview.appspot.com/11358080
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@165847 0039d316-1c4b-4281-b951-d872f2087c98
This replaces the last cases of FloatRect with gfx::RectF. It depends on the
IsExpressibleAsRect() method in https://codereview.chromium.org/11364054/ and
removes the stubs as well!
We add an API to the Region class that is intended to be our final Region
class interface. It uses an iterator to walk the rects in the Region, which is
compatible with the SkRegion API, but can also hide the IntRects exposed by the
WebCore Region API.
Once this is done, there is no need to use cc::IntRect, and we can remove it
entirely.
Covered by existing tests; no change in behaviour.
BUG=147395
R=enne
Review URL: https://codereview.chromium.org/11360066
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@165837 0039d316-1c4b-4281-b951-d872f2087c98
They were also fixed in past revisions, now that cc component landed and the
TillingData landed to, we can remove them.
BUG=147395,154052
TEST=checkdeps.py succeeds.
R=enne@chromium.org,jamesr@chromium.org
Review URL: https://codereview.chromium.org/11360069
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@165805 0039d316-1c4b-4281-b951-d872f2087c98
It does as it says it does. This depends on the QuadF CL found at
https://codereview.chromium.org/11369043/ and is just search/replace
after that, as I added all the equivalent functionality to QuadF that
we made use of on FloatQuad.
It is possible we may see some slight differences in behaviour from using
FloatQuad, as we should benefit from increased precision, using doubles after
multiplying floats, when using Contains(Point) or IsCounterClockwise().
Covered by existing tests; no dramatic change in behaviour.
R=enne
BUG=147395
Review URL: https://codereview.chromium.org/11364044
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@165735 0039d316-1c4b-4281-b951-d872f2087c98
This is a direct port of the TilingData class from the WebKit repo, found in:
Source/WebCore/platform/graphics/gpu/TilingData.h|cpp
Previous commits from non-google folks have been:
- ossy replacing the non-copyable macro (which is not present here).
- hyatt replacing right()/bottom() with maxX()/maxY() (we use right()/bottom() again here, with gfx::Rect instead of IntRect).
- mitz using ASSERT_UNUSED instead of ASSERT guarded on NDEBUG (we use DCHECK instead here).
Covered by existing tests; this replaces the use of WebCore::TilingData with the new cc::TilingData.
R=enne
BUG=147395
Review URL: https://codereview.chromium.org/11359030
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@165681 0039d316-1c4b-4281-b951-d872f2087c98
The remaining sizes should all be becoming vectors. Some or all of the
remaining points should as well.
The only Int/Float Point/Size types left are in the scrolling and page scaling
code, or in the LayerTilingData.
R=enne
BUG=147395
Review URL: https://codereview.chromium.org/11358050
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@165569 0039d316-1c4b-4281-b951-d872f2087c98
The remaining uses are:
- Dealing with the output of Region::rects() which gives a vector of
WebCore::IntRects.
- Using FloatRect::isExpressibleAsIntRect.
Covered by existing tests; no new behaviour.
BUG=147395
R=enne
Review URL: https://codereview.chromium.org/11275113
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@165542 0039d316-1c4b-4281-b951-d872f2087c98
This entirely removes our usage of FloatPoint3D, and removes the stub header as
well.
Covered by existing tests; just changing data types.
This depends on https://codereview.chromium.org/11367025/
BUG=147395
R=enne
Review URL: https://codereview.chromium.org/11369018
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@165484 0039d316-1c4b-4281-b951-d872f2087c98
This covers layers, layer tree hosts, and related classes. *phew*
I intentionally avoided anything to do with scrolling or page scale. Those
should be changed to be Vectors and need a bit more thought. This change
should be pretty mindless.
It converts to gfx Rect, Size, Vector, and Point classes. No change is
made for FloatPoint3D or FloatQuad yet.
I've added cc/geometry.h as a place for free functions that don't exist
on gfx types yet, and that we should port over in the future.
No change in behaviour; covered by existing tests.
BUG=147395
R=enne
Review URL: https://codereview.chromium.org/11264056
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@165434 0039d316-1c4b-4281-b951-d872f2087c98
This is the first part of fixing fuzzy content issue in composited layers in
scaled pages.
There are two reasons of fuzzy content:
1) Inaccurate scale: The scale in transformation is calculated with
contentBounds.width / bounds.width
contentBounds.height / bounds.height
in layer_tree_host_common.cc and other places.
However, contentBounds is a IntSize which is calculated from bounds
and contentsScale in layer.cc:
IntRect(lroundf(bounds.width * contentsScale),
lroundf(bounds.height * contentsScale))
This causes the scale like 0.993 or 1.007 in the drawTransformation etc.
where identity transformation is expected.
To resolve the issue, instead of calculating scale using contentBounds,
pass the accurate contentsScale from Layer to LayerImpl.
2) Pixel on surfaces are not aligned. Will describe this in the CL for the
second part.
(See https://bugs.webkit.org/show_bug.cgi?id=84187 for more details).
Change-Id: I8f59f0460e1b212223e2c8c551b4127d8239e5cc
BUG=bugs.webkit.org/show_bug.cgi?id=84187
TEST=ContentsScalingLayerTest.checkContentBounds, LayerTreeHostCommonTest.verifyLayerTransformsInHighDPIAccurateScaleZeroPosition, LayerTreeHostCommonTest.verifyRenderSurfaceTransformsInHighDPIAccurateScaleZeroPosition
Review URL: https://chromiumcodereview.appspot.com/11276060
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@165269 0039d316-1c4b-4281-b951-d872f2087c98
