Closed Bug 1209801 Opened 4 years ago Closed 4 years ago

Content is scaled twice physical resolution

Categories

(Core :: Graphics: Layers, defect, major)

ARM
Android
defect
Not set
major

Tracking

()

VERIFIED FIXED
mozilla44
Tracking Status
firefox43 --- unaffected
firefox44 + verified
fennec 44+ ---

People

(Reporter: wgianopoulos, Assigned: jnicol)

References

Details

(Keywords: regression)

Attachments

(7 files, 3 obsolete files)

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.
Attachment #8667623 - Attachment description: nexus about: page → screenshot nexus about: page
Flags: needinfo?(snorp)
Setting setting layers.tiles.adjust = false appears to avoid the issue.
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.
Keywords: regression
I added the regression keyword, as this worked correctly using the 9/28 nightly build and files with the 9/29 builds.
Oh I should mention, Android 4.2.2 is the latest vendor supported Android version on this device.
Component: General → Graphics: Layers
Product: Firefox for Android → Core
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 :)
Flags: needinfo?(milan)
Blocks: 1182665
hg bisect said:

The first bad revision is:
changeset:   264757:9fea88097171
user:        James Willcox <snorp@snorp.net>
date:        Wed Aug 26 17:33:16 2015 -0500
summary:     Bug 1182665 - Adjust tile sizes depending on the screen size r=nical
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.
: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?
Flags: needinfo?(snorp)
Flags: needinfo?(milan)
Flags: needinfo?(jnicol)
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?
Attachment #8667957 - Flags: review?(snorp)
Unfortunately I don't have any devices with that size of screen.
Flags: needinfo?(jnicol)
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...
Flags: needinfo?(snorp)
tracking-fennec: --- → ?
Duplicate of this bug: 1209828
(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?
Flags: needinfo?(wgianopoulos)
(In reply to James Willcox (:snorp) (jwillcox@mozilla.com) 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.
Flags: needinfo?(wgianopoulos)
(In reply to James Willcox (:snorp) (jwillcox@mozilla.com) 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 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?
Flags: needinfo?(snorp)
(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
Thanks!  Jamie, can you order one of these?
Flags: needinfo?(snorp) → needinfo?(jnicol)
Ordered.
Flags: needinfo?(jnicol)
tracking-fennec: ? → 44+
Assignee: nobody → jnicol
: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.
Attached patch workaround (obsolete) — Splinter Review
I am using this hacky workaround to avoid the issue.
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.
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.
Perhaps we should just set layers.tiles.adjust to false for blocklisted devices.
This also happens on Galaxy Nexus (1280x720) running 4.2.2.
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.
But pease see if this device is also GFX blocklisted.
(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.
Perhaps this is just a Jelly Bean issue.
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.
Summary: Content window does not display correctly on Samsung Galaxy Tab 2 7.0 running Android 4.2.2 → Content is scaled twice physical resolution
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.
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.
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
(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.
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 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)
Attachment #8667957 - Flags: review?(snorp) → review-
(In reply to James Willcox (:snorp) (jwillcox@mozilla.com) 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.
Attachment #8668732 - Attachment is obsolete: true
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
(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.
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.
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.
Are you sure this is because we're using a GLES 3 feature? and if so, which one?
(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.
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.
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?
(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.
(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.
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.
Matt, Bas mentioned that this sounds like a bug you looked at before? Any ideas?
Flags: needinfo?(matt.woodrow)
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.
(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.
(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?
Flags: needinfo?(matt.woodrow)
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?
(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?
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.
(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.
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.
Attached patch Fix logic in WantsSmallTiles() (obsolete) — Splinter Review
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.
(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
(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.
I think this is necessary since not all Textures created by TextureClientPool will want to have DISALLOW_BIGIMAGE set?
Attachment #8671471 - Flags: review?(matt.woodrow)
This one will actually fix the bug (and bug 1211857)
Attachment #8671472 - Flags: review?(matt.woodrow)
^ 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?
Flags: needinfo?(snorp)
Attachment #8671471 - Flags: review?(matt.woodrow) → review+
Attachment #8671472 - Flags: review?(matt.woodrow) → review+
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.
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.
Keywords: checkin-needed
Attachment #8671060 - Attachment is obsolete: true
(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.
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.
Flags: needinfo?(jnicol)
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.
Flags: needinfo?(snorp)
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
Flags: needinfo?(jnicol)
Attachment #8673204 - Flags: review?(matt.woodrow)
Attachment #8673204 - Flags: review?(matt.woodrow) → review+
Requesting checkin for the Part 1, 2, and 3 patches please. Try runs linked to from comment 71 and 77.
Keywords: checkin-needed
Duplicate of this bug: 1209828
Verified as fixed in build 44.0a1 2015-10-15;
Device: Motorola Razr (Android 4.4.4).
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.