Closed Bug 962629 Opened 6 years ago Closed 6 years ago
Rendering stretched when scrolling on Power
VR SGX with APZC
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.
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
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.
I can take a look.
I'm seeing this on Nexus 4 with current master.
I'm seeing this on a Galaxy Nexus with current master. Is this PVR+gralloc-specific?
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.
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?
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.
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.
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.
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: nobody → chrislord.net
Status: NEW → ASSIGNED
Attachment #8389339 - Flags: review?(nical.bugzilla) → review+
Pushed to inbound: https://hg.mozilla.org/integration/mozilla-inbound/rev/8b449c3a4caa
Status: ASSIGNED → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla30
You need to log in before you can comment on or make changes to this bug.