Some pages entirely black on Fennec when GL Layers enabled

RESOLVED FIXED in mozilla8

Status

()

Core
Graphics
RESOLVED FIXED
6 years ago
6 years ago

People

(Reporter: ajuma, Assigned: ajuma)

Tracking

({regression})

Trunk
mozilla8
ARM
Android
regression
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [inbound])

Attachments

(1 attachment, 1 obsolete attachment)

(Assignee)

Description

6 years ago
This is occurring sporadically with several sites, but is most consistently reproducible at https://addons.mozilla.org/en-US/mobile/

The page appears entirely black, with no content displayed. 

In some cases (e.g. at m.cnn.com), the content briefly flashes on the screen before disappearing, and reappears if the page is scrolled to the bottom.

This seems to be a very recent regression, and indeed the issue does not occur when the patches from bug 660090 are backed out.
Unless Joe has an idea what's causing this I suggest we back them out until we can fix them up.

Updated

6 years ago
Blocks: 607684
(Assignee)

Comment 2

6 years ago
The problem turns out to be that in certain cases, the wrong internal format is used in fTexImage2D. This should be easy to fix -- patch coming soon.
Is it bug 661002 by any chance?
(Assignee)

Comment 4

6 years ago
(In reply to comment #3)
> Is it bug 661002 by any chance?

It certainly seems related. What's happening is that with bug 660090, the constructor of TextureImageEGL makes a call to Resize(), that in turn calls fTexImage2D. The latter call is made under the assumption that the surface's format is mUpdateFormat. When this guess turns out to be wrong, we're in trouble.

Specifically, we're running into a situation where mUpdateFormat is ARGB_32, but the surface passed to TextureImageEGL::DirectUpdate() is RGB16_565. At this point the texture has already been allocated with internal format LOCAL_GL_RGBA, but it should really be LOCAL_GL_RGB.
(Assignee)

Comment 5

6 years ago
Created attachment 549532 [details] [diff] [review]
Recover from incorrect guess of surface format

Before calling UploadSurfaceToTexture, we check if our guess of the surface format turned out to be incorrect; if so, we ask UploadSurfaceToTexture to reallocate the texture (using the correct format).
(Assignee)

Updated

6 years ago
Attachment #549532 - Attachment is patch: true
Attachment #549532 - Attachment mime type: text/x-patch → text/plain
This seems like it will happen fairly often on mobile, and probably isn't great for performance.

Can we either improve our guessing logic, or defer the initial texture creation until we know the surface type?
(Assignee)

Comment 7

6 years ago
Created attachment 550389 [details] [diff] [review]
Defer allocation of textures

This postpones the allocation of textures until the texture is about to be used. 

This is essentially a middle-ground between what was happening before bug 660090 landed (we were allocating textures too late, and hence running into incomplete framebuffer errors), and what is happening currently (we are allocating textures early and hence sometimes we don't choose the right internal format).
Attachment #549532 - Attachment is obsolete: true
Attachment #550389 - Flags: review?(matt.woodrow)
Comment on attachment 550389 [details] [diff] [review]
Defer allocation of textures

I'd r+ this twice if I could. :)
Attachment #550389 - Flags: review?(matt.woodrow) → review+
Nice! Lets get this landed :)
http://hg.mozilla.org/integration/mozilla-inbound/rev/c048ca40dcd1
Whiteboard: [inbound]
http://hg.mozilla.org/mozilla-central/rev/c048ca40dcd1
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla8
You need to log in before you can comment on or make changes to this bug.