CSS Units Changes Landed
The CSS units changes that I blogged about in January have landed and will be in the next Firefox milestone. With these changes, 1in = 96px always. Likewise 3pt = 4px, 25.4mm = 96px, etc.
This matches the behaviour of Internet Explorer, Safari and Chrome.
By default, when printing, 1in is rendered as one physical inch. For other output media, all these units are scaled in a medium-dependent and platform-dependent way by default. One goal of this scaling is to give results consistent with user expectations and other applications on the system. For example, standard form controls such as checkboxes should look the same in Web pages as in other applications, by default. Another goal is to choose default scaling so that a document designed to print well on normal-sized paper will be readable on the output device, e.g., a phone. So, the advice for authors using CSS physical units is to set lengths so the document looks good when printed without scaling; the browser will then scale those lengths to display the document suitably on different kinds of screens.
There are some rare cases where it makes sense to include true physical measurements in a Web document — for example, “life size” diagrams, or elements in a touch interface. For these cases we have introduced a new experimental unit, “mozmm”. For media such as screens that can be touched, 1mozmm is rendered as one physical millimetre (or as close as we can get based on what we know about the medium). For other media, such as contact lens displays, brain-implanted electrodes, or lasers projecting into the sky, we reserve the right to treat ‘mozmm’ similarly to ‘mm’. Authors should only use mozmm for elements which really need the same physical size on, for example, a 4″ phone screen and a 24″ monitor. This is hardly ever going to be what you want.
Internally, our DPI code has been overhauled. Everything is now controlled by two parameters: for each window, the number of device pixels per inch (returned by nsIWidget::GetDPI), and also for each window, the default scale (returned by nsIWidget::GetDefaultScale). The ‘layout.css.dpi’ about:config pref overrides the result of nsIWidget::GetDPI, if present. nsIWidget::GetDPI only affects the interpretation of mozmm (unlike before, where on some platforms, some DPI values would trigger automatic scaling). We set CSS 1px to one device pixel times GetDefaultScale times the current zoom factor. Currently GetDefaultScale always returns 1.0 on all platforms, although on Mac we should set it to the system “default UI scale” (and change some other code to compensate), and on Windows we should set it based on the “system font DPI”, which is essentially a user preference that controls scaling of all applications on the system. It’s important that the default scale be based on a system-wide setting; that will keep Firefox consistent with the rest of the system, and ensure that the user doesn’t get a surprise.
http://robert.ocallahan.org/2010/08/css-units-changes-landed_20.html
Firefox 7 is lean and fast
Firefox 7 uses less memory than Firefox 6 (and 5 and 4): often 20% to 30% less, and sometimes as much as 50% less. In particular, Firefox 7?s memory usage will stay steady if you leave it running overnight, and it will free up more memory when you close many tabs.
This means that Firefox 7 is faster (sometimes drastically so) and less likely to crash, particularly if you have many websites open at once and/or keep Firefox running for a long time between restarts.
Background
Firefox has a reputation for being a memory hog, and the efficiency with which it uses memory has varied over the years. For example, Firefox 2 was quite bad, but Firefox 3, 3.5 and 3.6 were substantially better. But Firefox 4 regressed again, partly due to a large number of new features (not all of which were maximally efficient in their first iteration), and partly due to some over-aggressive tuning of heuristics relating to JavaScript garbage collection and image decoding.
As a result, Mozilla engineers started an effort called MemShrink, the aim of which is to improve Firefox’s speed and stability by reducing its memory usage. A great deal of progress has been made in only 7 weeks, and thanks to Firefox’s new rapid release cycle, each improvement made will make its way into a final release in only 12–18 weeks. (These improvements are available earlier to users on the Aurora and Beta channels.) Firefox 7 is the first release to benefit from MemShrink’s successes, and the benefits are significant.
Quantifying the improvements
Measuring memory usage is difficult: there are no standard benchmarks, there are several different metrics you can use, and memory usage varies enormously depending on what the browser is doing. Someone who usually has only a handful of tabs open will have an entirely different experience from someone who usually has hundreds of tabs open. (This latter case is not uncommon, by the way, even though the idea of anyone having that many tabs open triggers astonishment and disbelief in many people. E.g. see the comment threads here and here.)
Canciones nuevas
Encuentra las ultimas canciones nuevas de el momento , La mejor y ultimos videos de el momentos los encuentras en ese nuevo blog , Espero que les guste.