Palm WebOS Dali Clock

Ladies and Gentlemen,

I have ported Dali Clock to the Palm Pre.

Truly, this program will last forever. If I have anything to say about it.

It's a little slow. It is, in fact, a bit slower than the PalmOS "Classic" port. And, for that matter, the original Xerox Alto version. Why, you may ask?

Because this port is written entirely in Javascript.


Let's take a moment to ponder this version and the Alto version, and just how many wasted instructions, layers of abstraction, frameworks, toolkits and outright cruft have gotten between the algorithm and the frame buffer in the intervening twenty-seven years. This program makes my phone hot. Hot, I tell you.

Oh. The huge manatee.

Tags: , , , ,

59 Responses:

  1. lionsphil says:

    Welcome to the future! The web is the next desktop lol.

    Is it too late to go back in time and kneecap whichever smartarses thought that making a hypertext viewer have Turing-complete scripting ability was a good idea?

  2. pikuorguk says:

    Aren't there any hardware/software designers left that want to build devices that run efficiently?

    I thought we'd all decided scripting languages were slow and not worth using for serious computational stuff?

    Oh yeah... I forgot, our computers got fast enough that we could pull this mad stunt off.

    Think of all those wasted CPU cycles the next time you watch your phone redraw its tiny screen. It's wrong when 10 year old 8bit computers are more responsive than current generation machines.

    • korgmeister says:

      I gather from this that the Palm Pre is a departure from Palm's traditional championing of lightweight, efficient platforms?

      How disappointing.

      • lionsphil says:

        The clue is in the name "WebOS".

        The Web is a crap hypertext system, an even worse thin-client system, and quite possibly the worst concievable graphical application platform. At least use of it on full-size computers has the excuse that it's vaguely zero-install, cross-platform, and loads from a remote server, so the publisher can enforce obsolescence. For a locally-installed, device-specific (which it will be, if it's to make use of native human interaction capabilities like tilting, touchscreens, or trackballs) program, IT ARE MAKE NO SENSE.

        But, hey, it's like totally 2.0, man!

        • korgmeister says:

          Lame, looks like the iPhone still remains the "Platform which most closely resembles how I think computing should be".

          This makes me sad.

        • jayp39 says:

          As somebody who works at a company developing apps for all the major platforms including iPhone, Blackberry, Android and Windows Mobile, WebOS has the distinct advantage of being the easiest to develop for out of all of them (at least for our goals). In the long run I think that means that the Pre will end up with more apps than any other platform, which will be Very Good for Palm.

    • landley says:

      > Aren't there any hardware/software designers left that want to
      > build devices that run efficiently?

      Yes, we're called "embedded developers", we do things like BusyBox, and as far as I can tell we're all slowly migrating to the iPhone.

      > Think of all those wasted CPU cycles the next time you watch your
      > phone redraw its tiny screen. It's wrong when 10 year old 8bit
      > computers are more responsive than current generation machines.

      Except that CPU cycles use power which eats battery life, which is a big deal in the embedded world.

      By the way, if you think Moore's Law will give every device so much memory and CPU you won't have to care, you haven't heard of "disposable computing", where Moore's Law someday makes a small but usable amount of computer power so cheap you can manufacture millions of them to be _thrown_away_.

      Imagine the day when electronic paper's patents expire and you walk down a cereal aisle full of boxes of captain crunch that change what's displayed on the front of the box every 30 seconds. If a usable computer can cost less than the "free toy inside" and run for months off of a blinky-LED style watch battery, or perhaps they'll eventually get this stuff work:

      Yes, they'll have to work out the environmental kinks of throwing them away, but regulation will take a while to catch up, and if you make 'em really really small the materials used in them become rounding errors for the rest of the packaging...

      • mdl says:

        Huh? Busybox isn't what I'd use as an example of something good, I'm not sure what you're getting at with the remark about CPU cycles because the entire point is that they're being squandered nowadays on largely pointless abstraction, and oh boy--I sure can't wait for the era of such waste and societal decadence that Cap'n Crunch boxes are animated. Maybe when I look down while I'm taking a dump in my own home there can be some sort of advertisement in there too.

  3. gths says:

    I thought xdaliclock was the coolest thing to ever hit a computer screen when I was 18 years old (well, that, and a few other things). It was like Whoa The Numbers Are Melting How Cool Is This?

    I'm nearly twice that age now and it's still pretty Whoa.

  4. jered says:

    Since it's JavaScript, do you have a version that we can view here in the comfort of our Firefox, Chrome or Safari?

  5. dojothemouse says:

    Using anigifs instead of canvas might up your framerate. But I guess that's not the point of dali clock.

    • jwz says:

      Sadly, it has to do transitions between arbitrary numbers (when switching out of date-mode, or when machine load causes it to have to skip a second or two to keep up.) I addressed this in the X11 version, when in 1991 I was trying to make the animation run sufficiently fast when doing uncompressed X protocol to a remote NCD X terminal running over a 14.4kbps modem connection (which is what I had at home), and the number of cached intermediate frames was vast. I cached [1-9]→0, [1-8]→[2-9], [1-7]→[3-9] and 9→1.

      Also, that's cheating.

  6. loic says:

    Of course, now you have a version that runs on iPhone and Android too, and any platform that has a modernish browser. We've finally got a universal application platform. It's just a pity that it kind of sucks.

    • jwz says:

      I got about halfway through a "real" iPhone port of Dali Clock (porting the Cocoa version) and gave up because it was just too much of a pain in the ass. See, iPhone doesn't run Cocoa, it runs something a lot like Cocoa, in that it's a GUI written in Objective C, but the libraries are completely different in arbitrary ways. I mean, you wouldn't want color allocation to have the same API on both a Mac and an iPhone, right? That would be crazy talk.

      It's in the source bundle if anyone wants to finish it.

  7. evan says:

    Since everyone else is too busy feeling superior, I'll throw in that I'd be curious to see a profile of what makes it slow. The pre uses v8 so the JS is JITting to native ARM code. The rendering is WebKit which is fast and light for what it does. Just guessing, but it could be JS→canvas overhead or it could be drawing overhead. Depends on how you're implementing the morphs -- if it's as a pixel buffer, then yeah, pretty slow.

    I support the above request for a web version. I've got a friend who works on this sort of stuff for Chrome who would probably poke at it a bit.

    • haran says:

      Just modified enough to make it run.
      Works on Firefox and Chrome.
      Haven't tested anywhere else.

        • This makes my dual-core laptop speed up its fan. Fuck JavaScript. :|

        • dzm6 says:

          For whatever it's worth this runs on a 1st Gen iPod Touch with v3 OS' Safari.

        • djquack says:

          Thank you, sir.

        • graydon says:

          Runs at a decent clip in a firefox 3.5 nightly, but we have a JIT now too. I'll throw this into the performance suite we're fleshing out in the next few months, along with the various emulators, raytracers and other gewgaws.

          Always good to keep the needs of real eyecandy in mind when tuning.

          • haran says:

            It seems to run moderately well on Firefox 3 as well.
            On the other hand this little thing I slapped together:

            has a noticeable speed difference between Chrome and Firefox3. Although it's possible that I'm doing something wrong somewhere.

            Turning off firebug and running in safe-mode didn't make it any faster.
            I haven't tried it on Firefox 3.5 with their new JS engine though.

            • graydon says:

              Could make a difference. I just tried and it seems a bit faster with the JIT enabled, but you don't have a framerate count or anything, so it's hard to tell. I'm not surprised if chrome (or safari) still beats us on a given page. They've been doing excellent work too. Yay performance competition! Everyone wins.

              The engine in 3.5 is very ... difficult to make predictions about the performance of, at this point. When it guesses right and hits peak speeds, it can beat v8 and sfx. It has a more aggressive type-specialization and inlining system. When it guesses wrong, it has more work to undo and subsequently gets hurt worse. V8 and sfx tend to sit at a more steady state, benchmark-to-benchmark; amusingly sfx is usually on top, and it isn't even a JIT, just a context-threaded interpreter with a lot of smart design choices.

              But there are a number of knobs to turn (and auto-knob-turning algorithms to stabilize). We think we have a lot of room for performance improvement. This release was more about getting it working.

      • jwz says:

        Thanks for that.

        I thought about trying to abstract it out so that the clock code was just a subroutine of the WebOS code, but it seemed like kind of a rathole...

      • lionsphil says:

        Works in Opera 9 too, so looks like you've got it right. (Doesn't in MSIE 7, but does that even support canvas malarky?)

    • gryazi says:

      Already mentioned cluecc but I did get off on a tangent and managed to track down some results for it with v8 here.
      Chances are the clue output is not really 'optimal' vs. hand-targeting js, but the 10%-of-native result is an interesting... "win-to-fail ratio."

      It's hard to find Whetstone results for the CPU in the Pre, but if the results table here has anything to do with anything (see also some phone review sites publishing Dhry and Whet figures for smartphones), current-era smartphones are performing somewhere between a 386 and Pentium 133 [although this is with the phone OS running]. So 10% of that doesn't leave much... maybe only somewhere between a MicroVAX and a Cray 1. [Yes, Whetstone is completely the wrong benchmark to use, but it's all I have the native-vs.v8-js results available for.]

      The point, if there is one to this post, would seem to be that there's room for improvement and/or that js maybe isn't the best 'universal VM' for applications like this (vs. something like llvm, the forgotten Tao products behind the Amiga Inc. pipe-dream, or a rare instance of Java working properly). But one would think that, in theory, native js should be able to come up a little higher than the 10% penalty, so the other problem is the lack of a fast path (or optimization therefor) to get graphics onto the screen.

      What's horribly wrong is not so much having abstraction, it's that the modern attempts at abstraction are benchmarking far worse than LISP. (So did LISP get something right, or is it just that it takes 20+ years to properly optimize that level of abstraction?)

      • graydon says:

        You forget that due to relativistic social and economic forces at work in the expansion of computing, the state of the art in deployed computer science is actually traveling backwards in time. It takes enormous effort just to slow the reversal down.

        If you want a technical perspective: the nature of JS (mostly all the loose binding) makes JITs for it extremely speculative; they have to do a lot of guesswork. When your guesses turn out right, you can drive the speed up pretty high. When they turn out wrong, you have to throw out guesses and adapt very fast (or at least try to limit the damage).

        Also -- quite independent of the language -- the layers of software between the JS engine and the framebuffer are substantial these days. Takes a lot of carving to get a fast path all the way down.

        There remains quite a bit of room for improvement in the JS engine arena though. There's active competition now, at long last. The next few years will see a lot of field-tuning and benchmark-wars in this area.

  8. gthing says:

    Awesome. I believe this makes you the largest WebOS develop in existence.

  9. jsbowden says:

    I've been using xdaliclock for almost fifteen years now, and I find this both awesome and hilarious.

  10. cdavies says:

    Here, I've written the DaliClock family a bastard cousin who is never invited to reunions, an S60 3rd edition port.

    (Also, obligatory video is here, it's a bit loud because the phone speaker was a bit too close to the camera mic. might want to turn the volume down a bit before playing.)

    There's still a couple of problems to sort out, it doesn't sync too well with clock time at the moment, skipping about one second in 15. Plus there's a noticeable redraw at the end of each cycle when it refreshes the screen. But still, not too bad for a couple of hours work.

    I'll probably sort those things out tomorrow and put some source and binaries up.

    • haran says:

      Ha, I was thinking of doing an S60 port.
      Can you release the source?
      I'd be interested in seeing how it works..

  11. not_art says:

    "Truly, this program will last forever. If I have anything to say about it."

    All hail the Dali Clock. Never shall it cease to morph. Never!

    When I have to reinstall Debian because I've managed to break it by trying out stupid things (again), "aptitude install xdaliclock" is right after getting X up and running (yet again...). Thank you again, JWZ.