So.

Is it as fun as it used to be?

Archive for the ‘Mac OS/X’ Category

How To Destroy Page Rendering Performance Using Just Javascript and CSS

So. Did you know that a severe impact on browser rendering time can be caused by CSS and javascript not playing nicely together? Rendering on different browsers varies by a factor of about 20 times (or whatever factor you want). I sure didn’t know.

And I have a “solution.”

So what is the situation? Consider an actual page from a webapp I’m developing. In FireFox the page loads and renders in something around 0.6 seconds. Safari loads and renders the same page in 12 seconds. This is not a contrived example.

What’s involved on the page? It displays summary information about all of the users of the webapp. The test data has 119 users. It uses [Blueprint](http://www.blueprintcss.org/) and the jQuery plugin [ListNav](http://www.ihwy.com/labs/jquery-listnav-plugin.aspx). I recommend them both, very nice. [ListNav](http://www.ihwy.com/labs/jquery-listnav-plugin.aspx) (check out the [demo pages](http://www.ihwy.com/labs/Demos/Current/jquery-listnav-plugin.aspx)) allows for easy navigation through a long list. [Blueprint](http://www.blueprintcss.org/) is a CSS framework for laying out a page using a grid (check it out, it has [demos](http://www.blueprintcss.org/tests/parts/sample.html) too), handles typography, and generally helps you make a page look decent. Blueprint works with <div>s, and ListNav wraps them up in <ul>s. Each user is represented by five <div>s within a <ul>.

On Safari, by changing the number of <div>s for each user I get:

user < div>s render time
1 0.5
2 2
3 4.25
4 7.5
5 12
6 18
8 32

To cut it short, if I remove the link tag to the Blueprint screen.css file in the header, the page renders almost instantly, even with 8 divs — but it looks like crap. There are a lot of things that are not the problem (I was “busy”, let’s say), and I don’t really want to go into it.

A few moments of thinking… what if I delay the application of the BlueprintCSS file? A little googling and I found some code in a JavaScript Kit tutorial: [Dynamically loading an external JavaScript or CSS file](http://www.javascriptkit.com/javatutors/loadjavascriptcss.shtml), which I simplified to:

function loadcssfile(filename){
  // thanks to http://www.javascriptkit.com/javatutors/loadjavascriptcss.shtml
  var fileref=document.createElement("link");
  fileref.setAttribute("rel", "stylesheet");
  fileref.setAttribute("type", "text/css");
  fileref.setAttribute("href", filename);
  document.getElementsByTagName("head")[0].appendChild(fileref);
}

$(document).ready(function() { var navOpts = { initLetter: 'a' };
                               $('#user-list').listnav(navOpts);

                               loadcssfile("blueprint/screen.css") // use a real URL here
                             });

This is (obviously) in the jQuery document ready function.

And it worked! In Safari. Not so well in FireFox. Sigh. In FireFox, this caused a rendering effect: the unstyled content would flash on the screen before being being styled. So, back to the webapp, and check the user agent, and only do this trick for Safari. Well, hold on. It is actually any AppleWebKit based user agent — OmniWeb screws up too. There’s probably others. Anyway, about 0.3s in Safari, obviously no change in FireFox, and I’m happy enough for now.

It all came down to a single link element in the page’s header.

Written by hutch

December 30, 2008 at 1:24 pm

Annoyed to distraction by Front Row?

Well then, fix it once and for all.

  sudo mkdir /System/Library/CoreServices/JUNK
  sudo mv /System/Library/CoreServices/Front\ Row.app /System/Library/CoreServices/JUNK

or, if you are really in a state:

sudo rm /System/Library/CoreServices/Front\ Row.app

Then kill the already running Font Row.app process.

Gone! For good!

What a relief!

Why you ask? Well, for some reason Front Row keeps getting control of my machine. I don’t know why. But it is very distracting when it happens in the middle of something… wait for the fancy animation, wait for a couple seconds, hit escape or command-esc a couple of times (and if that doesn’t work, put the machine to sleep and wake it up, then try the escape, repeat as needed).

Written by hutch

June 15, 2007 at 10:30 am

Posted in Mac OS/X

You actually can make Mail.app run faster

UPDATE: now we have vacuum mail

So the trick I posted 13 months ago didn’t work for me, though it did for some people.

Here is one that actually does work: A faster way to speed up Mail.app from Hawk Wings.

First off, it is trivial, run this after backing up…

sqlite3 "~/Library/Mail/Envelope Index" vacuum;

from a command line in OS X.

It reduced the sqlite3 DB from 50,760kb to 47,976kb which isn’t a lot, but then that isn’t the point is it?

What it did do was an almost magic speedup of Mail.app’s operation. Opening my inbox used to take 10-15 seconds the first time and about 5 seconds after that. Downloading email took about 1-3 seconds per message. I open my inbox in less than 2 seconds the first time and pretty much instantly after than, I can download email at rate of about 3 messages per second (that’s almost 10x faster).

It is like a new application.

I think I’ve solved my problem :-)

The one-minute UPDATE: and search is actually usable… ah, so this is why people keep saying how great and fast Mail.app searching is….

Written by hutch

March 5, 2007 at 4:08 pm

The Program.exe Problem

The Program.exe Problem

Once again, pleased that I don’t use windows any more.

Written by hutch

February 19, 2007 at 3:37 pm

The iTunes Store, DRM, the Number Five, and Me

Apple’s DRM imposed upon music downloaded from the iTunes store limits the music to playback on five different machines. I have two where I want the music authorised. But recently my PowerBook melted into a puddle of slag, the temporary replacement machine is no longer available to me and I didn’t think to deauthorise it, the new MacBook I purchased to replace the PowerBook went walkies, and the newer new MacBook I purchased is now humming along just fine. Trouble is, I hit my five machine limit on the DRM.

Well, it turns out that once the fifth machine is authorised, a new button appears on your iTunes store account home page “Deauthorize All” — it is not there until the fifth authorisation. If you click that button then all five machines will be deauthorised, and you can then re-authorise the machines that should be.

I don’t like this DRM stuff, for a lot of reasons. At least this relieves one worry.

UPDATE: so can I use this to maybe track down whoever it was that took my last MacBook? Anyone know?

Written by hutch

November 23, 2006 at 10:06 am

Posted in Mac OS/X, Worthwhile

OS X Filesystem Event Tracking

fseventer

Discusses a couple tools that allow you to monitor filesystem events in OS X. It uses the mechanism underlying Spotlight, not Spotlight itself.

Written by hutch

May 6, 2006 at 5:35 pm

Posted in Mac OS/X, Software

Dashboard Widget For Browsing Ruby RDoc

Precision Information Services – Dashboard Widgets

This is kind of cool. It lets you browse Ruby RDoc files in a OS X Dashboard widget.

Written by hutch

February 22, 2006 at 11:37 pm

Posted in Mac OS/X, Ruby, Tools I use

macosxhints – Avoid a security vulnerability in Safari

macosxhints – Avoid a security vulnerability in Safari

UPDATE: Daring Fireball has a nice explanation — isn’t it great that someone takes the time to write this stuff up (unlike me)?

I get a queasy feeling just thinking about allowing a browser to be so ‘helpful’ as to open ‘safe’ files automatically. What’s safe? Why do I need this help anyway? That Safari has this as the default continues to amaze me. I’ve been turning this turned off as long as I can remember.

It seems that Safari has a funny idea of ‘safe’. Apparently shell scripts are ‘safe’. Sure they are. Right. Nothing is safe.

Written by hutch

February 22, 2006 at 11:21 pm

Posted in Mac OS/X

I was 0wn3d

I was 0wn3d

Very funny, but no idea if it actually happened.

Written by hutch

February 14, 2006 at 10:47 am

macosxhints – A possible fix for a slow Mail.app

macosxhints – A possible fix for a slow Mail.app

This didn’t help me. My ‘Envelope Index’ started at 44MB ended at 37MB and it still takes a couple of seconds to read a new message (I’ve got more than 77k messages being handled by mail.app which is pushing its limit I think). After re-indexing a few messages were marked unread that I know I’ve already read, however a few of them I’m quite certain I’ve never seen before. Hmm. That’s not good.

UPDATE: Three or four of those email messages that ‘reappeared’ are important and having missed them is embarrassing. One is from November. From now on, I think this is going to be a regular exercise. Maybe I need a better mail reader (I’m missing Agent from the windows world)

Written by hutch

February 7, 2006 at 10:07 am

Posted in Mac OS/X