Web Info & Tutorials

Stuart Parmenter has been blogging about his work on memory usage and various malloc() libraries and their tradeoffs.

In his latest, he talks about the memory usage in Firefox 3 today and the work that he has done:

• Reduced Memory fragmentation: One of the things we did to help was to minimize the number of total allocations we did, to avoid unnecessarily churning memory. We’ve managed to reduce allocations in almost all areas of our code base.
• Fixed cycles with the Cycle collector: For Gecko 1.9, we’ve implemented an automated cycle collector that can recognize cycles in the in-memory object graph and break them automatically.
• Tuned our caches: In many cases we’ve added expiration policies to our caches which give performance benefits in the most important cases, but don’t eat up memory forever. We now expire cached documents in the back/forward cache after 30 minutes since you likely won’t be going back to them anytime soon. We have timer based font caches as well as caches of computed text metrics that are very short lived.
• Adjusted how we store image data: In Firefox 3, thanks to some work by Federico Mena-Quintero (of GNOME fame), we now throw away the uncompressed data after it hasn’t been used for a short while. Another fantastic change from Alfred Kayser changed the way we store animated GIFs so that they take up a lot less memory. We now store the animated frames as 8bit data along with a palette rather than storing them as 32 bits per pixel.

What about the tests?

For the results below we loaded 29 different web pages through 30 windows over 11 cycles (319 total page loads), always opening a new window for each page load (closing the oldest window alive once we hit 30 windows). At the end we close all the windows but one and let the browser sit for a few minutes so see if they will reclaim memory, clear short-term caches, etc. There is a 3 second delay between page loads to try and get all the browsers to take the same amount of time.

Great work guys, and thanks for talking to us about how you are doing this work!

Neil Roberts has posted a great article on Creating Your Own $ with Dojo:

The bling, one of the best global variables in JavaScript. A tool which has come to mean, as a function, a way to locate a node or set of nodes. And, as a namespace, a simple way to access often-used functionality. "This can't be done with Dojo," you insist. But you're wrong, it's really easy. The ideas behind this little symbol are quite simple and I'm going to show you how to create your own customized version of it.

He manages to walk us through a path where he gets $ working in a way that mimics jQuery. He starts with $ = dojo.query; and ends up with:

He then tackles plugins and using:

You end up being able to do:

Very cool indeed!

“This module not invoke the frugalness around or mend every the problems in the markets but it should turn the liquidity issue, at small for now”

The Bank of Canada is connexion an planetary try to support assist the orbicular assign crisis, injecting $4 1000000000 in liquidity into top markets over the incoming some months. via CFRB

PPK has blogged a critique of the new W3C CSSOM View Module. He is a fan:

W3C published the first working draft of the W3C CSSOM View specification (written by Anne van Kesteren), and I must say I'm very happy with it. Since I was testing stuff anyway I created a new compatibility table for most of the methods and properties specified in this document, and browser compatibility is already excellent.

What does this new module do? "The APIs introduced by this specification provide authors with a way to inspect and manipulate the view information of a document. This includes getting the position of element layout boxes, obtaining the width of the viewport through script, and also scrolling an element."

PPK calls out one special method, elementFromPoint:

This method expects two coordinates and then reports which HTML element is located at these coordinates. This is a godsend for drag-and-drop scripts. If the user drops an element, get the mouse coordinates and use this method to find out which HTML element is located at these coordinates.

One catch: you first have to temporarily hide the dragged element, because otherwise elementFromPoint() would always report the dragged element — after all it itself is the topmost element under the mouse.

I'm going to add this functionality to my Drag and Drop script, but for the moment this seems to be the idea:

PLAIN TEXT

JAVASCRIPT:

1.  
2. releaseElement: function(e) { // called onmouseup
3.         var evt = e || window.event;
4.         dragDrop.draggedObject.style.display = 'none';
5.         var receiver
6.                 = document.elementFromPoint(evt.clientX,evt.clientY);
7.         dragDrop.draggedObject.style.display = '';
8.  

Andrew Dupont, Thomas Fuchs, John Resig, Alex Russell, Sam Stephenson. These were the folks that gathered at SXSW to talk about the "Secrets of JavaScript Libraries" in a panel that was full to the brim (as was the browser wars one the day before).

The slides are now up, and the podcast is forthcoming:

The group covered:

• JavaScript the language
• Cross browser coding
• Events
• DOM Traversal
• HTML Style
• Animations
• Distribution
• HTML Insertion

I hope that SXSW ramps up a little on the technical talks next year.