android: Add test for ContentViewCore readback

android: Add test for ContentViewCore readback

This test renders a blue screen and grabs a snapshot of the content.  The
test checks that the pixel in the middle of the snapshot is blue.

BUG=372792
NOTRY=true

Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=280381

Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=280446

[powei, 2014-06-24 21:31:52]

https://codereview.chromium.org/358513002/diff/1/content/public/android/javat...
File
content/public/android/javatests/src/org/chromium/content/browser/ContentViewReadbackTest.java
(right):

https://codereview.chromium.org/358513002/diff/1/content/public/android/javat...
content/public/android/javatests/src/org/chromium/content/browser/ContentViewReadbackTest.java:95:
runTestOnUiThread(yFling);
This hack is not great i know.  Please let me know if you know of a signal that
indicates whether RWHVAndroid has a layer or not.

Also, if there's a way to force a composite from here, that'd would be great for
below.

[Ted C, 2014-06-26 02:27:00]

lgtm...sievers or dtrainor might now a more reliable way to handle forcing a
composite, but this seems reasonable to me.

https://codereview.chromium.org/358513002/diff/1/content/public/android/javat...
File
content/public/android/javatests/src/org/chromium/content/browser/ContentViewReadbackTest.java
(right):

https://codereview.chromium.org/358513002/diff/1/content/public/android/javat...
content/public/android/javatests/src/org/chromium/content/browser/ContentViewReadbackTest.java:95:
runTestOnUiThread(yFling);
On 2014/06/24 21:31:52, powei wrote:
> This hack is not great i know.  Please let me know if you know of a signal
that
> indicates whether RWHVAndroid has a layer or not.
> 
> Also, if there's a way to force a composite from here, that'd would be great
for
> below.

What about WebContentsObserverAndroid#didFirstVisuallyNonEmptyPaint?  Granted, I
think that can still have issues about content sizing and things like that.  It
might need to be that and a combintation of onOffsetsForFullscreenChanged (which
is the only callback from updateFrameInfo on every frame).

With that said, that could be just as gross and somewhat deterministic.  Maybe
you could just use the CriteriaHelper to poll for the height being 5000px as set
in the page specification above.  In the end, it might end up being as gross.

https://codereview.chromium.org/358513002/diff/20001/content/public/android/j...
File
content/public/android/javatests/src/org/chromium/content/browser/ContentViewReadbackTest.java
(right):

https://codereview.chromium.org/358513002/diff/20001/content/public/android/j...
content/public/android/javatests/src/org/chromium/content/browser/ContentViewReadbackTest.java:97:
runTestOnUiThread(new Runnable() {
normally, I think we use ThreadUtils.runOnUiThreadBlocking (probably the same
end result though)

[no sievers, 2014-06-26 19:23:00]

On 2014/06/26 02:27:00, Ted C wrote:
> lgtm...sievers or dtrainor might now a more reliable way to handle forcing a
> composite, but this seems reasonable to me.
> 

It should not be necessary to trigger a composite, CopyFromCompositingSurface()
should imply that by causing an invalidation (it must be doing it currently
because we create a new layer for readback and attach it somewhere which
triggers needs composite).

[powei, 2014-06-26 23:49:03]

On 2014/06/26 19:23:00, sievers wrote:
> On 2014/06/26 02:27:00, Ted C wrote:
> > lgtm...sievers or dtrainor might now a more reliable way to handle forcing a
> > composite, but this seems reasonable to me.
> > 
> 
> It should not be necessary to trigger a composite,
CopyFromCompositingSurface()
> should imply that by causing an invalidation (it must be doing it currently
> because we create a new layer for readback and attach it somewhere which
> triggers needs composite).

Yeah you're right.  I was thinking of an old case where the readback was on the
RWHVAndroid layer.  Thanks.

[powei, 2014-06-26 23:50:10]

https://codereview.chromium.org/358513002/diff/20001/content/public/android/j...
File
content/public/android/javatests/src/org/chromium/content/browser/ContentViewReadbackTest.java
(right):

https://codereview.chromium.org/358513002/diff/20001/content/public/android/j...
content/public/android/javatests/src/org/chromium/content/browser/ContentViewReadbackTest.java:97:
runTestOnUiThread(new Runnable() {
On 2014/06/26 02:27:00, Ted C wrote:
> normally, I think we use ThreadUtils.runOnUiThreadBlocking (probably the same
> end result though)

Done.

[powei, 2014-06-27 00:43:58]

The CQ bit was checked by powei@chromium.org

[commit-bot: I haz the power, 2014-06-27 00:45:48]

CQ is trying da patch. Follow status at
 https://chromium-status.appspot.com/cq/powei@chromium.org/358513002/40001

[powei, 2014-06-27 16:53:00]

The CQ bit was checked by powei@chromium.org

[commit-bot: I haz the power, 2014-06-27 16:54:04]

CQ is trying da patch. Follow status at
 https://chromium-status.appspot.com/cq/powei@chromium.org/358513002/60001

[commit-bot: I haz the power, 2014-06-27 19:25:14]

FYI, CQ is re-trying this CL (attempt #1).
The failing builders are:
  chromium_presubmit on tryserver.chromium
(http://build.chromium.org/p/tryserver.chromium/builders/chromium_presubmit/bu...)

[powei, 2014-06-27 19:26:10]

The CQ bit was unchecked by powei@chromium.org

[powei, 2014-06-27 19:28:58]

On 2014/06/27 19:26:10, powei wrote:
> The CQ bit was unchecked by mailto:powei@chromium.org

Failing on presubmit due to findbug addition.  I'm going to NOTRY this.  The
findbug error will be addressed and removed in a later patch where I will remove
the boolean from onFinishGetBitmap.

[powei, 2014-06-27 19:29:06]

The CQ bit was checked by powei@chromium.org

[commit-bot: I haz the power, 2014-06-27 19:30:24]

CQ is trying da patch. Follow status at
 https://chromium-status.appspot.com/cq/powei@chromium.org/358513002/60001

[commit-bot: I haz the power, 2014-06-27 19:31:55]

Change committed as 280381

[powei, 2014-06-27 19:42:34]

A revert of this CL has been created in
https://codereview.chromium.org/359043002/ by powei@chromium.org.

The reason for reverting is: broke win_gpu because of findbugs addition.  Will
rebase and try again..

[powei, 2014-06-27 23:37:28]

The CQ bit was checked by powei@chromium.org

[commit-bot: I haz the power, 2014-06-27 23:38:41]

CQ is trying da patch. Follow status at
 https://chromium-status.appspot.com/cq/powei@chromium.org/358513002/80001

[commit-bot: I haz the power, 2014-06-27 23:40:10]

Change committed as 280446