597458 - Investigate different drawing techniques for TabCandy/Panorama zoom transition

Status: RESOLVED INVALID

(Firefox Graveyard :: Panorama, defect, P3)

Description

[Hans Schmucker]

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

Comment 1

[Hans Schmucker]

Attachment: Test using an ultra-low-resolution Canvas

Comment 2

[Michael Yoshitaka Erlewine [:mitcho]]

Hans, thanks for taking a lead on this. P3 for investigation.

Comment 3

[Hans Schmucker]

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.

Comment 4

[Hans Schmucker]

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.

Comment 5

[Hans Schmucker]

Attachment: Alternative TabItem::zoomIn using MozBeforePaint

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?

Comment 6

[Hans Schmucker]

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).

Comment 7

[Hans Schmucker]

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.

Comment 8

[Ian Gilman [:iangilman]]

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?

Comment 9

[Hans Schmucker]

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.

Comment 10

[Hans Schmucker]

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.

Comment 11

[Lyricconch]

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.

Comment 12

[Alfred Kayser]

The halfway stop is indeed annoying, even on my decent machine (T61p), even with D3D enabled. It just looks like a broken animation.

Comment 13

[The 8472]

(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?

Comment 14

[Ian Gilman [:iangilman]]

(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.

Comment 15

[Patrick Walton (:pcwalton)]

See bug 624931 for a really fast zoom.

Comment 16

[Michael Yoshitaka Erlewine [:mitcho]]

Switching to beta 11 for tracking, though we're making good progress on this and we may be ready to close this.

Comment 17

[Kevin Hanes]

We have enough specific bugs on this topic that we can close this rather general bug. Bug 624931, for example.