1.21 MB, text/plain
3.47 KB, patch
|Details | Diff | Splinter Review|
Part 2: when switching into tab view, start the heartbeat only after the zoom operation has been finished
1.16 KB, patch
|Details | Diff | Splinter Review|
Part 3: Prioritize showing the target tab over internal maintenance tasks when switching to a tab from Panorama
1.23 KB, patch
|Details | Diff | Splinter Review|
Repro: 1. Create a couple groups, each with 100 or so tabs) 2. Click on a tab. Actual: Notice the animation is non-smooth or non-existant. Expected: The zoom animation is smooth.
[17:48] <The_8472> well, i have no clue how your code looks like. but the performance of zooming into a tab should not be dependent on the number of tabs [17:48] <The_8472> it seems like a constant-time operation to me [17:49] <iangilman> The_8472: I suspect it has to do with the complexity of the scene behind the zoom [17:49] <The_8472> that shouldn't have to be redrawn [17:49] <The_8472> you draw it without the zoom [17:49] <The_8472> then freeze it [17:49] <iangilman> I get the impression that firefox isn't terribly clever about caching all of the DOM elements behind a moving element [17:49] <The_8472> and render the zooming animation over the frozen element [17:49] <iangilman> right... but I don't think Firefox does that for us [17:49] <iangilman> ... and we haven't done it our selves [17:49] <The_8472> canvas can do it for you i guess [17:50] <The_8472> i see [17:50] <The_8472> if you just play with domnodes... yeahh... [17:50] <The_8472> are you using CSS transitions? [17:50] <The_8472> maybe those are more optimized than manually doing the resizing [17:51] <iangilman> yes, we're using css transitions [17:51] <The_8472> mhmh [17:51] <iangilman> and I haven't verified that it's not caching what's behind the animation, but it certainly seems that way [17:51] <The_8472> i thought the accelerated layers stuff in FF4 should optimize exactly this case
Assignee: nobody → seanedunn
Status: NEW → ASSIGNED
I'm making this p3 as I think having a large number of tabs (100 per group) is an edge-case
Priority: -- → P3
From conversation with Aza in #tabcandy, we want to push the 30FPS bar for as many items as possible, but have at least 15FPS for the 400 item case.
It would be interesting to know what the curve is for this; how slow is it per each new item added to the scene? We could test this with a script that repeatedly adds tabs and then simulates dragging a tab across the screen (once per tab added).
Adding roc; he may have some ideas as to how to best take advantage of the built in acceleration.
The zoom effect is just a CSS transform on the zooming tab, right? If so, we should indeed be caching the rest of the document in layers and not having to repaint. If it's an engine bug, a simplified testcase would help us.
(In reply to comment #6) > The zoom effect is just a CSS transform on the zooming tab, right? It is indeed.
Assignee: seanedunn → nobody
Component: TabCandy → Layout
Product: Firefox → Core
QA Contact: tabcandy → layout
blocking2.0: --- → final+
(In reply to comment #6) > If it's an engine bug, a simplified testcase would help us. Would you like it in the form of a mochitest that creates a single group with 400 empty tabs and then zooms to and from the first tab multiple times?
Anything that involves running TabCandy doesn't really count as "simplified" :-). Don't worry about testcases, we should start by just profiling the zoom in Tabcandy. Er, Panorama.
(In reply to comment #2) > I'm making this p3 as I think having a large number of tabs (100 per group) is > an edge-case Please do not. I almost always have over 100 Tabs. If you use TabMix+ it is easy and powerful. It is a matter of "usage preferences", they way in which people use the Browser. It is possible that _some_ people use a new Window instead of a new Tab for each URL, Firefox should work that way also with the only limit being available memory. (In reply to comment #9) > Anything that involves running TabCandy doesn't really count as "simplified" > :-). > > Don't worry about testcases, we should start by just profiling the zoom in > Tabcandy. Er, Panorama. I was looking for Dupes prior to posting and chose this Thread. 1. I find that the "Panorama" view takes a very long time to 'evolve' from blanks to _literally_ Thumbnails (too small to be of any use, need to be twice as big at least). 2. When you mouseover a Thumbnail you get nothing, not a Tooltip and not an enlargement of the Thumbnail. We should see the URL float over a "zoomed preview". 3. When you click on a (mystery) Thumbnail _sometimes_ you get a "zoomed preview" for an instant and sometimes for a whole half second, occasionally you get no preview at all. 4. Sometimes the "zoomed preview" is 'pixelated' (super blocky) but usually it shows a preview that is of too low a resolution to be of _much_ use (yet still enough to be of minor use - IE: it need to be of an even higher resolution). 5. Based on how long it takes to build the Panorama it ought to be able to squeeze out a higher resolution preview (or "zoomed transition" _IF_ that is the effect that is being attempted - IE: hard to tell as whatever is being done is not working very well). 6. The Panorama could be built up in the background so that if I try to use it TEN minutes after starting the Browser it WORKS perfectly and is BEAUTIFUL (stunning, please). 7. This next comment is a bit of an RFE but may make it easier to fix this Bug. We need a Checkbox that makes the Panorama render ONLY "above the fold" so we get even more useful information (should some people desire it). 8. If I simply click on another Tab I get a full screen view (full Browser Window view) instantly so why is it not possible for the "Panorama Subroutine" to do (behind the scenes): 1. a click on a Tab, 2. screenshot, 3. resize, 4. back to step 1 - faster than I could do it with a script (what I mean by that is that IF I had a clipboard utility that saved multiple clipboard events I could certainly click on each Tab and screenshot it FASTER than the "Panorama Subroutine" could generate it's preview. 9. Going directly back to the Panorama and re-clicking the same Tab as chosen previously does not always result in the same experience. Sometimes you get a poor-but-OK resolution Preview, sometimes you get a super-blocky Preview and sometimes you get nothing (or is what I am called a _very_ brief Preview supposed to be a zoomed transition - if it worked better I could tell). Sorry that sounds so negative, it WILL be a great feature after we fix it. Rob
(In reply to comment #10) Rob, These are all great items, but most of them are out of scope for this bug. If you're interested, each of those numbered items sound like they should have their own bug in the Tab Candy section.
(In reply to comment #11) > (In reply to comment #10) > > Rob, > > These are all great items, but most of them are out of scope for this bug. If > you're interested, each of those numbered items sound like they should have > their own bug in the Tab Candy section. I think only the second numbered is non-zoom related. The other comments are directly related to having this feature work "decently" as opposed to having a very poor "zooming transition" (it seems currently to be sort of a "Demo Feature" as opposed to a "Working Beautifully Feature"). Look at TabMix+'s "Tooltip Previews". It is true that they are placed too low and are too transparent but they are very very fast to popup and render perfectly at a greatly reduced size (on earlier versions of FF like Namoroka). Rob
(In reply to comment #12) Rob, I completely agree. It's not a question of whether their zoom related or not, it would just be nice if all of those individual items were in separate bugs so that we could work on them, triage them, prioritize them individually. This way we can give them each the attention they deserve. :)
(In reply to comment #13) > (In reply to comment #12) > > Rob, I completely agree. It's not a question of whether their zoom related or > not, it would just be nice if all of those individual items were in separate > bugs so that we could work on them, triage them, prioritize them individually. > This way we can give them each the attention they deserve. :) I just found 4.0b8pre (Minefield) and it works WAY better. Now it is "nearly smooth", it simply doesn't have enough resolution (pixelated 4x effect). It loads all the previews quite fast (and my 100 Tabs load really fast too!) and is great except for it's even poorly ability to host Add-ons (it _might_ be able to but the Add-ons don't accept so new a version). I think if the "pixelating' were fixed (and that is NOT part of _this_ BR) then _this_ BR would also be demonstrable as fixed. If you could imagine the "poorer than desired rendering" as being better then you could guess that '4.0b8' likely fixes this BR. Rob References: http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk/firefox-4.0b8pre.en-US.win32.installer.exe
(In reply to comment #13) > (In reply to comment #12) > > Rob, I completely agree. It's not a question of whether their zoom related or > not, it would just be nice if all of those individual items were in separate > bugs so that we could work on them, triage them, prioritize them individually. > This way we can give them each the attention they deserve. :) Kevin, Filed: Bug 608560 Rob
Let's profile and then retriage/reassign.
Assignee: nobody → ehsan
This version http://releases.mozilla.org/pub/mozilla.org/firefox/releases/4.0b8/linux-i686/en-US/firefox-4.0b8.tar.bz2 is beautiful but a tiny bit stuttered (when running under VMware on WinXP) with only TWO Tabs. I've used VMWare a fair bit and it ought not to stutter like that. There would be more 'Processor Time' available if the 'zoom transition' had a few less frames in the 'non-stuttering portion' so the portion of the transition that stuttered could have more processing time. It looks (and feels) totally different than the WinXP version (which does not help for Bug Reporting). Rob
(In reply to comment #18) > This version > http://releases.mozilla.org/pub/mozilla.org/firefox/releases/4.0b8/linux-i686/en-US/firefox-4.0b8.tar.bz2 > is beautiful but a tiny bit stuttered (when running under VMware on WinXP) with > only TWO Tabs. > .... > Rob With over 150 Tabs it is AWFUL. The "zoom" has three levels, "puny", "a bunch-of-blocks", and the whole Page". If you click on a Tile then click on the "Panorama Button" (again) _immediately_ you can see "one of the zoomed tiles?" for a moment before it disappears (and it has HIGH resolution !?!). It should 'zoom' equally well with a couple of Tiles and LOTS. Thanks, Rob
(In reply to comment #19) > It should 'zoom' equally well with a couple of Tiles and LOTS. Here is a Page with TONs of Tiles. If you have the "SilverLight Plug-in" you can see what "Microsoft DeepZoom" looks like; smooth sweeping pans and zooms of many Tiles: http://galleryzoom.co.uk/aho1.html
Rob, you're talking too much. Zoom is an issue, but posting walls of text with random emphasis, underlines, allcaps and linking to silverlight and random mozilla plugins doesn't help anybody. This is a bug tracker, not a discussion forum. Keep it concise and the rants down to a minimum. Yes, performance is an issue. But it's being worked on from what i can gather.
So I created an extremely large session, and profiled it. It seems like we're spending most of our time in JS. I think that when we call TabItems.pausePainting, we actually need to cancel the heartbeat, and to reenable it when resumePainting is called (the latter already happens in the code). I'm trying this idea out locally...
Warning: it's probably going to take some time for Firefox to load this session. Don't use it unless you're ready to wait!
This implements my idea in comment 22. It does improve the performance noticeably. More to come (/me wishes that Shark was faster...).
Comment on attachment 503347 [details] [diff] [review] Part 1: stop the heartbeat when a zoom is in progress Looks good to me. Also requesting feedback from Sean, who's done a lot of work in this area.
Ehsan, while you're in there, I just ran across another bad one! In UI.showTabView, we call TabItems.resumePainting() right after starting the zoom, rather than waiting until the zoom is done. Please fix this as well.
(In reply to comment #26) > Ehsan, while you're in there, I just ran across another bad one! In > UI.showTabView, we call TabItems.resumePainting() right after starting the > zoom, rather than waiting until the zoom is done. Please fix this as well. Good catch. This patch fixes that.
Attachment #503939 - Flags: review?(ian)
When a zoom in operation ends, we should prioritize actually displaying the current tab over all else. Right now we do that as the last thing on our list, and this patch changes the order of things to make sure that the tab is displayed before all of our internal maintenance.
Attachment #504156 - Flags: review?(ian)
With these patches, the zoom animation performance is much better on large tabview sessions. The only hit that I see from time to time is gc, but there isn't much that we can do about that here. I should also mention that during all of the profiling that I did here, I never noticed layout to be a bottleneck. The main source of perf hit here was the tabview heartbeat timers.
Whiteboard: [softblocker] → [softblocker][has patch][needs review ian]
OT: Ehsan, if you have a chance sometime, I (and perhaps also Sean or Ian) would love to know how you do this profiling. :)
(In reply to comment #30) > OT: Ehsan, if you have a chance sometime, I (and perhaps also Sean or Ian) > would love to know how you do this profiling. :) Sure, just ping me on IRC on Monday. :-)
Comment on attachment 503939 [details] [diff] [review] Part 2: when switching into tab view, start the heartbeat only after the zoom operation has been finished Lovely
Attachment #503939 - Flags: review?(ian) → review+
Attachment #503347 - Flags: feedback?(seanedunn) → feedback+
Comment on attachment 504156 [details] [diff] [review] Part 3: Prioritize showing the target tab over internal maintenance tasks when switching to a tab from Panorama Yes, good catch.
Attachment #504156 - Flags: review?(ian) → review+
http://hg.mozilla.org/mozilla-central/rev/69e56ac91ec4 http://hg.mozilla.org/mozilla-central/rev/3ff94e47854d http://hg.mozilla.org/mozilla-central/rev/f2091ca7dc39
Status: ASSIGNED → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Whiteboard: [softblocker][has patch][needs review ian] → [softblocker]
Target Milestone: --- → mozilla2.0b10
No longer blocks: 626527
Component: Layout → TabCandy
Product: Core → Firefox
QA Contact: layout → tabcandy
Target Milestone: mozilla2.0b10 → Firefox 4.0b10
Version: unspecified → Trunk
verified with nightly build of minefield.
Status: RESOLVED → VERIFIED
The issue is still reproducible on Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0) Gecko/20100101 Firefox/9.0. There is a non-smooth transition from Tabs Group to browser even there are just a few tabs opened. Also a rendering issue, the pixels of the page are seen due the transition.
You need to log in before you can comment on or make changes to this bug.