Closed Bug 608560 Opened 14 years ago Closed 8 years ago

Panorama (TabCandy) needs higher resolution previews and higher rez. Zooming (with ToolTips)

Categories

(Firefox Graveyard :: Panorama, enhancement, P3)

x86
Windows XP
enhancement

Tracking

(Not tracked)

RESOLVED WONTFIX
Future

People

(Reporter: rob1weld, Unassigned)

Details

Attachments

(6 files)

User-Agent:       Mozilla/5.0 (Windows NT 5.1; rv:2.0b8pre) Gecko/20101030 Firefox/4.0b8pre
Build Identifier: Mozilla/5.0 (Windows NT 5.1; rv:2.0b8pre) Gecko/20101030 Firefox/4.0b8pre

RFE: See: https://bugzilla.mozilla.org/show_bug.cgi?id=604215#c10


This RFE is limited to these comments from 604215#c10

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

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

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

The above points relate ONLY to having higher resolution Previews on the Panorama, other points made in 604215#c10 are not the subject of this RFE.

Rob


Reproducible: Always



Expected Results:  

A beautiful Preview that zooms in like a "beauty pass" (This is fair definition: http://www.youtube.com/watch?v=rE4PlmVWUsw or http://www.youtube.com/watch?v=BJACXApym1g ) of the Enterprise _AND_ shows some useful information (because it has sufficient resolution).

This could be further enhanced by clicking a checkbox that causes the render to be done ONLY on the area "above-the-fold".
The software called "Impressive" accepts a '.PDF' as input and creates a Presentation from it. It is written in Python so you can view the source and see how these effects are done.


Re. "Transitions" in the software "Impressive" from: http://swik.net/KeyJnote

"It’s written in Python and focuses on style and eyecandy, powered by OpenGL, ... "


Here is source code and a movie (better than dinner and a movie).


"Impressive" (used to be called KeyJnote)
http://sourceforge.net/projects/impressive/files/

"Impressive" PDF Presentation
http://www.youtube.com/watch?v=orwQO-1Oilk


In the Youtube Video (at times 0:30 1:00 and 1:14) there is shown a set of tiles that represent each page in the Presentation. The Video shows how you can go from one tile to the next and the way it zooms in. 

The level of quality demonstrated in this Video shows what our (haha) "TabCandy" could look like if it were much better.


Rob
Component: General → TabCandy
QA Contact: general → tabcandy
Version: unspecified → Trunk
The only time we don't have high-res thumbnails is when we are zooming them in, is this what you're referring to? Making those higher-res would be a significant perf decrease.

 The rest of the time our thumbnails are 1:1. Unless you are referring to bug 587231, which we landed sometime after b7. 

Do you still feel like we need higher-res thumbnails on the latest nightly?
Priority: -- → P3
Target Milestone: --- → Future
Here is an example of what my System looks like when the Browser is open at a well known Page. The "Java Console" is open due to the use of Java on a different Page but it should serve as a size comparison since it is shown at the "as opened sized" (it was not resized).
If I click on the Panorama Button this is what I see come up.
I can drag the edge to resize but the Icons get no bigger. The resized Window COVERS the "Search in Tabs" Button but the "un-Panorama" Button is 'always on Top'.
If I use Lanczos resizing on the full size image and then reduce the image I get a (very) slightly clearer version than you do. The "Pixel art scaling algorithms" should provide you with an even better image than my version.
This is a screen capture made by skillfully hitting the [Prnt Scr] Key in mid-flight of the zoom (after left clicking). 

Notice how pixelated it (the 'fly-out') is. Instead of deriving this image by zooming up 200% (the puny icon) you should have derived this image by zooming DOWN 50% the FULL SIZE rendering that is contained in the Tab you are going to (not the icon you are coming from).
This is what it SHOULD look like (if the Data used to calculate the zoom were not derived backwards). I would like to see something like this screenshot when I hover over a Tab in the Panorama. Notice the left and right buttons on the edges of the Icon along with a Tooltip to say what the full URL is.
(In reply to comment #2)
> The only time we don't have high-res thumbnails is when we are zooming them in,
> is this what you're referring to? Making those higher-res would be a
> significant perf decrease.

If you derive the "fly out" from the full sized image (scale it down), instead of zooming the little icon up and making pixels bigger, it would be of better quality and the algorithm COULD run in a similar amount of time

Even better would be to use some of the "extra info" in the larger image to 'make decisions' of which pixel to use --- BUT I HEAR YA, you don't want the icon emblazoned on the side of the Enterprise (with live feed from Jim, Spock and Bones) as it zooms by due to performance concerns.

That is why I suggested "Impressive" (used to be called KeyJnote) as it shows a 'simplistic' approach (yet has OpenGL to help).


Your "fly outs" are awful when the majority of the content is written text (yet reasonable for images). If you can only "afford" 3 or 4 frames on your fly-out that is OK but let us have readable text mid-flight (just so it looks correct and costs (almost) no extra time in execution).


>  The rest of the time our thumbnails are 1:1. Unless you are referring to bug
> 587231, which we landed sometime after b7. 

They look 1:10 if that is what you mean but when they "fly-out" let us say they are then at 5:1; the problem is that then they are PIXELS that are 5 times bigger (block) instead of being a rendering of the ORIGINAL Tab at 1/2 the size.


> Do you still feel like we need higher-res thumbnails on the latest nightly?

YES, PLEASE. This is an RFE. We (did?) call it "Tab Candy" yet it is like gum under the desk. 

I understand performance concerns but it could be better without much of an increase utilizing some of the best algorithms for this purpose (instead of zooming the puny icon).

It could also bet better with (next to) NO change in performance and a HUGE difference in the "mid-flight" be using different source Data.

-----

My "complaint" (RFE) is:
1. The "Icons" should be almost TWICE as large as they are.
2. The Icons could be created by "Lanczos Resizing" as a MINIMUM standard.
3. The Icons should use "hqx scaling" http://en.wikipedia.org/wiki/Pixel_art_scaling_algorithms#hqnx_family or
use the "origonal rendering" (the full size version that you would see IF you clicked on the Tab) and reduce it rather
than using the puny pixelated version and scaling it up (the scaler algorithim derives it's Data 'backwards').
4. Hover over an Icon for a "zoomed preview" (without going to the Page). The left and right edges of the Preview would 
have arrows so you could go to the next Icon (or use the mouse wheel). Movement should "flow" (even if you miss frames).
5. When you hover you get a "Tooltip" that shows the full URL.


* So, yes, Kevin; to fulfill _this_ RFE I need four or five things. 

* To fix what I perceive as a BUG (NOT the new one in 608560#c5, the blocky zooming shown in 608560#c7) I need only one thing (change the 'source Data' from icon to Tab).


Thank you kindly for reading my Post Kevin. We appreciate that this feature was implemented and thank everyone for their efforts; we just want "Tab Candy" to look better.

Rob
The "Pile Flyout" [1] also need to utilize better resolution.

It also needs more frames than just a few. To flyout a large 'pile' you will need 12 frames to do it in 1/2 a second with the quality of an old film movie (or 1/2 of 29.97 frames for "DVD Quality").


[1] The "Pile" is created in the Panorama by moving the Mouse to the lower right corner of the inner Pane of the Panorama. Now left-click and drag to resize the inner Pane (not the whole Panorama) so it is much smaller (until the individual icons 'jump' into a "Pile").
(In reply to comment #2)
> The only time we don't have high-res thumbnails is when we are zooming them in,
> is this what you're referring to? Making those higher-res would be a
> significant perf decrease.


Here is an example of (TRUE) "Tab Candy". This is a 'UI Replacement' for your Symbian Cell Phone. This shows what we might want for "Firefox Mobile" (or even our Desktop!).


SPB Mobile Shell 
http://spb.com/symbian-software/mobileshell/screenshots.html

http://spb.com/uploads/images/mobileshell/Screenshots/Symbian/3.5/501.png

Rob
A 'trick' that proves a fault with the algorithm is:

1. Start 4.0b8pre with more than 80 Tabs open using Tab Mix Plus.

2. When you get a few Tabs loaded click the Panorama Button and watch the speed at which the <title> for each Page is looked up and displayed.

3. Resize the inner Panorama Pane (not the whole Window) so it is smaller (but don't "Pile" it), half size is good enough. Notice that the lookup and display of the URL is much quicker (even if you can't see much of in any event).

4. Let half the Tabs get their URL text displayed and now resize the inner Pane to 90% full size (and at least twice as big as it was to start with). Notice the text load much slower and the 'Icons' will have some rendered "extra-poorly" and some "white with the Site's "URLIcon" in the corner.

5. Wait a minute. The Icons should redraw and the white ones will have a small rendering while the ones already rendered will "un-smudge" a little.


It seems odd that the size of the 'inner Pane' would so influence the speed at which each URL's text could be displayed. I would have imagined that all that text could be displayed nearly instantly, here we have a situation were this does not occur. 

There is something in the loop hogging the uP and making the whole function slower than it need be; as demonstrated in my prior comment 11 a meager Cell Phone can have "Tab Candy" so we should have the GIPS (more than MIPS) to do it.

It is as though the zoom algorithm were calculating EVERY single point in double floating point and then rendering each 128TH POINT in just 256 colors (doing a lot of calculating and throwing out the result). 

I hope it is binary zooming (math done by shifts) and not floating point multiply or divide to the powers of 2 (expensive) and that you derive your render data by skipping input instead of (calculating what you will not render) simply throwing away output.


Thanks
Rob
A perfect example of what this could look like is here: http://xoctave.webs.com/apps/photos/album?albumid=5929407 just click on the Link that says "View as Slideshow" (it is a 'JavaScript Link') and you end up being asked to install the "CoolIris Plugin".

After installing CoolIris go back to that Album, now it has 'flying 3D tiles' and zooming popups. All of this from a "FireFox Plug-in" (so something built-in to the Browser could be MUCH better, but really only needs to be half as great as CoolIris).


Thanks,
Rob
See Bug 604215 Comment 18 --- You are VERY close under Linux (ran using VMWare under WinXP, using a limited number of Tabs). The last 'WinXP version' I ran looked nothing like that "Linux Binary". 

See Comment 13 in this thread about "CoolIris" it waves around and zooms nicely.

Rob
(In reply to comment #2)
> The only time we don't have high-res thumbnails is when we are zooming them in,
> Do you still feel like we need higher-res thumbnails on the latest nightly?

FoxTab lacks "zooming" (when you click on a Tile) but it offers a nice choice of "Tile Layouts" that you may wish to view: https://addons.mozilla.org/en-US/firefox/addon/8879/ you can easily compare what various resolutions would look like as it ALSO has a choice of sizes.

Rob
Mozilla/5.0 (Windows NT 5.1; rv:2.0b10) Gecko/20100101 Firefox/4.0b10 - Build ID: 20110121161358


I am changing this from an "Enhancement" to a "BUG" on the basis that "Panorama" looks NOTHING like it is advertised to be on this Page:

http://www.mozilla.com/en-US/firefox/4.0b9/whatsnew/

If you have FF4 you can see a wonderful video here: http://videos-cdn.mozilla.net/serv/firefox4beta/grouptabs.webm


Panorama zooms nicely and the Tiles are of a reasonable enough resolution (in that Video but not in FF, on WinXP with a decent Video Card) that you get the idea on what is on each Page (assuming a fair quality memory). 

With many Tiles each is far too tiny (a scrollbar on the Pane would help) and when it "zooms" (if that is what you call it :Q ) it is extra-low-resolution and super-low-frame rate (it could hardly be twice as bad).

Rob
Severity: enhancement → normal
Summary: Panorama (TabCandy) needs higher resolution previews → Panorama (TabCandy) needs higher resolution previews and higher rez. Zooming (with ToolTips)
Changing this back to an RFE.

We used to have "zooming" (which did not work very smoothly) and now I would be hard pressed to see a single frame in between the un-zoomed and fully zoomed state; thus I would suggest the zooming is removed (though it is possible that on slower Computers the 'timing Code' causes it to be bypassed alltogether).
Severity: normal → enhancement
Panorama has been removed from Firefox 45, currently in Beta and scheduled for release on March 7th. As such, I'm closing all existing Panorama bugs.

If you are still using Panorama, you will see a deprecation message in Firefox 44, and when 45 is released your tab group data will be migrated to bookmarks, with a folder for each group. There are also a few addons offering similar functionality.

See https://support.mozilla.org/en-US/kb/tab-groups-removal for more info.

We're removing Panorama because it has extremely low usage (about 0.01% of users), and has a large number of bugs and usability issues. The cost of fixing all those issues is far too high to justify, and so we'll instead be focusing our time and energy on improving other parts of Firefox.
Status: UNCONFIRMED → RESOLVED
Closed: 8 years ago
Resolution: --- → WONTFIX
Product: Firefox → Firefox Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: