(only tested on Android) Last good nightly: 2010-10-15 First bad nightly: 2010-10-16 push log: http://hg.mozilla.org/mozilla-central/pushloghtml?startdate=2010-10-15&enddate=2010-10-16 WebGL can be tested here: http://learningwebgl.com/lessons/lesson14/index.html
Probably a dup of bug 606098?
Here's the error i get from that page. WebGL: We are currently drawing stuff, but some 2D texture has not yet been uploaded any image at level 0. Until it's uploaded, this texture will look black. http://learningwebgl.com/lessons/lesson14/index.html 397
In my case: "Warning: WebGL: WebGL: Can't get a usable WebGL context"
(In reply to comment #2) > Probably a dup of bug 606098? So no, this isn't the same issue, since the present bug is failing to get a WebGL context whereas 606098 is a crash. (In reply to comment #3) > Here's the error i get from that page. > > WebGL: We are currently drawing stuff, but some 2D texture has not yet been > uploaded any image at level 0. Until it's uploaded, this texture will look > black. > http://learningwebgl.com/lessons/lesson14/index.html > 397 I wouldn't worry about this unless you actually see unwanted black stuff. This message just means what it says i.e. that it's starting to draw (drawArrays...) stuff before having finished uploading (texImage2D...) all its textures, which is rather usual.
(In reply to comment #5) > (In reply to comment #2) > > I wouldn't worry about this unless you actually see unwanted black stuff. This > message just means what it says i.e. that it's starting to draw (drawArrays...) > stuff before having finished uploading (texImage2D...) all its textures, which > is rather usual. This obviously isn't the error Paul was reporting, but we never (never == I waited 3 or 4 minutes) render anything but black in this case.
(In reply to comment #6) > This obviously isn't the error Paul was reporting, but we never (never == I > waited 3 or 4 minutes) render anything but black in this case. Interesting! This needs to be filed as a separate bug. I just realized that we are printing this message even if webgl.verbose=false, which explains why you see only this message. Can you please set webgl.verbose=true and retry. Hopefully you'll get more messages.
Component: General → Canvas: WebGL
Product: Fennec → Core
QA Contact: general → canvas.webgl
What is really weird is that none of the WebGL initialization code changed in the regression range given in comment 0. The code is is WebGLContext.cpp, and InitAndValidateGL() in WebGLContextValidate.cpp WebGLContext.cpp was not touched. InitAndValidateGL is touched only in 906f66ccd8cc but the diff is just: + gl->fGetIntegerv(LOCAL_GL_PACK_ALIGNMENT, (GLint*) &mPixelStorePackAlignment); + gl->fGetIntegerv(LOCAL_GL_UNPACK_ALIGNMENT, (GLint*) &mPixelStoreUnpackAlignment); I don't see how this can cause a failure.
tracking-fennec: --- → ?
Assignee: nobody → bjacob
tracking-fennec: ? → 2.0b3+
I have a suspiscion that this could have been a dupe of bug 604395 which is now fixed. Can you retry now?
Doesn't work with my Nexus One. Works with the Samsung Galaxy S.
Does anyone have a debug build and is able to step through WebGLContext::SetDimensions() in WebGLContext.cpp and WebGLContext::InitAndValidateGL() in WebGLContextValidate.cpp ?
fwiw, WebGL in Fennec is on the back burner until it's stable on the desktop; it's unlikely to make Fennec 2.0.0 (Firefox 4).
tracking-fennec: 2.0b3+ → ---
hmm I have EGL working for layers, also remote layers, and webgl is mostly working with readpixels path (plannin to change that to blitTextures) and I have example 1-5 working fine, but not earth and tear-spot. sounds like some wrong handling GLES in common webGL code
That's possible indeed: there are a few places in the WebGL code where we do things differently for GLES, and the GLES path has presumably received little testing.
Closing this, since WebGL has been working on Fennec for a while now.
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.