android webview: allow cc to fail hardware draw

android webview: allow cc to fail hardware draw

Replace draw_and_swap_full_viewport_every_frame output surface
capability with resourceless_software_draw_, since forcing a draw is
only needed for software draws now, which is decided at draw time.

This also requires plumbing resourceless_software_draw_ bool through
to scheduler to force draws, instead of
using_synchronous_renderer_compositor setting.

Note that resourceless_software_draw_ is no longer a static value.
It can change frame by frame.

BUG=419795
CQ_INCLUDE_TRYBOTS=tryserver.blink:linux_blink_rel

Committed: https://crrev.com/8ca8390151cdc16ae25b82b85148bfd97def043e
Cr-Commit-Position: refs/heads/master@{#355730}

[boliu, 2015-10-09 18:09:50]

boliu@chromium.org changed reviewers:
+ brianderson@chromium.org

[boliu, 2015-10-09 18:09:51]

https://codereview.chromium.org/1394263004/diff/20001/cc/scheduler/scheduler_...
File cc/scheduler/scheduler_state_machine.cc (right):

https://codereview.chromium.org/1394263004/diff/20001/cc/scheduler/scheduler_...
cc/scheduler/scheduler_state_machine.cc:268: // TODO(boliu): This contradicts
comment above that
Question for Brian:

So this patch shoves resourceless software (which requires always drawing) and
visible into CanDraw. Seems like I can't really get away with scheduler being
oblivious to whether the current draw is resourceless software draw or not. I
had a DCHECK_IMPLIES(!visible_, !can_draw_); before, but then of course that's
obviously doesn't hold with resourceless software mode.

Are you happy with adding this to PendingActivationsShouldBeForced:
if (!PendingDrawsShouldBeAborted())
  return false;

The alternative is to plumb resourceless software draw through to the scheduler,
which means this patch needs a rewrite.

Any thoughts?

[boliu, 2015-10-09 18:39:54]

https://codereview.chromium.org/1394263004/diff/20001/cc/scheduler/scheduler_...
File cc/scheduler/scheduler_state_machine.cc (right):

https://codereview.chromium.org/1394263004/diff/20001/cc/scheduler/scheduler_...
cc/scheduler/scheduler_state_machine.cc:268: // TODO(boliu): This contradicts
comment above that
On 2015/10/09 18:09:51, boliu (slow to review) wrote:
> Question for Brian:
> 
> So this patch shoves resourceless software (which requires always drawing) and
> visible into CanDraw. Seems like I can't really get away with scheduler being
> oblivious to whether the current draw is resourceless software draw or not. I
> had a DCHECK_IMPLIES(!visible_, !can_draw_); before, but then of course that's
> obviously doesn't hold with resourceless software mode.
> 
> Are you happy with adding this to PendingActivationsShouldBeForced:
> if (!PendingDrawsShouldBeAborted())
>   return false;
> 
> The alternative is to plumb resourceless software draw through to the
scheduler,
> which means this patch needs a rewrite.
> 
> Any thoughts?

This goes a bit deeper, since resourceless software can flip between true and
false very often. Is it possible to force activate (!visible &&
!resourcless_software), and then resourceless flips to true, and the pending
draw is not aborted?

(Actually articulating that, not sure what's wrong with that picture..)

[boliu, 2015-10-20 20:56:04]

ptal after offline discussion

tried to keep state machine changes small

Patch plumbs resourceless software draw bool into the state machine. It's
tempting to just merge it as part of can_draw_, but that might get a bit
complicated..

[boliu, 2015-10-21 20:53:21]

mild ping

[brianderson, 2015-10-21 22:43:04]

https://codereview.chromium.org/1394263004/diff/100001/cc/scheduler/scheduler...
File cc/scheduler/scheduler_state_machine.cc (right):

https://codereview.chromium.org/1394263004/diff/100001/cc/scheduler/scheduler...
cc/scheduler/scheduler_state_machine.cc:261: if (resourceless_draw_)
Please update the comment above.

https://codereview.chromium.org/1394263004/diff/100001/cc/scheduler/scheduler...
File cc/scheduler/scheduler_state_machine_unittest.cc (right):

https://codereview.chromium.org/1394263004/diff/100001/cc/scheduler/scheduler...
cc/scheduler/scheduler_state_machine_unittest.cc:1794:
state.SetResourcelessSoftareDraw(true);
Since this is a dynamic setting now, can you update this test or the Scheduler
test to switch the mode on and off?

https://codereview.chromium.org/1394263004/diff/100001/cc/trees/layer_tree_ho...
File cc/trees/layer_tree_host_impl.cc (right):

https://codereview.chromium.org/1394263004/diff/100001/cc/trees/layer_tree_ho...
cc/trees/layer_tree_host_impl.cc:1451:
client_->OnResourcelessSoftareDrawStateChanged(resourceless_software_draw);
Is it possible this is triggered within a draw? Just wondering if we need to be
worried about any weird ordering issues.

https://codereview.chromium.org/1394263004/diff/100001/cc/trees/layer_tree_ho...
File cc/trees/layer_tree_host_impl_unittest.cc (right):

https://codereview.chromium.org/1394263004/diff/100001/cc/trees/layer_tree_ho...
cc/trees/layer_tree_host_impl_unittest.cc:5753: SetAlwaysDraw();
Why isn't this called from other LayerTreeHostImplViewportCoveredTest tests when
those used to force draws before this patch too?

[boliu, 2015-10-21 22:46:34]

answer comments only

https://codereview.chromium.org/1394263004/diff/100001/cc/trees/layer_tree_ho...
File cc/trees/layer_tree_host_impl.cc (right):

https://codereview.chromium.org/1394263004/diff/100001/cc/trees/layer_tree_ho...
cc/trees/layer_tree_host_impl.cc:1451:
client_->OnResourcelessSoftareDrawStateChanged(resourceless_software_draw);
On 2015/10/21 22:43:04, brianderson wrote:
> Is it possible this is triggered within a draw? Just wondering if we need to
be
> worried about any weird ordering issues.

As in inside LTHI::OnDraw? Nope

https://codereview.chromium.org/1394263004/diff/100001/cc/trees/layer_tree_ho...
File cc/trees/layer_tree_host_impl_unittest.cc (right):

https://codereview.chromium.org/1394263004/diff/100001/cc/trees/layer_tree_ho...
cc/trees/layer_tree_host_impl_unittest.cc:5753: SetAlwaysDraw();
On 2015/10/21 22:43:04, brianderson wrote:
> Why isn't this called from other LayerTreeHostImplViewportCoveredTest tests
when
> those used to force draws before this patch too?

The above two tests have always_draw = false.

[boliu, 2015-10-21 23:04:44]

And new patch set

https://codereview.chromium.org/1394263004/diff/100001/cc/scheduler/scheduler...
File cc/scheduler/scheduler_state_machine.cc (right):

https://codereview.chromium.org/1394263004/diff/100001/cc/scheduler/scheduler...
cc/scheduler/scheduler_state_machine.cc:261: if (resourceless_draw_)
On 2015/10/21 22:43:04, brianderson wrote:
> Please update the comment above.

Umm, that comment is still totally legit! Android WebView and software draws
both still apply. (It was actually slightly wrong before this patch)

https://codereview.chromium.org/1394263004/diff/100001/cc/scheduler/scheduler...
File cc/scheduler/scheduler_state_machine_unittest.cc (right):

https://codereview.chromium.org/1394263004/diff/100001/cc/scheduler/scheduler...
cc/scheduler/scheduler_state_machine_unittest.cc:1794:
state.SetResourcelessSoftareDraw(true);
On 2015/10/21 22:43:04, brianderson wrote:
> Since this is a dynamic setting now, can you update this test or the Scheduler
> test to switch the mode on and off?

Done.

[brianderson, 2015-10-21 23:15:28]

lgtm

https://codereview.chromium.org/1394263004/diff/100001/cc/scheduler/scheduler...
File cc/scheduler/scheduler_state_machine.cc (right):

https://codereview.chromium.org/1394263004/diff/100001/cc/scheduler/scheduler...
cc/scheduler/scheduler_state_machine.cc:261: if (resourceless_draw_)
On 2015/10/21 23:04:44, boliu wrote:
> On 2015/10/21 22:43:04, brianderson wrote:
> > Please update the comment above.
> 
> Umm, that comment is still totally legit! Android WebView and software draws
> both still apply. (It was actually slightly wrong before this patch)

Ha! Nice. =)

[boliu, 2015-10-21 23:16:39]

boliu@chromium.org changed reviewers:
+ danakj@chromium.org

[boliu, 2015-10-21 23:16:39]

+danakj to take a look too?

[danakj, 2015-10-22 00:32:22]

will tomorrow.

On Wed, Oct 21, 2015 at 4:16 PM, <boliu@chromium.org> wrote:

> +danakj to take a look too?
>
> https://codereview.chromium.org/1394263004/
>

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

[danakj, 2015-10-22 18:36:29]

> WIP

Update patch description plz

[boliu, 2015-10-22 18:41:10]

Description was changed from

==========
android webview: allow cc to fail hardware draw

WIP

Replace draw_and_swap_full_viewport_every_frame output surface
capability with resourceless_software_draw_, since forcing a draw is
only needed for software draws now, which is decided at draw time.

BUG=419795
CQ_INCLUDE_TRYBOTS=tryserver.blink:linux_blink_rel
==========

to

==========
android webview: allow cc to fail hardware draw

Replace draw_and_swap_full_viewport_every_frame output surface
capability with resourceless_software_draw_, since forcing a draw is
only needed for software draws now, which is decided at draw time.

This also requires plumbing resourceless_software_draw_ bool through
to scheduler to force draws, instead of
using_synchronous_renderer_compositor setting.

Note that resourceless_software_draw_ is no longer a static value.

BUG=419795
CQ_INCLUDE_TRYBOTS=tryserver.blink:linux_blink_rel
==========

[boliu, 2015-10-22 18:41:53]

Description was changed from

==========
android webview: allow cc to fail hardware draw

Replace draw_and_swap_full_viewport_every_frame output surface
capability with resourceless_software_draw_, since forcing a draw is
only needed for software draws now, which is decided at draw time.

This also requires plumbing resourceless_software_draw_ bool through
to scheduler to force draws, instead of
using_synchronous_renderer_compositor setting.

Note that resourceless_software_draw_ is no longer a static value.

BUG=419795
CQ_INCLUDE_TRYBOTS=tryserver.blink:linux_blink_rel
==========

to

==========
android webview: allow cc to fail hardware draw

Replace draw_and_swap_full_viewport_every_frame output surface
capability with resourceless_software_draw_, since forcing a draw is
only needed for software draws now, which is decided at draw time.

This also requires plumbing resourceless_software_draw_ bool through
to scheduler to force draws, instead of
using_synchronous_renderer_compositor setting.

Note that resourceless_software_draw_ is no longer a static value.
It can change frame by frame.

BUG=419795
CQ_INCLUDE_TRYBOTS=tryserver.blink:linux_blink_rel
==========

[boliu, 2015-10-22 18:42:06]

On 2015/10/22 18:36:29, danakj wrote:
> > WIP
> 
> Update patch description plz

Oops. Done

[danakj, 2015-10-22 18:49:23]

https://codereview.chromium.org/1394263004/diff/120001/cc/trees/layer_tree_ho...
File cc/trees/layer_tree_host_impl.cc (right):

https://codereview.chromium.org/1394263004/diff/120001/cc/trees/layer_tree_ho...
cc/trees/layer_tree_host_impl.cc:947: // When resourceless software draw, we
don't have control over the surface the
"When doing a resourceless..."

https://codereview.chromium.org/1394263004/diff/120001/cc/trees/layer_tree_ho...
cc/trees/layer_tree_host_impl.cc:1451:
client_->OnResourcelessSoftareDrawStateChanged(resourceless_software_draw);
The only thing I can see maybe being better is that it's not obvious to me what
order things happen when you read the code. Like will the scheduler always be
told about the draw state changing before drawing, and then will it always be
reset back to false at the right times?

Another way to approach it might be to pass resourceless_software_draw_ to
OnDrawForOutputSurface(), then have the scheduler set it true from that, and
reset it to false after the draw completes.

What do you think Brian?

https://codereview.chromium.org/1394263004/diff/120001/cc/trees/layer_tree_ho...
File cc/trees/layer_tree_host_impl_unittest.cc (right):

https://codereview.chromium.org/1394263004/diff/120001/cc/trees/layer_tree_ho...
cc/trees/layer_tree_host_impl_unittest.cc:5550: if (always_draw) {
maybe rename always_draw to software?

https://codereview.chromium.org/1394263004/diff/120001/cc/trees/layer_tree_ho...
cc/trees/layer_tree_host_impl_unittest.cc:5702: void SetAlwaysDraw() {
SetResourcelessSoftwareDraw?

https://codereview.chromium.org/1394263004/diff/120001/cc/trees/layer_tree_ho...
File cc/trees/layer_tree_host_unittest.cc (right):

https://codereview.chromium.org/1394263004/diff/120001/cc/trees/layer_tree_ho...
cc/trees/layer_tree_host_unittest.cc:2489:
MULTI_THREAD_TEST_F(LayerTreeHostTestResourcelessSoftwareDraw);
Leave a comment why this can't/shouldn't test single thread

[boliu, 2015-10-22 18:58:08]

https://codereview.chromium.org/1394263004/diff/120001/cc/trees/layer_tree_ho...
File cc/trees/layer_tree_host_impl.cc (right):

https://codereview.chromium.org/1394263004/diff/120001/cc/trees/layer_tree_ho...
cc/trees/layer_tree_host_impl.cc:1451:
client_->OnResourcelessSoftareDrawStateChanged(resourceless_software_draw);
On 2015/10/22 18:49:23, danakj wrote:
> The only thing I can see maybe being better is that it's not obvious to me
what
> order things happen when you read the code. Like will the scheduler always be
> told about the draw state changing before drawing, and then will it always be
> reset back to false at the right times?

Yep. Always reset back to false after the OnDraw

> 
> Another way to approach it might be to pass resourceless_software_draw_ to
> OnDrawForOutputSurface(), then have the scheduler set it true from that, and
> reset it to false after the draw completes.
> 
> What do you think Brian?

I vote for doing that (although fixing up tests is going to be more involved)

Might be debatable some other params here should be passed in from OnDraw as
well, but let's have that debate later.

[brianderson, 2015-10-22 20:53:35]

https://codereview.chromium.org/1394263004/diff/120001/cc/trees/layer_tree_ho...
File cc/trees/layer_tree_host_impl.cc (right):

https://codereview.chromium.org/1394263004/diff/120001/cc/trees/layer_tree_ho...
cc/trees/layer_tree_host_impl.cc:1451:
client_->OnResourcelessSoftareDrawStateChanged(resourceless_software_draw);
On 2015/10/22 18:58:08, boliu wrote:
> On 2015/10/22 18:49:23, danakj wrote:
> > The only thing I can see maybe being better is that it's not obvious to me
> what
> > order things happen when you read the code. Like will the scheduler always
be
> > told about the draw state changing before drawing, and then will it always
be
> > reset back to false at the right times?
> 
> Yep. Always reset back to false after the OnDraw
> 
> > 
> > Another way to approach it might be to pass resourceless_software_draw_ to
> > OnDrawForOutputSurface(), then have the scheduler set it true from that, and
> > reset it to false after the draw completes.
> > 
> > What do you think Brian?
> 
> I vote for doing that (although fixing up tests is going to be more involved)
> 
> Might be debatable some other params here should be passed in from OnDraw as
> well, but let's have that debate later.

I'd vote for an argument as well. I didn't realize this flag would toggle that
often.

https://codereview.chromium.org/1394263004/diff/120001/content/renderer/andro...
File content/renderer/android/synchronous_compositor_output_surface.cc (right):

https://codereview.chromium.org/1394263004/diff/120001/content/renderer/andro...
content/renderer/android/synchronous_compositor_output_surface.cc:198:
SetNeedsRedrawRect(gfx::Rect(viewport.size()));
Does this also need to be called for the first hardware draw after a software
draw? Or alternatively accumulate the damage rects of all previous software
draws and union that with the damage for the first hardware draw?

[boliu, 2015-10-22 20:57:53]

https://codereview.chromium.org/1394263004/diff/120001/content/renderer/andro...
File content/renderer/android/synchronous_compositor_output_surface.cc (right):

https://codereview.chromium.org/1394263004/diff/120001/content/renderer/andro...
content/renderer/android/synchronous_compositor_output_surface.cc:198:
SetNeedsRedrawRect(gfx::Rect(viewport.size()));
On 2015/10/22 20:53:35, brianderson wrote:
> Does this also need to be called for the first hardware draw after a software
> draw? Or alternatively accumulate the damage rects of all previous software
> draws and union that with the damage for the first hardware draw?

Good question. I think the answer is yes.

This is proably better: move all this damage logic into LTHI::OnDraw as well.
Then for software, save the damage at the beginning, damage viewport, draw, and
restore the old damage. That would be the "right" behavior I think?

[danakj, 2015-10-22 21:10:55]

On Thu, Oct 22, 2015 at 1:57 PM, <boliu@chromium.org> wrote:

>
>
>
https://codereview.chromium.org/1394263004/diff/120001/content/renderer/andro...
> File content/renderer/android/synchronous_compositor_output_surface.cc
> (right):
>
>
>
https://codereview.chromium.org/1394263004/diff/120001/content/renderer/andro...
> content/renderer/android/synchronous_compositor_output_surface.cc:198:
> SetNeedsRedrawRect(gfx::Rect(viewport.size()));
> On 2015/10/22 20:53:35, brianderson wrote:
>
>> Does this also need to be called for the first hardware draw after a
>>
> software
>
>> draw? Or alternatively accumulate the damage rects of all previous
>>
> software
>
>> draws and union that with the damage for the first hardware draw?
>>
>
> Good question. I think the answer is yes.
>
> This is proably better: move all this damage logic into LTHI::OnDraw as
> well. Then for software, save the damage at the beginning, damage
> viewport, draw, and restore the old damage. That would be the "right"
> behavior I think?
>

I'd rather we just damage everything when we go back to hardware. There's
damage in layers that is lost when you draw, and trying to save that will
be a bunch of complexity. If I'm understanding this right.

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

[boliu, 2015-10-22 21:20:56]

30-minutes in, I want to separate out the refactor out of this change; moving
only resourceless bool makes things more weird..

So goign to move all of these to OnDraw:
transform
viewport
clip
resourceless_software_draw

I suppose the refactor could be done before or after this change though. Any
preferences?

On 2015/10/22 21:10:55, danakj wrote:
> On Thu, Oct 22, 2015 at 1:57 PM, <mailto:boliu@chromium.org> wrote:
> 
> >
> >
> >
>
https://codereview.chromium.org/1394263004/diff/120001/content/renderer/andro...
> > File content/renderer/android/synchronous_compositor_output_surface.cc
> > (right):
> >
> >
> >
>
https://codereview.chromium.org/1394263004/diff/120001/content/renderer/andro...
> > content/renderer/android/synchronous_compositor_output_surface.cc:198:
> > SetNeedsRedrawRect(gfx::Rect(viewport.size()));
> > On 2015/10/22 20:53:35, brianderson wrote:
> >
> >> Does this also need to be called for the first hardware draw after a
> >>
> > software
> >
> >> draw? Or alternatively accumulate the damage rects of all previous
> >>
> > software
> >
> >> draws and union that with the damage for the first hardware draw?
> >>
> >
> > Good question. I think the answer is yes.
> >
> > This is proably better: move all this damage logic into LTHI::OnDraw as
> > well. Then for software, save the damage at the beginning, damage
> > viewport, draw, and restore the old damage. That would be the "right"
> > behavior I think?
> >
> 
> I'd rather we just damage everything when we go back to hardware. There's
> damage in layers that is lost when you draw, and trying to save that will
> be a bunch of complexity. If I'm understanding this right.

Sure. Still easier to do it before a software OnDraw returns I think.

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

[danakj, 2015-10-22 21:26:45]

On Thu, Oct 22, 2015 at 2:20 PM, <boliu@chromium.org> wrote:

> 30-minutes in, I want to separate out the refactor out of this change;
> moving
> only resourceless bool makes things more weird..
>
> So goign to move all of these to OnDraw:
> transform
> viewport
> clip
> resourceless_software_draw
>
> I suppose the refactor could be done before or after this change though.
> Any
> preferences?
>

Mildly prefer refactor before, but I trust you to follow up on it so if
that's annoying could go after IMO.

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

[boliu, 2015-10-22 21:50:09]

Refactor after this then :) This fixes a flicker that's really irking me..

https://codereview.chromium.org/1394263004/diff/120001/cc/trees/layer_tree_ho...
File cc/trees/layer_tree_host_impl.cc (right):

https://codereview.chromium.org/1394263004/diff/120001/cc/trees/layer_tree_ho...
cc/trees/layer_tree_host_impl.cc:947: // When resourceless software draw, we
don't have control over the surface the
On 2015/10/22 18:49:23, danakj wrote:
> "When doing a resourceless..."

Done.

https://codereview.chromium.org/1394263004/diff/120001/cc/trees/layer_tree_ho...
File cc/trees/layer_tree_host_impl_unittest.cc (right):

https://codereview.chromium.org/1394263004/diff/120001/cc/trees/layer_tree_ho...
cc/trees/layer_tree_host_impl_unittest.cc:5550: if (always_draw) {
On 2015/10/22 18:49:23, danakj wrote:
> maybe rename always_draw to software?

Done.

https://codereview.chromium.org/1394263004/diff/120001/cc/trees/layer_tree_ho...
cc/trees/layer_tree_host_impl_unittest.cc:5702: void SetAlwaysDraw() {
On 2015/10/22 18:49:23, danakj wrote:
> SetResourcelessSoftwareDraw?

Done.

https://codereview.chromium.org/1394263004/diff/120001/cc/trees/layer_tree_ho...
File cc/trees/layer_tree_host_unittest.cc (right):

https://codereview.chromium.org/1394263004/diff/120001/cc/trees/layer_tree_ho...
cc/trees/layer_tree_host_unittest.cc:2489:
MULTI_THREAD_TEST_F(LayerTreeHostTestResourcelessSoftwareDraw);
On 2015/10/22 18:49:23, danakj wrote:
> Leave a comment why this can't/shouldn't test single thread

Done.

https://codereview.chromium.org/1394263004/diff/120001/content/renderer/andro...
File content/renderer/android/synchronous_compositor_output_surface.cc (right):

https://codereview.chromium.org/1394263004/diff/120001/content/renderer/andro...
content/renderer/android/synchronous_compositor_output_surface.cc:198:
SetNeedsRedrawRect(gfx::Rect(viewport.size()));
On 2015/10/22 20:57:53, boliu wrote:
> On 2015/10/22 20:53:35, brianderson wrote:
> > Does this also need to be called for the first hardware draw after a
software
> > draw? Or alternatively accumulate the damage rects of all previous software
> > draws and union that with the damage for the first hardware draw?
> 
> Good question. I think the answer is yes.
> 
> This is proably better: move all this damage logic into LTHI::OnDraw as well.
> Then for software, save the damage at the beginning, damage viewport, draw,
and
> restore the old damage. That would be the "right" behavior I think?

Keeping it at the end of InvokeComposite here for now.

[boliu, 2015-10-22 21:52:02]

oops, replied before upload finished, PS8 up now

[danakj, 2015-10-22 21:59:42]

That rebase + changes :P

LGTM

[boliu, 2015-10-22 22:01:29]

On 2015/10/22 21:59:42, danakj wrote:
> That rebase + changes :P

Oops. I have the habit of rebasing every morning :)

> 
> LGTM

[boliu, 2015-10-22 22:01:39]

The CQ bit was checked by boliu@chromium.org

[boliu, 2015-10-22 22:01:39]

The patchset sent to the CQ was uploaded after l-g-t-m from
brianderson@chromium.org
Link to the patchset: https://codereview.chromium.org/1394263004/#ps140001
(title: "review")

[commit-bot: I haz the power, 2015-10-22 22:03:32]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1394263004/140001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1394263004/140001

[commit-bot: I haz the power, 2015-10-23 00:28:23]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2015-10-23 00:28:24]

Try jobs failed on following builders:
  linux_android_rel_ng on tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_android_r...)

[boliu, 2015-10-23 00:41:08]

On 2015/10/23 00:28:24, commit-bot: I haz the power wrote:
> Try jobs failed on following builders:
>   linux_android_rel_ng on tryserver.chromium.linux (JOB_FAILED,
>
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_android_r...)

Time out on a test that I filed a bug for earlier this week because it
consistently fails for me locally and I was wondering why it was passing at all
on the bots. Yay android :p

[boliu, 2015-10-23 03:38:58]

On 2015/10/23 00:41:08, boliu wrote:
> On 2015/10/23 00:28:24, commit-bot: I haz the power wrote:
> > Try jobs failed on following builders:
> >   linux_android_rel_ng on tryserver.chromium.linux (JOB_FAILED,
> >
>
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_android_r...)
> 
> Time out on a test that I filed a bug for earlier this week because it
> consistently fails for me locally and I was wondering why it was passing at
all
> on the bots. Yay android :p

/me set a command line switch locally that doesn't work yet, so that's why
everything was failing locally for me

then the real test failures are due to infinite invalidate-redraw loop, due to
setting damage at the *end* of software draw. So my brain skipped a step when I
thought that was ok. Went with setting a flag to trigger damage on next hardware
draw instead

Should be ok now.. I hope

[boliu, 2015-10-23 03:39:08]

The CQ bit was checked by boliu@chromium.org

[boliu, 2015-10-23 03:39:08]

The patchset sent to the CQ was uploaded after l-g-t-m from danakj@chromium.org,
brianderson@chromium.org
Link to the patchset: https://codereview.chromium.org/1394263004/#ps160001
(title: "damage before hardware to avoid invalidate-draw loop")

[commit-bot: I haz the power, 2015-10-23 03:39:20]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1394263004/160001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1394263004/160001

[commit-bot: I haz the power, 2015-10-23 04:36:23]

Committed patchset #9 (id:160001)

[commit-bot: I haz the power, 2015-10-23 04:37:14]

Patchset 9 (id:??) landed as
https://crrev.com/8ca8390151cdc16ae25b82b85148bfd97def043e
Cr-Commit-Position: refs/heads/master@{#355730}