Talk:Firefox/Namoroka/Initial Plan: Difference between revisions

← Older edit

Talk:Firefox/Namoroka/Initial Plan (view source)

Revision as of 02:12, 29 August 2009

10,557 bytes added , 29 August 2009

Add Suggestion For Resend Dialog Sheet

Ggoo

2

edits

@@ Line 14: / Line 14: @@
 *And what about Linux integration?
 *GNOME key-manager, Notify-OSD for notifications, for example.
+* KDE integration is a much-requested, but sadly inexistent feature.
 == MacMel ==
@@ Line 24: / Line 25: @@
 == DougT ==
 * Both windows 7 and snow leopard will have location services.  Our geolocation implementation should make use of these system services.
+** ''KDE on Linux is also is the process of creating a geolocation service, scheduled for 4.4, afair.''
 == jwatt ==
@@ Line 201: / Line 203: @@
 Note: Simon Montagu appears to be working on the bug.
 : [[User:Znerd|Znerd]] 09:57, 11 July 2009 (UTC)
+==CarlosM==
+===Optimize Linux Builds===
+Linux builds have lower performance than the windows builds even if you run the windows build using Wine. the test I'm doing consist on running the different builds and enter to this link:
+* [http://v8.googlecode.com/svn/data/benchmarks/v5/run.html V8 Benchmark Suite ]
+This link points to the JavaScript code used to verify the Google Chrome performance.
+The score shown may vary on +-5 points from run to run but when compared between different platform builds it may run from 180 on the linux-native build to 240 at the Windows native build.
+==== Note from Chris Blizzard ====
+Carlo - The windows builds are faster because the compiler generally creates better code than gcc does.  Plus, afaik, we can't use PGO on Linux because of tooling problems with the profiling tools and threaded applications.  We've spent a lot of time optimizing Linux but if you would be willing to help get some gcc people to look at those tools it would help a lot - thanks!
+Apparently, Tracemonkey/JIT isn't available for 64bit yet. This would explain why many Linux users have a poor experience, especially with JS benchmarks pointed to by CarlosM. [[User:Pweilbacher|paepse]] 09:06, 20 August 2009 (UTC)
+== Samuelspiza ==
+=== Menu Bar ===
+I really like the option to hide the Menu Bar in 3.6a1. It brings the Interface closer to a point where it only contains features i really need.
+However i think the handling of the problem could be further improved. With a hidden Menu Bar functions that have no keyboard shortcut are not quite handy to access. (Preferences, Addons, Update, + everything you doesn't do reguarly enough to remember the shortcut)
+I have to click twice to undo the hiding. Then at least two clicks to access the function. Finally two more clicks to hide the Bar again. Even if I need functions from the Menu Bar only once or twice a day this procedure feels somehow arbitary complicated.
+The prefered solution for me would be an option to hide the menus under a button right next to the home/reload buttons. This Layout would still save many pixels compared to a whole bar. However it would have lower burden to access the features.
+== First Impressions I Have From a User Standpoint ==
+I'm no tech or anything when it comes to browsers I just know what I like and functionality of them. Can't say how to change stuff or make it better, just know how to see if they work properly for day to day activities with certain add-ons.
+I am running Vista Ultimate 64 with the latest updates.
+Still running RedShift v3 with no issues (well it may be causing my issues too).
+All add-ons that shouldn't work so far seem to be working fine (that I use on a day to day basis).
+*last.fm isn't working (but shouldn't and just noticed)
+Having issues adding Bookmarks (they won't) and all my saved bookmarks didn't transfer over (probably have to do something else but unsure what atm).
+Doesn't seem to eat memory like 3.5.2 does or hold on in the system after it was closed.
+Also doesn't seem to use the processor up like 3.5.2 did instead seems to be taking less.
+The memory seems to pretty much stay stable the whole time also.
+Overall seems more stable then 3.5.2
+Running Quad Extreme Q9650, 4GB 1066MHz RAM, on a 780i MB, with Raptor HDD, under Vista Ultimate 64.
+Current benchmarks of browsers I currently have installed (used peacekeeper for test http://service.futuremark.com/peacekeeper/index.action). I only did one run per browser but the numbers are far enough apart to make the point.
+Minefield 3.7a1pre - 2578 (22 Aug) 2216 (24 Aug)
+Namoroka 3.6a1 - 2441
+Firefox 3.5.2 - 2036
+Chrome 3.0.195.6 - 3829
+IE 8.0.6001.18813 - 868
+IE 8.0.6001.18813 64-bit - 881
+Chrome still wins even in Sunspider test at 507ms on my setup.
+Minefield is close behind too with 796.6 (22 Aug) 933.2 (24 Aug) so they've already taken over 100ms off between an alpha and pre-alpha release. I believe Firefox can squeak out past everyone shortly. Also see the jump from 3.6 to 3.7 soon with Minefields marks.
+Minefileld is getting worse actually in marks. Haven't tested 3.5.3 yet nor 3.6a2pre.
+Sunspider Test between 3.5.2 (left) and 3.6a1 (right)
+TEST                   COMPARISON            FROM                 TO             DETAILS
+=============================================================================
+** TOTAL **:           1.27x as fast     1228.4ms +/- 3.6%   970.0ms +/- 2.0%     significant
+=============================================================================
+d:                  -                  176.2ms +/- 13.2%   154.6ms +/- 7.3%
+    cube:              1.29x as fast       51.2ms +/- 3.6%    39.6ms +/- 13.4%     significant
+    morph:             -                   55.2ms +/- 20.2%    55.0ms +/- 1.6%
+    raytrace:          -                   69.8ms +/- 25.7%    60.0ms +/- 18.3%
+  access:              -                  146.4ms +/- 9.3%   131.8ms +/- 14.7%
+    binary-trees:      -                   41.8ms +/- 19.7%    39.6ms +/- 16.7%
+    fannkuch:          -                   61.6ms +/- 19.4%    55.4ms +/- 20.8%
+    nbody:             1.20x as fast       28.4ms +/- 2.4%    23.6ms +/- 8.8%     significant
+    nsieve:            -                   14.6ms +/- 11.4%    13.2ms +/- 32.2%
+  bitops:              -                   40.2ms +/- 10.1%    38.8ms +/- 3.5%
+bit-bits-in-byte: 1.25x as fast        2.0ms +/- 0.0%     1.6ms +/- 42.6%     significant
+    bits-in-byte:      1.04x as fast       10.0ms +/- 0.0%     9.6ms +/- 7.1%     significant
+    bitwise-and:       ??                   2.2ms +/- 25.3%     2.8ms +/- 19.9%     not conclusive: might be *1.27x as slow*
+    nsieve-bits:       -                   26.0ms +/- 17.6%    24.8ms +/- 2.2%
+  controlflow:         -                   42.8ms +/- 9.7%    39.6ms +/- 14.8%
+    recursive:         -                   42.8ms +/- 9.7%    39.6ms +/- 14.8%
+  crypto:              1.36x as fast       67.6ms +/- 4.2%    49.6ms +/- 13.3%     significant
+    aes:               1.38x as fast       40.4ms +/- 3.5%    29.2ms +/- 22.8%     significant
+    md5:               1.37x as fast       17.0ms +/- 17.9%    12.4ms +/- 5.5%     significant
+    sha1:              1.27x as fast       10.2ms +/- 5.5%     8.0ms +/- 0.0%     significant
+  date:                1.28x as fast      203.6ms +/- 7.4%   159.0ms +/- 14.3%     significant
+    format-tofte:      1.40x as fast      106.2ms +/- 6.3%    75.8ms +/- 19.4%     significant
+    format-xparb:      1.17x as fast       97.4ms +/- 10.9%    83.2ms +/- 16.8%     significant
+  math:                1.10x as fast       60.2ms +/- 1.7%    54.8ms +/- 8.2%     significant
+    cordic:            1.15x as fast       34.4ms +/- 2.0%    30.0ms +/- 15.5%     significant
+    partial-sums:      1.05x as fast       17.6ms +/- 3.9%    16.8ms +/- 3.3%     significant
+    spectral-norm:     -                    8.2ms +/- 6.8%     8.0ms +/- 0.0%
+  regexp:              1.57x as fast      109.4ms +/- 9.5%    69.8ms +/- 20.1%     significant
+    dna:               1.57x as fast      109.4ms +/- 9.5%    69.8ms +/- 20.1%     significant
+  string:              1.40x as fast      382.0ms +/- 5.5%   272.0ms +/- 6.2%     significant
+    base64:            1.27x as fast       19.0ms +/- 0.0%    15.0ms +/- 19.4%     significant
+    fasta:             1.59x as fast       87.8ms +/- 1.8%    55.2ms +/- 19.5%     significant
+    tagcloud:          1.13x as fast       96.8ms +/- 10.0%    85.6ms +/- 8.4%     significant
+    unpack-code:       1.65x as fast      138.0ms +/- 17.8%    83.8ms +/- 14.0%     significant
+    validate-input:    -                   40.4ms +/- 19.4%    32.4ms +/- 16.4%
+== jacekmw ==
+====Windows 7 Jump Lists====
+Currently, the Windows 7 Jump List functionality can be obtained for Firefox with [https://brentf.com/blog/software/winfox-ndash-firefox-and-windows-7/ WinFox], but it would be useful for a standard install to have this.  The Pinned/Frequent/Tasks model WinFox uses would work well, and would mirror the way jump lists are used for many native Windows apps (IE8, WMP, etc)
+== ggoo ==
+Currently when restarting Firefox, if one has it configured to restore windows from a previous session, any pages with POST data will display a sheet explaining that the data must be resent to redisplay the page.  This is of course necessary any time one wants to redisplay a POSTed page, and the decision must be available to the user.  There are two problems I will address about this feature, one with what appears to be the current plan to change it, and the other, a problem with the current behavior.
+I see at <https://wiki.mozilla.org/Firefox3/Product_Requirements_Document> at item "GKO-002a" that this sheet (as it's displayed under Mac OS X, at least) is apparently going to be changed to an error page!  This could be a big disappointment, as it would seem to mean one would lose all the forward history in the window or tab!  It might be that this should be an optional setting, but it shouldn't be mandatory for those of us who like to be able to retain the forward history.
+The other problem with the message is not normally an issue when one is using the Back button to navigate to a page that needs reloading, but is a problem when one is restoring a window with several tabs.  In the latter case the message dialog sheet obscures the URL field in the address bar, so one can't tell what page one is being asked to resend data for.  This leaves one in the awkward position of either guessing what page it is, or just declining to reload ''all'' pages initially, in which case one gets an error page for each of them, and loses all the forward history for each such tab, which as I explained above, I often wish to retain.  If the dialog message were simply elaborated to include the URL (and possibly the original title, if it is saved between sessions) of the page that needs reloading, then a better decision could be made by the user.
+So please retain the modal dialog type of notification (such as a sheet) for pages that require POST data to be resent, '''at least as an option''', but modify the dialog to be explicit as to the URL receiving the data (since that's the page to be displayed), and possibly the URL sending the data as well, if they differ significantly.
+[[User:Ggoo|Ggoo]] 02:12, 29 August 2009 (UTC)