1209801 - Content is scaled twice physical resolution

Status: VERIFIED FIXED

(Core :: Graphics: Layers, defect)

Description

[Bill Gianopoulos [:WG9s]]

The content area displays incorrectly on the Samsung Galaxy TAB 2 7.0.  It appears that the left half of the windows displays left adjusted on the left half of the screen 2 X bigger than normal and the right hand half is right adjusted also 2x bigger than normal which leaves the center portion of the screen not displayed at all.  I do not see this issue on my Nexus 7 2012 running latest Lollipop.  Screen shots to follow.

Comment 1

[Bill Gianopoulos [:WG9s]]

Attachment: screenshot galaxy about: page

Comment 2

[Bill Gianopoulos [:WG9s]]

Attachment: screenshot nexus about: page

Comment 3

[Bill Gianopoulos [:WG9s]]

Attachment: screenshot galaxy WG9s builds page

Comment 4

[Bill Gianopoulos [:WG9s]]

Attachment: screenshot nexus WG9s builds page

Comment 5

[Bill Gianopoulos [:WG9s]]

Setting setting layers.tiles.adjust = false appears to avoid the issue.

Comment 6

[Bill Gianopoulos [:WG9s]]

It would be really nice if this turned out to be an android version issue rather than a hardware support type issue.  If the layers.tiles.adjust=false path is intended to live on then could be a simple force it to false if android version is below minimum version required to make it work.

Comment 7

[Bill Gianopoulos [:WG9s]]

I added the regression keyword, as this worked correctly using the 9/28 nightly build and files with the 9/29 builds.

Comment 8

[Bill Gianopoulos [:WG9s]]

Oh I should mention, Android 4.2.2 is the latest vendor supported Android version on this device.

Comment 9

[James Willcox (:snorp) ([e-mail]) (he/him)]

Milan, this seems to be fallout from tile size changes. Can we get someone to look into why this could be happening? I only know how to change prefs :)

Comment 10

[Bill Gianopoulos [:WG9s]]

hg bisect said:

The first bad revision is:
changeset:   264757:9fea88097171
user:        James Willcox <[e-mail]>
date:        Wed Aug 26 17:33:16 2015 -0500
summary:     Bug 1182665 - Adjust tile sizes depending on the screen size r=nical

Comment 11

[James Willcox (:snorp) ([e-mail]) (he/him)]

Bill has pointed out that the device in question has a 1024px wide screen. The current logic for that would yield a 1024px tile (because npow2(1024) / 2 = 1024), which is probably not ideal.

Comment 12

[Milan Sreckovic [:milan] (needinfo for best results)]

:snorp, I'm assuming you're interested in finding out why a 1024 tile size breaks things, rather than adjusting the heuristic to give us a 512 size instead?

Short term though, it seems like we would want at least two tiles in either direction, so is it worth adjusting the heuristic to give us at least two?  As in, npow2(size-1)/2 instead of npow2(size)/2?  Practically, given the standard sizes, this would only change the result for the 1024 width.

Jamie, do you have this device, or another one with 1024 screen?

Comment 13

[Milan Sreckovic [:milan] (needinfo for best results)]

Attachment: Adjust the sizing heuristic? r=snorp

The comment in the code says we should check if we're exceeding the maximum texture size.  Does this device have a maximum texture size that can't handle 1k x 1k?

Comment 14

[Jamie Nicol [:jnicol]]

Unfortunately I don't have any devices with that size of screen.

Comment 15

[James Willcox (:snorp) ([e-mail]) (he/him)]

I would think any device we currently run on would handle 2k x 2k at least. The device in question uses a PowerVR SGX540, which should definitely handle 1k...

Comment 17

[James Willcox (:snorp) ([e-mail]) (he/him)]

(In reply to Milan Sreckovic [:milan] from comment #13)
> Created attachment 8667957 [details] [diff] [review]
> Adjust the sizing heuristic? r=snorp
> 
> The comment in the code says we should check if we're exceeding the maximum
> texture size.  Does this device have a maximum texture size that can't
> handle 1k x 1k?

The reporter tried this patch, and it didn't seem to help. I believe he reported that 256x256 is the only size that worked. Is that correct, Bill?

Comment 18

[Bill Gianopoulos [:WG9s]]

(In reply to James Willcox (:snorp) ([e-mail]) from comment #17)
> (In reply to Milan Sreckovic [:milan] from comment #13)
> > Created attachment 8667957 [details] [diff] [review]
> > Adjust the sizing heuristic? r=snorp
> > 
> > The comment in the code says we should check if we're exceeding the maximum
> > texture size.  Does this device have a maximum texture size that can't
> > handle 1k x 1k?
> 
> The reporter tried this patch, and it didn't seem to help. I believe he
> reported that 256x256 is the only size that worked. Is that correct, Bill?

That is what I remember (or at least that is the largest size that worked, I did not try anything smaller).  I do not have the device with me today as I am in the office.  I will retest tonight just to be certain.

Comment 19

[Bill Gianopoulos [:WG9s]]

(In reply to James Willcox (:snorp) ([e-mail]) from comment #17)
> (In reply to Milan Sreckovic [:milan] from comment #13)
> > Created attachment 8667957 [details] [diff] [review]
> > Adjust the sizing heuristic? r=snorp
> > 
> > The comment in the code says we should check if we're exceeding the maximum
> > texture size.  Does this device have a maximum texture size that can't
> > handle 1k x 1k?
> 
> The reporter tried this patch, and it didn't seem to help. I believe he
> reported that 256x256 is the only size that worked. Is that correct, Bill?

I looked a NextPowerOfTwo and it already takes care of this.  I ran a test and NextPowerOfTwo(1024) returns 1024.  SO the -1 seems to be not needed.

Comment 20

[Milan Sreckovic [:milan] (needinfo for best results)]

Comment 11 and comment 19 claim different tile sizes on this device (comment 11 suggests 1024, comment 19 suggests 512.)  :snorp, is this a freely available device, can we just order one for Jamie?

Comment 21

[Bill Gianopoulos [:WG9s]]

(In reply to Milan Sreckovic [:milan] from comment #20)
> Comment 11 and comment 19 claim different tile sizes on this device (comment
> 11 suggests 1024, comment 19 suggests 512.)  :snorp, is this a freely
> available device, can we just order one for Jamie?

http://www.amazon.com/Samsung-Galaxy-7-Inch-Wi-Fi-Model/dp/B007P4VOWC

Comment 22

[Milan Sreckovic [:milan] (needinfo for best results)]

Thanks!  Jamie, can you order one of these?

Comment 23

[Jamie Nicol [:jnicol]]

Ordered.

Comment 24

[Milan Sreckovic [:milan] (needinfo for best results)]

:snorp, I will leave it to you to back out the patch that changed the tile size from 256x256 to 512x512 on this device, if you think there is urgency to it.  Otherwise we'll wait for the device to show up and look for a problem.

Comment 25

[Bill Gianopoulos [:WG9s]]

Attachment: workaround

I am using this hacky workaround to avoid the issue.

Comment 26

[Bill Gianopoulos [:WG9s]]

Perhaps this is the issue? http://mxr.mozilla.org/mozilla-central/source/widget/android/GfxInfo.cpp#549  This device seems to be blocklisted form some gfx features.

Comment 27

[Bill Gianopoulos [:WG9s]]

Perhaps this is the issue? http://mxr.mozilla.org/mozilla-central/source/widget/android/GfxInfo.cpp#549  This device seems to be blocklisted for some gfx features.

Comment 28

[Bill Gianopoulos [:WG9s]]

Perhaps we should just set layers.tiles.adjust to false for blocklisted devices.

Comment 29

[(inactive) Jim Chen [:jchen] [:darchons]]

This also happens on Galaxy Nexus (1280x720) running 4.2.2.

Comment 30

[Jamie Nicol [:jnicol]]

That is very interesting, I'd assumed it was due to a power-of-two screen size. I'll see if I can get my hands on a nexus 4 (1280x768) and reproduce on that.

Comment 31

[Bill Gianopoulos [:WG9s]]

But pease see if this device is also GFX blocklisted.

Comment 32

[(inactive) Jim Chen [:jchen] [:darchons]]

(In reply to Jamie Nicol [:jnicol] from comment #30)
> That is very interesting, I'd assumed it was due to a power-of-two screen
> size. I'll see if I can get my hands on a nexus 4 (1280x768) and reproduce
> on that.

My Nexus 4 does _not_ reproduce, but it's running 4.4.2.

Comment 33

[Bill Gianopoulos [:WG9s]]

Perhaps this is just a Jelly Bean issue.

Comment 34

[Kevin Brosnan [Ex-Mozilla]]

This is an issue on a Motorola XT910 running Android 4.0. GPU is a PowerVR SGX 540. Screen resolution is 540x960 and the density is 256 dpi.

Comment 35

[Bill Gianopoulos [:WG9s]]

OK so based on the above reports on devices running the same android version and different geometries, I am back to the patch which just set layers.tiles.adjust to false patch.

Comment 36

[Bill Gianopoulos [:WG9s]]

But also it seems on different devices that i have no idea if they are or are not blocklisted but they all seem to be running android 4.2.2 or earlier.  perhaps that should be the discriminator here.  Maybe need to be running Kit Kat (Android 4.4) or later to do this advanced tile stuff.

Comment 37

[(inactive) Jim Chen [:jchen] [:darchons]]

On my Galaxy Nexus, there are issues even with layers.tiles.adjust set to false. Some elements still render at larger-than-normal size; e.g. the toolbar at top of about:config [1] is extra wide but has correct height; the horizontal scrolling tiles on touch.facebook.com get larger (width and height) while scrolling but return to normal after scrolling finishes.

[1] http://mxr.mozilla.org/mozilla-central/source/mobile/android/chrome/content/config.xhtml?rev=0010c0cb259e#27

Comment 38

[Bill Gianopoulos [:WG9s]]

(In reply to Jim Chen [:jchen] [:darchons] from comment #37)
> On my Galaxy Nexus, there are issues even with layers.tiles.adjust set to
> false. Some elements still render at larger-than-normal size; e.g. the
> toolbar at top of about:config [1] is extra wide but has correct height; the
> horizontal scrolling tiles on touch.facebook.com get larger (width and
> height) while scrolling but return to normal after scrolling finishes.
> 
> [1]
> http://mxr.mozilla.org/mozilla-central/source/mobile/android/chrome/content/
> config.xhtml?rev=0010c0cb259e#27

Please refer to bug 1209828 and set layers.single-tile.enabled to false also and see if that helps these other issues.

Comment 39

[Bill Gianopoulos [:WG9s]]

OK.  So looking at OpenGL and Android version support if this is an Open GL ES version 3 or later feature then we should not be trying to use it in any android version before 4.3  If it is an Open GL version 2 supported feature then this device just does not support the feature correctly.

Comment 40

[James Willcox (:snorp) ([e-mail]) (he/him)]

Comment on attachment 8667957 [details] [diff] [review]
Adjust the sizing heuristic? r=snorp

Review of attachment 8667957 [details] [diff] [review]:
-----------------------------------------------------------------

According to the reporter, this doesn't help (and the function we're calling already handles this case)

Comment 41

[Milan Sreckovic [:milan] (needinfo for best results)]

(In reply to James Willcox (:snorp) ([e-mail]) from comment #40)
> 
> According to the reporter, this doesn't help (and the function we're calling
> already handles this case)

My bad, I forgot to remove the patch and the request after comment 19.

Comment 42

[Jamie Nicol [:jnicol]]

I can reproduce this on a Nexus S running android 4.1.2.

It's resolution is 480x800, so layers.tiles.adjust = true results in a tile size of 256, which works correctly. But setting layers.tiles.adjust=false and changing layers.tile-width/height causes this. < 256 renders correctly. > 256 stretches the content that should be within a 256-sized tile to the actual tile size

Comment 43

[Bill Gianopoulos [:WG9s]]

(In reply to Jamie Nicol [:jnicol] from comment #42)
> I can reproduce this on a Nexus S running android 4.1.2.
> 
> It's resolution is 480x800, so layers.tiles.adjust = true results in a tile
> size of 256, which works correctly. But setting layers.tiles.adjust=false
> and changing layers.tile-width/height causes this. < 256 renders correctly.
> > 256 stretches the content that should be within a 256-sized tile to the
> actual tile size

So this gets me back to if the android version API version is 18 or earlier clamp this at 256x256 and also disable layers.single-tile.enabled to fix the issue in bug 120928.

Comment 44

[Bill Gianopoulos [:WG9s]]

Just to make it clear.  I DO NOT want a separate build for earlier devices for this I want current trunk to run and check for this at runtime.  Users will never figure out the sperate build and which they should load and why we support more than one.

Comment 45

[Bill Gianopoulos [:WG9s]]

This should definitely work on any device that is compatible with Open GL 3 and that is a requirement for Android 4.3 (API version 19).  So checking to make sure the device is running 4.3 before trying to alter tile sizes or using this single-tile feature should work if we verify the device is running android 4.3.  I realize people jailbreak their device and load non -vendor supported android versions on their device, but we should not have to support those.

Comment 46

[Jamie Nicol [:jnicol]]

Are you sure this is because we're using a GLES 3 feature? and if so, which one?

Comment 47

[Bill Gianopoulos [:WG9s]]

(In reply to Jamie Nicol [:jnicol] from comment #46)
> Are you sure this is because we're using a GLES 3 feature? and if so, which
> one?

NO it is just that everyone complaining is running android 4.2 and earlier and android 4.3 is the first version purported to support GLES 3.  I wonder if anyone running a version before 4.3 does not see this issue.

so trying to find a way to make devices running 4.2 and earlier work as before while allowing 4.3 and later to get the newer optimization without breaking this for anyone.

Comment 48

[Bill Gianopoulos [:WG9s]]

Trying to avoid yet another huge blocklist of devices for which this does not work.  As far as I know we have zero reports of this not working under android 4.3 and zero reports of you can't make it fail under 4.2 by altering layers.tile-width/height.

Comment 51

[Bill Gianopoulos [:WG9s]]

So, the point is why was this change being made in the first place?  Do we care if it only works on 4.3 and later Andriod versions?

Comment 52

[Jamie Nicol [:jnicol]]

(In reply to Bill Gianopoulos [:WG9s] from comment #51)
> So, the point is why was this change being made in the first place?  Do we
> care if it only works on 4.3 and later Andriod versions?

It's an optimisation. Mainly for devices with larger screens - which is usually newer versions of android, but also tablets. If someone runs in to this bug by default then it's because we think larger tiles would be faster for them (whereas on the Nexus S I had to manually change the tile size to hit it.) It would be nice to find a fix that allows larger tile sizes on all versions of android.

Comment 53

[Bill Gianopoulos [:WG9s]]

(In reply to Jamie Nicol [:jnicol] from comment #52)
> (In reply to Bill Gianopoulos [:WG9s] from comment #51)
> > So, the point is why was this change being made in the first place?  Do we
> > care if it only works on 4.3 and later Andriod versions?
> 
> It's an optimisation. Mainly for devices with larger screens - which is
> usually newer versions of android, but also tablets. If someone runs in to
> this bug by default then it's because we think larger tiles would be faster
> for them (whereas on the Nexus S I had to manually change the tile size to
> hit it.) It would be nice to find a fix that allows larger tile sizes on all
> versions of android.

I realize that but the current fix seems to break this for so many people.  Fixing it for tablets on android 4.3 and later would seem to be better than fixing it for no one if it actually would also end up breaking things for no one.  It was really just a suggestion.

Comment 54

[Bill Gianopoulos [:WG9s]]

But I also realize you have a device to work on internally that is the one that I originally encountered the issue on, which might result in coming up with a way to do this on older devices with older Android version.  I just thought perhaps an interim fix to keep this from breaking others while investigating this might not be a bad idea.

Comment 55

[Jamie Nicol [:jnicol]]

Matt, Bas mentioned that this sounds like a bug you looked at before? Any ideas?

Comment 56

[Jamie Nicol [:jnicol]]

The GL trace has lots of glTexImage2D calls with width and height = 256. So even though CompositorOGL thinks that the tile textures are whatever size I set them to be, it doesn't look like they actually are.

Comment 57

[Bill Gianopoulos [:WG9s]]

(In reply to Jamie Nicol [:jnicol] from comment #56)
> The GL trace has lots of glTexImage2D calls with width and height = 256. So
> even though CompositorOGL thinks that the tile textures are whatever size I
> set them to be, it doesn't look like they actually are.

But it would still be nice to figure out if this is an issue with the device or an issue with the version of Android.  I still suspect he latter.

Comment 58

[Matt Woodrow (:mattwoodrow)]

(In reply to Jamie Nicol [:jnicol] from comment #55)
> Matt, Bas mentioned that this sounds like a bug you looked at before? Any
> ideas?

This sounds similar to what I was seeing, but I could only ever reproduce it on try, never locally.

Mine was when we switching to use the 'single tile' mode (so allowing tile sizes other than 256), but seeing similar results where it looked like a 256x256 texture was being stretched to the size that we expected the tile to be.

We need to try figure out where the 256 size is coming from, try tracing back from the glTexImage2D calls?

I think they'll be coming from TextureImageTextureSourceOGL::Update, which uses the size of the memory surface.

That suggests that the tile pool on the client side allocated the wrong size surface (TextureClientPool::GetTextureClient), maybe we have a race where we initialize the pool surface size before we set the custom tile size?

Comment 59

[Jamie Nicol [:jnicol]]

The 256 comes from TiledTextureImage::TiledTextureImage(). WantsSmallTiles() returns true, because CanUploadSubTextures() returns false, because the Nexus S has a PowerVR SGX540 which is slow at glTexSubImage2D(). (I think the logic in WantsSmallTiles() is actually wrong, because later in the function it says to always return true on a SGX540 due to texture upload races, and races should trump performance?) The Galaxy Tab 2 and the Moto Razr reported in bug 1211857 also have this GPU, so this is the deciding factor, not Android version.

Each tile (in the TiledLayerBuffer meaning) has a TextureImage, specifically a TiledTextureImage. When the tile size > 256, the TiledTextureImage creates multiple tiles (a different concept of tile), each one a GL texture of max 256x256 to fill that size. CompositorOGL has no knowledge that its TextureSources' TextureImages might be tiled so it only renders from a single 256x256 texture, stretching it out to the tile size.

I think that either CompositorOGL needs to be aware that the TextureSources it renders from might have multiple tiles, or we want to ensure that each Tile uses a non-tiled TextureImage?

Comment 60

[Bill Gianopoulos [:WG9s]]

(In reply to Jamie Nicol [:jnicol] from comment #59)
> The 256 comes from TiledTextureImage::TiledTextureImage(). WantsSmallTiles()
> returns true, because CanUploadSubTextures() returns false, because the
> Nexus S has a PowerVR SGX540 which is slow at glTexSubImage2D(). (I think
> the logic in WantsSmallTiles() is actually wrong, because later in the
> function it says to always return true on a SGX540 due to texture upload
> races, and races should trump performance?) The Galaxy Tab 2 and the Moto
> Razr reported in bug 1211857 also have this GPU, so this is the deciding
> factor, not Android version.
> 
> Each tile (in the TiledLayerBuffer meaning) has a TextureImage, specifically
> a TiledTextureImage. When the tile size > 256, the TiledTextureImage creates
> multiple tiles (a different concept of tile), each one a GL texture of max
> 256x256 to fill that size. CompositorOGL has no knowledge that its
> TextureSources' TextureImages might be tiled so it only renders from a
> single 256x256 texture, stretching it out to the tile size.
> 
> I think that either CompositorOGL needs to be aware that the TextureSources
> it renders from might have multiple tiles, or we want to ensure that each
> Tile uses a non-tiled TextureImage?

If I understand what you are saying correclty, then the correct fix here is to make sure that for devices where TiledTextureImage::TiledTextureImage(). WantsSmallTiles() returns true we need to both ensure that gfxPlatform::ComputeTileSize() does not return a size bigger than (or perhaps other than) 256x256, and that we also assume layers.single-tiled.enabled is false to avoid the issue in bug 1209828?

Comment 61

[Jamie Nicol [:jnicol]]

No, the correct fix I believe is to make CompositorOGL correctly handle this situation (where the TextureSource it is compositing is backed by a TiledTextureImage possibly with multiple textures).

This would fix both this and bug 1209828.

Comment 62

[Bill Gianopoulos [:WG9s]]

(In reply to Jamie Nicol [:jnicol] from comment #61)
> No, the correct fix I believe is to make CompositorOGL correctly handle this
> situation (where the TextureSource it is compositing is backed by a
> TiledTextureImage possibly with multiple textures).
> 
> This would fix both this and bug 1209828.

OK thanks for the info.

Comment 63

[Matt Woodrow (:mattwoodrow)]

I'm not sure we really want to support tiling-within-tiling.

TiledContentHost already makes the decision (#ifdef MOZ_GFX_OPTIMIZE_MOBILE) to upload entire textures instead of just the dirty region, so I don't think we gain anything by splitting our IPC tiles further.

I think we'd be better off ignoring the value of WantsSmallTiles(), making TiledContetHost::RenderTile assert that the TextureSource it has isn't itself tiled, and possibly take the WantsSmallTiles logic into account in ComputeTileSize.

Comment 64

[Bill Gianopoulos [:WG9s]]

Attachment: Fix logic in WantsSmallTiles()

As mentioned in bug1209801, the current logic in WantsSmallTiles() is non-sensical.  Fixing that to what was most-likely intended fixes the issue at last on the Galaxy Tab 2 7.0.

Comment 65

[Bill Gianopoulos [:WG9s]]

(In reply to Bill Gianopoulos [:WG9s] from comment #64)
> Created attachment 8671060 [details] [diff] [review]
> Fix logic in WantsSmallTiles()
> 
> As mentioned in bug1209801, the current logic in WantsSmallTiles() is
                  ^^^^^^^^^^
                  comment 59

Comment 66

[Bill Gianopoulos [:WG9s]]

(In reply to Bill Gianopoulos [:WG9s] from comment #64)
> Created attachment 8671060 [details] [diff] [review]
> Fix logic in WantsSmallTiles()

My nightly builds at http://www.wg9s.com/mozilla/firefox/ now include this patch.

Comment 67

[Jamie Nicol [:jnicol]]

Attachment: Part 1: Add TextureFlags parameter to TextureClientPool

I think this is necessary since not all Textures created by TextureClientPool will want to have DISALLOW_BIGIMAGE set?

Comment 68

[Jamie Nicol [:jnicol]]

Attachment: Part 2: Do not allow big image textures to be used with TiledLayerBuffers

This one will actually fix the bug (and bug 1211857)

Comment 69

[Jamie Nicol [:jnicol]]

^ I meant "and bug 1209828"

I think we should land Bill's patch in comment 64. It hides this issue rather than fixes it, but is correct to land for other reasons. I'm not sure if I have the authority to r+ it?

And as Matt suggests in comment 63 we might want to take the WantsSmallTiles' logic into account in ComputeTileSize. Snorp, since you recently rewrote ComputeTileSize do you have thoughts on that?

Comment 70

[Bill Gianopoulos [:WG9s]]

I have verified that these 2 patches fix the issue I originally reported.  I will probably file another bug about the WantsSmallTiles logic issue.  We should either move or remove the check for SGX 540 becuase it is non-functional where it is.

Comment 71

[Jamie Nicol [:jnicol]]

Requesting checkin for the "Part 1" and "Part 2" patches.
Here is a try run containing them: https://treeherder.mozilla.org/#/jobs?repo=try&revision=269da593aca5
The OS X failures are explained by intermittent failures, and the Android failures I can reproduce locally either with or without these patches, so are not due to these patches.

Bill, please do file another bug. And if we decide to change the logic for ComputeTileSize we can create a bug for that, so this can be closed once those patches land.

Comment 72

[Bill Gianopoulos [:WG9s]]

(In reply to Jamie Nicol [:jnicol] from comment #71)

> Bill, please do file another bug. And if we decide to change the logic for
> ComputeTileSize we can create a bug for that, so this can be closed once
> those patches land.

I filed bug 1213339 on that issue.

Comment 73

[Pulsebot]

https://hg.mozilla.org/integration/mozilla-inbound/rev/ae5f03f140a8
https://hg.mozilla.org/integration/mozilla-inbound/rev/9e69375c47ed

Comment 74

[Nigel Babu [:nigelb]]

Jamie, the Android R2 failures definitely seem to be part of your patches. I see them consistently on mozilla-inbound after these patches were landed. Going to back it out to see if I get a green.

Comment 75

[Pulsebot]

Backout:
https://hg.mozilla.org/integration/mozilla-inbound/rev/796d79ac842b
https://hg.mozilla.org/integration/mozilla-inbound/rev/2352801717ca

Comment 76

[James Willcox (:snorp) ([e-mail]) (he/him)]

I'm fine with adding a check in ComputeTileSizes() for this, but it looks like it may be somewhat tricky since it requires a GLContext to query the renderer and stuff. If we have a GLContext, we could also check the max texture size while we're there.

Comment 77

[Jamie Nicol [:jnicol]]

Attachment: Part 3: Adjust reftest fuzz and expected fails

The failing test already had some fuzzing around the borders between divs. This fix changes the shape of those divs (doesn't stretch them any more) so it makes sense that the amount of fuzzing required would change slightly. So slightly increase the fuzz threshold there.

And this also seems to fix a few tests (bug 959165). The pandaboards also have the SGX540 GPU so the original problem must also have been to do with that. I've unmarked these as expected fail.

Here is a green try run for android R2: https://treeherder.mozilla.org/#/jobs?repo=try&revision=e3ff63f621b6

Comment 78

[Jamie Nicol [:jnicol]]

Requesting checkin for the Part 1, 2, and 3 patches please. Try runs linked to from comment 71 and 77.

Comment 79

[Pulsebot]

https://hg.mozilla.org/integration/mozilla-inbound/rev/a1f80171a78e
https://hg.mozilla.org/integration/mozilla-inbound/rev/88d9d5909a0d
https://hg.mozilla.org/integration/mozilla-inbound/rev/a6b7ead9822d

Comment 80

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

https://hg.mozilla.org/mozilla-central/rev/a1f80171a78e
https://hg.mozilla.org/mozilla-central/rev/88d9d5909a0d
https://hg.mozilla.org/mozilla-central/rev/a6b7ead9822d

Comment 82

[Flaviu Cos]

Verified as fixed in build 44.0a1 2015-10-15;
Device: Motorola Razr (Android 4.4.4).