content: Enable 1-copy rasterizer on all platforms but Android and MacOS.

content: Enable 1-copy rasterizer on all platforms but Android and MacOS.

BUG=406404
Committed: https://crrev.com/91a0a8702ab11d02ff9b6a6ad9e8ab7b080c0f2f
Cr-Commit-Position: refs/heads/master@{#302567}

[reveman, 2014-10-29 20:59:40]

reveman@chromium.org changed reviewers:
+ ccameron@chromium.org, danakj@chromium.org, enne@chromium.org,
piman@chromium.org, vmpstr@chromium.org

[reveman, 2014-10-29 20:59:41]

I think this is ready for a try once https://codereview.chromium.org/683263004/
has landed.

Not sure an about:gpu field is required as this is unconditionally enabled on
Linux, Windows and ChromeOS.

FYI, we need to un-blacklist sync extensions and fix IOSurface destruction
before this can be enabled on MacOS. And I'm planning to give this a try on
Android after the branch point.

[piman, 2014-10-29 21:05:55]

LGTM.
What are the metrics we can monitor to evaluate if this is an improvement?

[reveman, 2014-10-29 22:19:59]

On 2014/10/29 21:05:55, piman (Very slow to review) wrote:
> LGTM.
> What are the metrics we can monitor to evaluate if this is an improvement?

The most important metric is our existing smoothness benchmarks. Ideally, they
shouldn't regress at all. If some benchmark regresses then we need to evaluate
why and determine if it's acceptable.

I'm not sure we have very good metrics for measuring the improvement except
reduced amount of reports of excessive checkerboarding :) Most of the bugs
related to this have required manual testing and that's also how I've been
evaluating this change. It's easy to reproduce by scrolling some large document
while something else GPU intensive is going on, like WebGL or video. Prior to
this change, you'd scroll and see nothing but checkerboarding for about a
second. That should not be happening after this change has landed. You might see
checkerboarding but only for a very short amount of time. I'll take a look at
the existing benchmarks to see if there's not something that reflect this
improvement or try to create something if we don't have anything already.

[piman, 2014-10-29 22:58:40]

On Wed, Oct 29, 2014 at 3:19 PM, <reveman@chromium.org> wrote:

> On 2014/10/29 21:05:55, piman (Very slow to review) wrote:
>
>> LGTM.
>> What are the metrics we can monitor to evaluate if this is an improvement?
>>
>
> The most important metric is our existing smoothness benchmarks. Ideally,
> they
> shouldn't regress at all. If some benchmark regresses then we need to
> evaluate
> why and determine if it's acceptable.
>
> I'm not sure we have very good metrics for measuring the improvement except
> reduced amount of reports of excessive checkerboarding :) Most of the bugs
> related to this have required manual testing and that's also how I've been
> evaluating this change. It's easy to reproduce by scrolling some large
> document
> while something else GPU intensive is going on, like WebGL or video. Prior
> to
> this change, you'd scroll and see nothing but checkerboarding for about a
> second. That should not be happening after this change has landed. You
> might see
> checkerboarding but only for a very short amount of time. I'll take a look
> at
> the existing benchmarks to see if there's not something that reflect this
> improvement or try to create something if we don't have anything already.
>

Ok. I'm mostly wondering about our many Chrome OS configs, I don't think
we've done manual testing on all of those.
ihf@ says we're probably running them in the labs, so we should
double-check there.


> https://codereview.chromium.org/686013002/
>

To unsubscribe from this group and stop receiving emails from it, send an email
to chromium-reviews+unsubscribe@chromium.org.

[reveman, 2014-10-29 23:21:56]

On 2014/10/29 22:58:40, piman (Very slow to review) wrote:
> On Wed, Oct 29, 2014 at 3:19 PM, <mailto:reveman@chromium.org> wrote:
> 
> > On 2014/10/29 21:05:55, piman (Very slow to review) wrote:
> >
> >> LGTM.
> >> What are the metrics we can monitor to evaluate if this is an improvement?
> >>
> >
> > The most important metric is our existing smoothness benchmarks. Ideally,
> > they
> > shouldn't regress at all. If some benchmark regresses then we need to
> > evaluate
> > why and determine if it's acceptable.
> >
> > I'm not sure we have very good metrics for measuring the improvement except
> > reduced amount of reports of excessive checkerboarding :) Most of the bugs
> > related to this have required manual testing and that's also how I've been
> > evaluating this change. It's easy to reproduce by scrolling some large
> > document
> > while something else GPU intensive is going on, like WebGL or video. Prior
> > to
> > this change, you'd scroll and see nothing but checkerboarding for about a
> > second. That should not be happening after this change has landed. You
> > might see
> > checkerboarding but only for a very short amount of time. I'll take a look
> > at
> > the existing benchmarks to see if there's not something that reflect this
> > improvement or try to create something if we don't have anything already.
> >
> 
> Ok. I'm mostly wondering about our many Chrome OS configs, I don't think
> we've done manual testing on all of those.
> ihf@ says we're probably running them in the labs, so we should
> double-check there.

Ok, sounds good. I've only verified the improvement on a few chromeos devices.
The result has been exactly the same on each device I've tried so far though.

> 
> 
> > https://codereview.chromium.org/686013002/
> >
> 
> To unsubscribe from this group and stop receiving emails from it, send an
email
> to mailto:chromium-reviews+unsubscribe@chromium.org.

[piman, 2014-10-29 23:45:40]

On Wed, Oct 29, 2014 at 4:21 PM, <reveman@chromium.org> wrote:

> On 2014/10/29 22:58:40, piman (Very slow to review) wrote:
>
>  On Wed, Oct 29, 2014 at 3:19 PM, <mailto:reveman@chromium.org> wrote:
>>
>
>  > On 2014/10/29 21:05:55, piman (Very slow to review) wrote:
>> >
>> >> LGTM.
>> >> What are the metrics we can monitor to evaluate if this is an
>> improvement?
>> >>
>> >
>> > The most important metric is our existing smoothness benchmarks.
>> Ideally,
>> > they
>> > shouldn't regress at all. If some benchmark regresses then we need to
>> > evaluate
>> > why and determine if it's acceptable.
>> >
>> > I'm not sure we have very good metrics for measuring the improvement
>> except
>> > reduced amount of reports of excessive checkerboarding :) Most of the
>> bugs
>> > related to this have required manual testing and that's also how I've
>> been
>> > evaluating this change. It's easy to reproduce by scrolling some large
>> > document
>> > while something else GPU intensive is going on, like WebGL or video.
>> Prior
>> > to
>> > this change, you'd scroll and see nothing but checkerboarding for about
>> a
>> > second. That should not be happening after this change has landed. You
>> > might see
>> > checkerboarding but only for a very short amount of time. I'll take a
>> look
>> > at
>> > the existing benchmarks to see if there's not something that reflect
>> this
>> > improvement or try to create something if we don't have anything
>> already.
>> >
>>
>
>  Ok. I'm mostly wondering about our many Chrome OS configs, I don't think
>> we've done manual testing on all of those.
>> ihf@ says we're probably running them in the labs, so we should
>> double-check there.
>>
>
> Ok, sounds good. I've only verified the improvement on a few chromeos
> devices.
> The result has been exactly the same on each device I've tried so far
> though.
>

Great, thanks!

Antoine


>
>
>  > https://codereview.chromium.org/686013002/
>> >
>>
>
>  To unsubscribe from this group and stop receiving emails from it, send an
>>
> email
>
>> to mailto:chromium-reviews+unsubscribe@chromium.org.
>>
>
>
>
> https://codereview.chromium.org/686013002/
>

To unsubscribe from this group and stop receiving emails from it, send an email
to chromium-reviews+unsubscribe@chromium.org.

[reveman, 2014-10-30 17:17:30]

reveman@chromium.org changed reviewers:
+ asvitkine@chromium.org

[reveman, 2014-10-30 17:17:30]

+asvitkine for tools/metrics/

[Alexei Svitkine (slow), 2014-10-30 18:05:39]

LGTM assuming you address the comment below. Thanks

https://codereview.chromium.org/686013002/diff/20001/tools/metrics/histograms...
File tools/metrics/histograms/histograms.xml (left):

https://codereview.chromium.org/686013002/diff/20001/tools/metrics/histograms...
tools/metrics/histograms/histograms.xml:46884: -  <int value="1465624446"
label="disable-zero-copy"/>
Please keep the existing entry as it's needed to decode data from old versions.

[reveman, 2014-10-30 19:46:19]

https://codereview.chromium.org/686013002/diff/20001/tools/metrics/histograms...
File tools/metrics/histograms/histograms.xml (left):

https://codereview.chromium.org/686013002/diff/20001/tools/metrics/histograms...
tools/metrics/histograms/histograms.xml:46884: -  <int value="1465624446"
label="disable-zero-copy"/>
On 2014/10/30 18:05:39, Alexei Svitkine wrote:
> Please keep the existing entry as it's needed to decode data from old
versions.

Done.

[reveman, 2014-10-30 22:57:06]

I've created a telemetry page set that is a good metric for measuring the
improvement this change is supposed to provide:

https://codereview.chromium.org/688423002/

mean_pixels_approximated (which is the amount of low-res and checkerboarding) is
reduced significantly from this change.

Run this benchmark locally if you're interested in seeing what difference this
change will make. It's easy to see the difference when visually comparing the
test runs.

[danakj, 2014-10-31 14:49:54]

On Thu, Oct 30, 2014 at 6:57 PM, <reveman@chromium.org> wrote:

> I've created a telemetry page set that is a good metric for measuring the
> improvement this change is supposed to provide:
>
> https://codereview.chromium.org/688423002/
>
> mean_pixels_approximated (which is the amount of low-res and
> checkerboarding) is
> reduced significantly from this change.
>
> Run this benchmark locally if you're interested in seeing what difference
> this
> change will make. It's easy to see the difference when visually comparing
> the
> test runs.
>

Nice! The smoothness benchmark also has a number for.. incomplete tiles or
something.. why is dashboard still dead :(

To unsubscribe from this group and stop receiving emails from it, send an email
to chromium-reviews+unsubscribe@chromium.org.

[chromium-reviews, 2014-10-31 15:39:02]

On Fri, Oct 31, 2014 at 10:49 AM, Dana Jansens <danakj@chromium.org> wrote:

> On Thu, Oct 30, 2014 at 6:57 PM, <reveman@chromium.org> wrote:
>
>> I've created a telemetry page set that is a good metric for measuring the
>> improvement this change is supposed to provide:
>>
>> https://codereview.chromium.org/688423002/
>>
>> mean_pixels_approximated (which is the amount of low-res and
>> checkerboarding) is
>> reduced significantly from this change.
>>
>> Run this benchmark locally if you're interested in seeing what difference
>> this
>> change will make. It's easy to see the difference when visually comparing
>> the
>> test runs.
>>
>
> Nice! The smoothness benchmark also has a number for.. incomplete tiles or
> something..
>

I'm using the smoothness benchmark and mean_pixels_approximated, which
afaict the is sufficient and the only information about incomplete tiles
being reported by the compositor. The problem with existing tests was just
that none of the page sets scroll a page fast enough to expose this issue.
I'm only adding two new pages in that patch but will probably follow up
with a few more soon. A WebGL version of the canvas page would be useful.


> why is dashboard still dead :(
>

To unsubscribe from this group and stop receiving emails from it, send an email
to chromium-reviews+unsubscribe@chromium.org.

[danakj, 2014-10-31 15:43:46]

On Fri, Oct 31, 2014 at 11:39 AM, David Reveman <reveman@google.com> wrote:

>
>
> On Fri, Oct 31, 2014 at 10:49 AM, Dana Jansens <danakj@chromium.org>
> wrote:
>
>> On Thu, Oct 30, 2014 at 6:57 PM, <reveman@chromium.org> wrote:
>>
>>> I've created a telemetry page set that is a good metric for measuring the
>>> improvement this change is supposed to provide:
>>>
>>> https://codereview.chromium.org/688423002/
>>>
>>> mean_pixels_approximated (which is the amount of low-res and
>>> checkerboarding) is
>>> reduced significantly from this change.
>>>
>>> Run this benchmark locally if you're interested in seeing what
>>> difference this
>>> change will make. It's easy to see the difference when visually
>>> comparing the
>>> test runs.
>>>
>>
>> Nice! The smoothness benchmark also has a number for.. incomplete tiles
>> or something..
>>
>
> I'm using the smoothness benchmark and mean_pixels_approximated, which
> afaict the is sufficient and the only information about incomplete tiles
> being reported by the compositor. The problem with existing tests was just
> that none of the page sets scroll a page fast enough to expose this issue.
> I'm only adding two new pages in that patch but will probably follow up
> with a few more soon. A WebGL version of the canvas page would be useful.
>

Oooh okay, that's awesome! Thanks for adding those.


>
>
>> why is dashboard still dead :(
>>
>
>

To unsubscribe from this group and stop receiving emails from it, send an email
to chromium-reviews+unsubscribe@chromium.org.

[reveman, 2014-11-04 01:42:36]

The CQ bit was checked by reveman@chromium.org

[commit-bot: I haz the power, 2014-11-04 01:46:16]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/686013002/40001

[commit-bot: I haz the power, 2014-11-04 03:40:40]

Committed patchset #3 (id:40001)

[commit-bot: I haz the power, 2014-11-04 03:41:18]

Patchset 3 (id:??) landed as
https://crrev.com/91a0a8702ab11d02ff9b6a6ad9e8ab7b080c0f2f
Cr-Commit-Position: refs/heads/master@{#302567}