I've got a WebGL program that works on b2g desktop and on nexus s, but does not display anything on otoro. No error messages in console. If I launch the app I see a blank screen. Then if I hold the Home key down to bring up the task switcher, I see my webgl graphics in the mini view of the app in the switcher. So the graphics are being rendered somewhere, just not shown on the screen. This may be related to: https://bugzilla.mozilla.org/show_bug.cgi?id=780926 And possibly related to: https://bugzilla.mozilla.org/show_bug.cgi?id=780920 The test case is at http://djf.net/gl.html It is a really simple WebGL program that just draws a green rectangle. My otoro does not have a working network connection, so I can't test that link on my device, and I don't know if you can reproduce the bug by just visiting that link. To reproduce, I had to do something like this: cp -a gaia/test_apps/template gaia/test_apps/webgltest cp gl.html gaia/test_apps/webgltest/index.html make install-gaia gl.html is the file linked above, and attached to this bug. This should get you a gaia homescreen with the Template apps. The second one is the test app. If it works, you'll see a green rectangle. If it doesn't work, you should just see the word "green" with no rectangle. But when you hold down the home button you should see the rectangle in the reduced-size window.
Nominating blocking-basecamp because this bug completely breaks the editing functionality of the Gallery app.
blocking-basecamp: --- → ?
Summary: [otoro] WebGL not working on otoro phone → [otoro] Simple WebGL app not rendering on otoro phone
This is among the simplest of all possible webgl programs. We need to at least understand why it's broken.
blocking-basecamp: ? → +
I've been told on irc that if you use the browser app to load http://djf.net/gl.html you'll see a blank screen with no green rectangle. If you test it that way, though, you won't see the green rectangle when you bring up the task switcher. To see that bit of craziness, you've got to install it as an app.
You keep referring to a green rectangle, but do you mean a green square? (That is, the entire canvas is green?)
Er. Ignore that, somehow I had triangle stuck in my head. Ahem!
I plan to look into this, but can't before Thursday: I will be off tomorrow and, wifi is broken in the B2G revision I'm currently using.
nhirata reports that he does not see this bug on otoro-ics with "version 7 of the firmware". At least not as it manifests in the Gallery app. I still see it (in Gallery) on otoro-gb with today's build.
Please ignore that last comment. nhirata was using an old version of gaia and not the latest webgl-based version of Gallery.
This is a compositing issue: the page thumbnail is rendered properly in the tab pane. This shows that the WebGL rendering is correctly working, only the compositing is broken.
Also, this isn't specific to this page: WebGL compositing is just completely broken in the B2G browser app at the moment (while it works in standalone apps, like CrystalSkull). Hopefully someone versed in how compositing differs between these two cases, could comment. Given how regression-prone WebGL compositing is, it's almost futile to try to fix it before we have turned on WebGL mochitests on B2G. Indeed, we may fix it today, but without regression tests this will regress again soon.
Summary: [otoro] Simple WebGL app not rendering on otoro phone → [otoro] WebGL compositing broken in browser app on Otoro phone
There's no difference in compositing between browser and other apps. I would bet folding money we're using some cross-thread code added for fennec-native that doesn't work across processes. Can test by flipping this off https://github.com/mozilla-b2g/gaia/blob/master/apps/browser/js/browser.js#L376 As to what's going wrong here, I have no idea.
bjacob: note that the attached test case is an app, and it fails when installed as an app. So this is not just webgl broken in the browser. You might want to re-edit the title. And note that these two bugs seem like compositing issues also: https://bugzilla.mozilla.org/show_bug.cgi?id=780920 https://bugzilla.mozilla.org/show_bug.cgi?id=782411
(In reply to Chris Jones [:cjones] [:warhammer] from comment #11) > I would bet folding money we're using some cross-thread code added for > fennec-native that doesn't work across processes. Can test by flipping this > off > > https://github.com/mozilla-b2g/gaia/blob/master/apps/browser/js/browser. > js#L376 This didn't make a difference.
(In reply to David Flanagan [:djf] from comment #12) > bjacob: note that the attached test case is an app, and it fails when > installed as an app. So this is not just webgl broken in the browser. You > might want to re-edit the title. Ah. OK, sorry for the noise then.
Summary: [otoro] WebGL compositing broken in browser app on Otoro phone → [otoro] Simple WebGL app not rendering on otoro phone
In the WebGL demo repository: http://www.khronos.org/webgl/wiki/Demo_Repository WORK: san-angeles particles shiny-teapot VBO example FLICKER: image-texture-test procedural-texture-test FAIL: colored box textured box
Alright, there are at least two issues here. Issue #1. WebGL contexts don't get composited at all unless the canvas width is a multiple of 160. Issue #2. WebGL compositing flickers, intermittently disappears, can then be brought back by panning. When the whole page is < screen size so that one can't pan in default zoom, it often happens that WebGL canvases disappear permanently. Going to file bugs.
Who wrote the current implementation of WebGL canvas compositing on B2G?
(In reply to Benoit Jacob [:bjacob] from comment #18) > Who wrote the current implementation of WebGL canvas compositing on B2G? Jonas guesses Chris Jones. Benoit, can you take this one, too? It might be a dupe of bug 780926.
Assignee: nobody → bjacob
Dup of bug 782785?
As said in comment 16 there are two issues here: bug 782785 (which was preventing any rendering at all) and bug 782786 (which causes severe flickering). The former is fixed now; I'm looking into the latter.
this morning, on a build with bjacob's latest patch, http://djf.net/gl.html displays a green rectangle, but it then disappears right away. And when the gallery app enters editing mode, it displays the photo being edited (this is new; that didn't use to happen) and then it disappers again until you actually start editing the photo. Since the test app and editing app just draw themselves once and then sit there, perhaps this is the flickering issue.
(In reply to David Flanagan [:djf] from comment #23) > this morning, on a build with bjacob's latest patch Just FWIW, the patch in bug 782785 is by Jeff Gilbert. >, http://djf.net/gl.html > displays a green rectangle, but it then disappears right away. I confirm this here. This seems to be exactly bug 782786. > > And when the gallery app enters editing mode, it displays the photo being > edited (this is new; that didn't use to happen) and then it disappers again > until you actually start editing the photo. > > Since the test app and editing app just draw themselves once and then sit > there, perhaps this is the flickering issue. Yep.
(In reply to Benoit Jacob [:bjacob] from comment #24) > (In reply to David Flanagan [:djf] from comment #23) > > this morning, on a build with bjacob's latest patch > > Just FWIW, the patch in bug 782785 is by Jeff Gilbert. > > >, http://djf.net/gl.html > > displays a green rectangle, but it then disappears right away. > > I confirm this here. This seems to be exactly bug 782786. bug 782786 now has a patch; it does fix the disappearing on http://djf.net/gl.html.
The gallery editing mode also seems to work correctly with the patch from bug 782786.
Tested on today's source, works well here, so this is fixed by bug 782785 + bug 782786.
Status: NEW → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.