Closed Bug 675210 Opened 9 years ago Closed 9 years ago

Some pages entirely black on Fennec when GL Layers enabled

Categories

(Core :: Graphics, defect)

ARM
Android
defect
Not set

Tracking

()

RESOLVED FIXED
mozilla8

People

(Reporter: ajuma, Assigned: ajuma)

References

Details

(Keywords: regression, Whiteboard: [inbound])

Attachments

(1 file, 1 obsolete file)

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.
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?
(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.
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).
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?
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/mozilla-central/rev/c048ca40dcd1
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla8
You need to log in before you can comment on or make changes to this bug.