Rendering stretched when scrolling on PowerVR SGX with APZC

RESOLVED FIXED in mozilla30

Status

()

Core
Panning and Zooming
RESOLVED FIXED
4 years ago
4 years ago

People

(Reporter: gerard, Assigned: cwiiis)

Tracking

(Blocks: 1 bug)

29 Branch
mozilla30
ARM
Gonk (Firefox OS)
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [more STR in duped bug])

Attachments

(2 attachments)

(Reporter)

Description

4 years ago
Created attachment 8363721 [details]
Stretching on scrolling on Nexus S in Browser app

When scrolling with APZC enabled (browser or app), there is some bad stretching appearing, like if the page has been rendered at a lower height and displayed at the device height.

I remember hitting this issue a long time ago on B2G18HD branch, with Nexus S. I just reproduced it with Flatfish on Master this morning, and since I got the flatfish.

STR:
1. Launch Marketplace
2. Tap on 'display all' for either featured apps or recent apps
3. Scroll the list

Expected:
Nice scrolling, no stretching

Actual:
Stretching when scrolling

Attached is an old screenshot of the issue in browser on Nexus S.
(Reporter)

Updated

4 years ago
Summary: Rendering strectched when scrolling on PowerVR SGX with APZC → Rendering stretched when scrolling on PowerVR SGX with APZC
OS: Linux → Gonk (Firefox OS)
Hardware: x86_64 → ARM
(Reporter)

Comment 1

4 years ago
FYI, Nexus S with master currently has gralloc disabled (due to bug 950050), and using shmem it does not expose the issue.
BenWa, you have a flatfish, right? Can you repro this?
It might be similar to Bug 850566.
Duplicate of this bug: 964207
Whiteboard: [more STR in duped bug]
(Reporter)

Updated

4 years ago
Blocks: 901322
I can take a look.
Flags: needinfo?(bgirard)

Comment 6

4 years ago
I'm seeing this on Nexus 4 with current master.
(Assignee)

Comment 7

4 years ago
I'm seeing this on a Galaxy Nexus with current master. Is this PVR+gralloc-specific?
(Assignee)

Comment 8

4 years ago
Theory: Going on https://bug850566.bugzilla.mozilla.org/attachment.cgi?id=730262, it seems that it's possible for the allocated gralloc texture size to differ from the requested size - in which case, the tile drawing code may end up drawing stretched tiles if a buffer ended up larger than what was requested.
(Assignee)

Comment 9

4 years ago
The situation where I can easily reproduce this (the pull-to-refresh on Mobile Twitter after scrolling) is allocating a gralloc surface that's greater than the maximum texture size. This is likely accounting for the stretching (I've seen this outside of this situation too, but I've not easily been able to reproduce that... It might cause some possibly-persistent weirdness when you trigger this).

I guess in these situations, tiled textures should be used. I thought we already did this... Perhaps PVR is misreporting its max texture size?
(Assignee)

Comment 10

4 years ago
So, it seems that the maximum texture size just isn't checked at all in the path that I see triggers this. Hacking CompositorOGL to return the number I know is the maximum texture size and checking the requested size in GrallocTextureClientOGL::AllocateGralloc shows it getting exceeded in the situations we end up with stretching.

I'll start debugging from this point.
(Assignee)

Comment 11

4 years ago
Here's the relevant part of the backtrace:

#0  mozilla::layers::GrallocTextureClientOGL::AllocateGralloc (this=0x42fea640, aSize=..., 
    aAndroidFormat=5, aUsage=307)
    at /home/cwiiis/Projects/mozilla-central/gfx/layers/opengl/GrallocTextureClient.cpp:400
#1  0x40a563f4 in mozilla::layers::GrallocTextureClientOGL::AllocateForSurface (this=0x439d8d60, 
    aSize=...) at /home/cwiiis/Projects/mozilla-central/gfx/layers/opengl/GrallocTextureClient.cpp:348
#2  0x40a32cd4 in mozilla::layers::ContentClientRemoteBuffer::CreateAndAllocateTextureClient (
    this=0x44040570, aClient=..., aFlags=16384)
    at /home/cwiiis/Projects/mozilla-central/gfx/layers/client/ContentClient.cpp:177
#3  0x40a331b4 in mozilla::layers::ContentClientRemoteBuffer::BuildTextureClients (this=0x44040570, 
    aFormat=..., aRect=..., aFlags=0)
    at /home/cwiiis/Projects/mozilla-central/gfx/layers/client/ContentClient.cpp:216
#4  0x40a3323a in mozilla::layers::ContentClientRemoteBuffer::CreateBuffer (this=0x44040570, aType=..., 
    aRect=..., aFlags=0, aBlackDT=0xbee0641c, aWhiteDT=0xbee06418)
    at /home/cwiiis/Projects/mozilla-central/gfx/layers/client/ContentClient.cpp:241
#5  0x40a291c2 in mozilla::layers::RotatedContentBuffer::BeginPaint (this=0x44040584, 
    aLayer=<value optimized out>, aFlags=1)
    at /home/cwiiis/Projects/mozilla-central/gfx/layers/RotatedBuffer.cpp:627
#6  0x40a31d62 in mozilla::layers::ContentClientBasic::BeginPaintBuffer (this=<value optimized out>, 
    aLayer=0xbee063dc, aFlags=3584) at ../../dist/include/mozilla/layers/ContentClient.h:329
#7  0x40a30ab8 in mozilla::layers::ClientThebesLayer::PaintThebes (this=0x42e36d70)
    at /home/cwiiis/Projects/mozilla-central/gfx/layers/client/ClientThebesLayer.cpp:55
#8  0x40a30be6 in mozilla::layers::ClientThebesLayer::RenderLayer (this=0x42e36d70)
    at /home/cwiiis/Projects/mozilla-central/gfx/layers/client/ClientThebesLayer.cpp:103
#9  0x40a2f88a in mozilla::layers::ClientContainerLayer::RenderLayer (this=<value optimized out>)
    at /home/cwiiis/Projects/mozilla-central/gfx/layers/client/ClientContainerLayer.h:83
#10 0x40a303bc in mozilla::layers::ClientLayerManager::EndTransactionInternal (this=0x43989520, 
    aCallback=0x4107e53d <mozilla::FrameLayerBuilder::DrawThebesLayer(mozilla::layers::ThebesLayer*, gfxContext*, nsIntRegion const&, mozilla::layers::DrawRegionClip, nsIntRegion const&, void*)>, 
    aCallbackData=0xbee06764)
    at /home/cwiiis/Projects/mozilla-central/gfx/layers/client/ClientLayerManager.cpp:199

Frame 0, aSize is greater than the max texture size in the y-direction.

So we have a RotatedBuffer that's bigger than the max texture size and it ends up stretched, I suppose because the texture coordinates get truncated or some other such reason.

Is it a layout or a gfx issue that we end up making layers we can't draw? I guess gfx in that the TextureHost should handle this perhaps? n?nical for comment.
Flags: needinfo?(nical.bugzilla)
We should fallback to shmem when the texture exceeds the maximum supported size. BufferTextureHost supports "BigImages" which breaks the shmem's content into smaller textures. We can't easily make the non-tiled ContentClient render to separate smaller textures, and now we have TiledContentClient on b2g which doesn't have the max texture size problem so let's just use the bullet-proof shmem path in those edge cases.
Flags: needinfo?(nical.bugzilla)
(Assignee)

Comment 13

4 years ago
Created attachment 8389339 [details] [diff] [review]
Respect max texture size when creating Gralloc texture clients

This fixes the issue, but this doesn't fix the larger issue that layout is letting this happen (scrollable layers with a displayport somehow not getting a tiled thebes layer).

I'll be investigating the layout issue separately, it'd still be good to get this in as there are probably more legitimate situations where we end up with large layers.
Attachment #8389339 - Flags: review?(nical.bugzilla)
(Assignee)

Comment 14

4 years ago
Taking.
Assignee: nobody → chrislord.net
Status: NEW → ASSIGNED
Flags: needinfo?(bgirard)

Updated

4 years ago
Attachment #8389339 - Flags: review?(nical.bugzilla) → review+
https://hg.mozilla.org/mozilla-central/rev/8b449c3a4caa
Status: ASSIGNED → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla30

Updated

4 years ago
Depends on: 984460
You need to log in before you can comment on or make changes to this bug.