WebGL appears to be baked enough in Minefield that we can use it, and it's expected to be supported on all 3 platforms for ship. You can do a WebGL context with a transparent background, so you can make it fill the Panorama UI and then just animate the one tab that you're zooming into/out of, overlaying on top of the existing scene. For reference, you can use the code on: http://azarask.in/projects/webgl/ ... which appears to run nice and smooth even on netbooks. Note that you may have to do some configuration on your build to make it include WebGL; still looking into that. If the results are good enough and the coverage is wide enough, this may supersede bug 617454.

Looks like you don't need any special build config; it just isn't working on my Mac for some reason.

Limi's computer (new 11" Air) also seems to fail. My 13" air works just fine...

This is out of scope for Firefox 4, because: 1. WebGL is not stable enough. It's not even tested at all at this point, so I don't feel comfortable with making any part of our UI depend on it. 2. WebGL won't work on a considerable portion of devices, which means that we need to maintain a fallback code path as well, which means extra complexity. 3. Using WebGL for tab animations is not going to give us any hardware acceleration advantages that we can't already get with 2D canvas. 4. Rewriting any part of the panorama code is too risky at this point in the release cycle. I will let this bug live around for future though.

(In reply to comment #3) > This is out of scope for Firefox 4, because: > > 1. WebGL is not stable enough. It's not even tested at all at this point, To clarify, what Ehsan means here is that the WebGL test suite mochitest is currently disabled so there's not automatic testing for WebGL. This is one of my blockers. > 2. WebGL won't work on a considerable portion of devices, To clarify, it requires OpenGL 2 hardware, or D3D9 on windows. Which excludes 5-year-old NVIDIA/ATI, 3-year-old Intel hardware, and probably more recent VIA chips. So it can't be made mandatory for Panorama for the time being. It could at most be optional, i.e. a bonus. > which means that we > need to maintain a fallback code path as well, which means extra complexity. Right. > > 3. Using WebGL for tab animations is not going to give us any hardware > acceleration advantages that we can't already get with 2D canvas. To clarify, what Ehsan means here is that properly used 2D canvas should be able to let the openGL-accelerated layers take care of the image zooming completely, while transparently falling back to software rendering. So yes that sounds like the right approach. I believe that Joe and Jeff will be happy to help you get that working! (not so much an expert myself).

Going to over ride this given then kinds of speed and experience gains of using gl as an upgrade path for animation, this is on the table for firefox 4. While it won't work on all devices it will work on enough to make this truly useful. Ehsan, can you explain number 3? it certainly doesn't appear that that is the case.

> Ehsan, can you explain number 3? it certainly doesn't appear that that is the > case. We had a conversation (Ehsan, Joe, Jeff, me) about this and Joe and Jeff believed that canvas 2d should really let the OpenGL-accelerated layers accelerate the image zooming. I hope they can reply here :-)

Yes, I'd love to know what we're doing wrong in our current code to take advantage of the gpu.

(In reply to comment #5) > Going to over ride this given then kinds of speed and experience gains of using > gl as an upgrade path for animation, this is on the table for firefox 4. While > it won't work on all devices it will work on enough to make this truly useful. > > Ehsan, can you explain number 3? it certainly doesn't appear that that is the > case. Of course. According to the graphics guys, we currently put each canvas element on its own layer, so operations like resizing it will happen during composition, and are accelerated by the GPU. The hardware acceleration provided by WebGL in addition to that only kicks in if you actually draw stuff inside the canvas using the WebGL API. Since the only thing that we'd want to do if we switch to WebGL canvases is to draw a tab image inside the canvas, we will not get the additional acceleration benefits from switching to WebGL. Therefore I do not think that this is worth investing time in the Firefox 4 timeframe. For Firefox next, we may want to draw the entire Panorama UI (not only the tab thumbnails) in WebGL. Once we have that, the entire drawing will be accelerated, but this is a large project in scope, and too risky for us to consider taking up right now.

It's too late for this for Fx4

bugspam: returning Sean's bugs to the pool

We're not going to address this with Panorama being slated for removal.