The Widget Maker's Prime Directive

by Joshua Scott Emmons

dashboard.png

Don’t let their small size fool you, Dashboard widgets are surprisingly CPU hungry. Take each widget’s intensely graphical nature and penchant for polling and parsing files from the internet. Add to this Dashboard’s slew of special effect and the fact that your average user keeps 5 or more widgets running at a time, and it’s not hard to arrive at a resource situation that can make the fans on your G5 kick up in anticipation.

But that’s ok, because these processor cycles are only used when Dashboard is activated. As soon as your widgets fade away into their OpenGL-accelerated purgatory, their resource usage drops to zero and your full-sized applications have the undivided attention of your CPU again. Right?


8 Comments

Craig
2006-07-12 10:56:59
Um.. why did your RSS feed shown the entire article? I thought RSS was to show a simple feed?
Joshua Emmons
2006-07-12 11:10:36
I thought RSS was to show a simple feed?


Actually, I think you'll find RSS only promises simple syndication. It makes no claims as to the complexity of the syndicated content ;-)


But to answer your question, it's a policy thing. O'Reilly has made the decision that the entirety of its articles should be included in the RSS feed. I think this is a smart move as most RSS readers (Safari included) allow you to define how much of the feed's articles you want presented to you. If you only want to see the first paragraph of each article, dial this value down. That way you're happy without messing things up for the next person who wants to read the entire article in their RSS browser.


But as I've said before, if this imposes some burden on you and you think it should be changed, let me know. I'll take the issue to my web-master overlords for consideration.

rampancy
2006-07-13 06:53:36
Thanks for the insightful article - I hope you decide to follow this up with that future article you mentioned detailing widgets and RAM usage...
Orin
2006-07-15 20:58:48
...it is seldom the case that more than one web page is displayed at a time. And it's even more rare that the entirety of a page is shown by a browser (unless it's a very short page or a very large screen). Finally, a browser is not expected to be "always on". Most users look at a page and then close their browser until they need to look at another one.


While I see the need to compare .gif format as used in the two different situations, and I find your dashboard solution ituitive, I can't be the only person who finds these particular assumptions utterly untrue. I almost always have multiple tabs open, and I surely don't just close the whole browser when I'm done looking at one page. And while it is rare for a browser to have loads of animated .GIFs visible and active, it's certainly not unheard of.

Joshua Emmons
2006-07-15 21:45:21
I almost always have multiple tabs open


Which is why I say, "it is seldom the case that more than one web page is displayed at a time." (bold added). If you have twenty tabs loaded, it is still the case that only one of those tabs can be displayed at a time. In Safari, .gifs only consume CPU when they are actively being displayed — that is, when they are on the currently selected tab.


I surely don't just close the whole browser
I'm not suggesting that people close the whole browser. They don't do a Safari->Quit after every web page, for example. But the average user does either close or minimize the browser window when done looking at a page. The reason is simple. Most people are confused by by having too many open windows on the screen. They habitually close or minimize anything they are not working on to "reduce clutter" (unless it's gmail, which doesn't contain any animated .gifs anyway). As developers, we're used to having kajillions of windows open. And we often have large/multiple screen's worth of real estate to spread things out upon. And so I don't doubt that you might leave your browser windows where the lie. I merely suggest you are not representative.


it's certainly not unheard of
Though I'll bet you betan dollars that you close that window as soon as you're done looking at it. ;-)

Butler
2006-08-24 09:08:25
Hi. Thanks much for your article. I am not a widget developer but have some web dev experience though more often I work with sound in some capacity. I wondered if it is possible/advisable to rewrite widgets developed by others once they are installed? Of course one of the most useful Widgets I have installed, an audio-oriented calculator, also apparently fails to stop processing... or maybe I should just forward the developer your article. Thanks again.


CDB

Andrew Purvis
2006-10-17 16:13:57
I wondered if it is possible/advisable to rewrite widgets developed by others once they are installed[.]


This is a simple question with a simple answer: sometimes. Addressing the question purely from the perspective of possibility, you can modify any uncompiled code you get. This is a benefit for users, but it is seen as a liability by developers who wish to protect their code with more than a license statement (my experience is that those developers, when scripting rather than writing in compiled languages, write some of the worst code out there).


This raises another key question: Do you have the right to modify someone else's work? Strictly speaking, once the code is sitting on your machine, you have the right to do whatever you want to it, so long as the modified code never leaves your custody. Don't go sending a widget to a buddy after you have modified someone else's code. You should comment any changes you make, and if they are noteworthy improvements, contact the widget's creator, if possible, and help out. Most free widgets are GPL or Creative Commons, and you can earn yourself a credit in someone else's code, which, while not top billing, doesn't suck.


See? I told you it was simple.

ben
2007-04-21 00:45:28
please is yahoo! widgets save or is it ok?