Closed Bug 597458 Opened 12 years ago Closed 12 years ago
Investigate different drawing techniques for Tab
Candy/Panorama zoom transition
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b7pre) Gecko/20100917 Firefox/4.0b7pre Build Identifier: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b7pre) Gecko/20100917 Firefox/4.0b7pre Currently, TabCandy's zoom in/out transitions are very slow. I'm not familiar what's happening inside TabCandy right now (hopefully someone will take the time to describe it in this bug), but there are ways to make it faster. Please do NOT dupe this bug against Bug #564978 , which is a Core bug about optimizing the functions used by TabCandy, not optimizing TabCandy itself! For example, using a canvas with image-rendering:-moz-crisp-edges and 1/4 the dimensions of the real screen (scaled back up via CSS) gives acceptable performance even on my tiny Netbook in "Max Battery" mode (of course at the cost of visual quality). I'll attach a quick demo in a second. But the 50%-then-sharp-drop behaviour is probably due to something else... is the real page shown too soon? Reproducible: Always Steps to Reproduce: 1. Open TabCandy on a slow PC (no gfx acceleration) 2. Click any thumbnail to zoom in Actual Results: The animation works at a slow, but acceptable speed up to about 50%, then it stutters terribly Expected Results: Animation should work smoothly
Hans, thanks for taking a lead on this. P3 for investigation.
Priority: -- → P3
No problem. For anybody like me, who isn't familiar with TabCandy's structure: just have a look inside omni.jar/chrome/browser/content/browser/tabview.js and look for "// Function: zoomIn". Right now it seems to use jQuery, which looks like a bad idea, seeing as it's probably still timeout based. I'm off to bed now, but I'll look into replacing it with paint event based behavior tomorrow.
Urgh. Just had a last quick look at the JS file. It's not jQuery, but I can see trouble lurking in the animate function which does a timeout to determine the end of the animation. Seems dangerous, since the transition might start a little late.
Attached is the same thing again, but this time as a ready to run replacement to tabview.js/TabItem::zoomIn. On the big screen it's not exactly beautiful (so we should probably control the resolution dynamically based on available acceleration or the speed of the first few runs) and it only scales the thumbnails, not the decoration (I'd just draw the decoration with Canvas instead of doing them via CSS). Also, the animation is currently linear. Anyway, it really works quite well on my little Netbook. Opinions?
Some other things that may be used to increase smoothness: 1. Motionblur (not much work, add globalAlpha proportional to time since last draw) 2. Decrease contrast to hide details of animation (also hides the ugly downscaling employed by drawWindow).
DOH! I'm guilty of the same mistake as the original code: do NOT skip drawing the last frame by calling the "go to tab" code without a timeout after the last frame has been drawn. That code is SYNCHRONOUS, meaning that your last drawn frame will never actually be shown. Instead, it will hang until the real tab content has been rendered.
Hans, awesome that you're looking into this! One thing to note: our zoom in animation only goes to half-screen by design; on machines with decent animation speed, the time between the last drawn animation frame (half-screen size) and the actual tab at full-screen gives the impression of the animation completing perfectly. Animating all the way to full size and then switching to the real tab would be slower, and would actually create more visual discontinuity (as the thumbnail doesn't perfectly match the real tab). Of course, as you've seen, on slower machines, it just hangs out at that half size and looks broken. I wonder to what extent this is just how long it takes to go from the Panorama screen to the actual tab?
The new patch, which is mixed up with the stuff from Bug #597713 (which aside from the new patch also has a video) can be found there. I've changed it so that the position of the scaled thumbnail actually matches the one of the content, so we should be good there. Speed-wise I'd say that a continuous animation is maybe slower, but more consistent among all supported machines. At least on my little Netbook it looks a whole lot better. Of course, we could use different profiles for machines with different speed, but I'm more for a clean, one-fits-all solution. The blocky pixels may not look perfect, but I think we can either sell them as an "artistic" decision or adjust the resolution based on current speed.
Just discussed the different rendering methods we want for the transition with aza and iangilman. Basically, the Canvas implementation will take over all rendering, but in three (very similar) modes: Full-resolution, downsized and boundingbox. We'll switch between those depending on speed. Full-resolution and downsized are pretty much identical and bounding box is really only a minor variant, so hopefully I'll get an early version working tomorrow or the day after.
it s better to give a param in about:config which decides how much resource can be taken for the animation . by the way , can CSS transforms be use in this case ? just calc all the params before animation(it s very fast, and just in background) when user click a tabpreview, then just apply the calced CSS.
The halfway stop is indeed annoying, even on my decent machine (T61p), even with D3D enabled. It just looks like a broken animation.
(In reply to comment #7) > DOH! I'm guilty of the same mistake as the original code: do NOT skip drawing > the last frame by calling the "go to tab" code without a timeout after the last > frame has been drawn. That code is SYNCHRONOUS, meaning that your last drawn > frame will never actually be shown. Instead, it will hang until the real tab > content has been rendered. Uhm, does that mean you're manually changing the height/width values incrementally of the canvas/img element or its containing block? According to bug 604215 comment 7 tabcandy is using CSS transisions, there should be no script "controlling" the zoom at all. So who is right?
(In reply to comment #13) > (In reply to comment #7) > > DOH! I'm guilty of the same mistake as the original code: do NOT skip drawing > > the last frame by calling the "go to tab" code without a timeout after the last > > frame has been drawn. That code is SYNCHRONOUS, meaning that your last drawn > > frame will never actually be shown. Instead, it will hang until the real tab > > content has been rendered. > > Uhm, does that mean you're manually changing the height/width values > incrementally of the canvas/img element or its containing block? > > According to bug 604215 comment 7 tabcandy is using CSS transisions, there > should be no script "controlling" the zoom at all. > > So who is right? We certainly are using CSS transitions for the zoom; I'm not sure what Hans is talking about there.
See bug 624931 for a really fast zoom.
Switching to beta 11 for tracking, though we're making good progress on this and we may be ready to close this.
We have enough specific bugs on this topic that we can close this rather general bug. Bug 624931, for example.
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → INVALID
Product: Firefox → Firefox Graveyard
You need to log in before you can comment on or make changes to this bug.