Dashboard: konfabulator fights back.

2

Comments

  • Reply 21 of 51
    the cool gutthe cool gut Posts: 1,714member
    Quote:

    Originally posted by John

    Konfab doesn't have any "candy effects" Sure, it has composited windows, but every window is composited, and compositing is already GPU accelerated by Quartz Extreme.



    There's more to it than that, Konfab has a pretty bad reputation for being a resource hog, depending on the widget you use.



    I don't understand how the folks at Konfabulator can build something around Apples own style and ideas, and then accuse Apple of ripping them off. And the coolest thing about Dashboard isn't even in Konfab - the ability to use a hot key to fade in all the widgets.
  • Reply 22 of 51
    johnjohn Posts: 99member
    Quote:

    There's more to it than that, Konfab has a pretty bad reputation for being a resource hog, depending on the widget you use.



    Again, what makes you think Dashboard will be better in this regard? I'm not claiming anything one way or the other, I'm just asking why everyone seems so sure that similar widgets will have wildly different CPU and memory usage behaviors in Dashboard vs. Konfab.



    Quote:

    the coolest thing about Dashboard isn't even in Konfab - the ability to use a hot key to fade in all the widgets.



    The "Konspose" of Kondabulator feature is similar in that it brings all the widgets to the front and fades the background. Put them all at desktop level and they won't interfere with anything until summoned (even though you may still be able to see some of them...which may be considered a feature for certain kinds of widgets).
  • Reply 23 of 51
    hmurchisonhmurchison Posts: 12,145member
    Well put it this way.



    If Dashboard gadget suck up RAM and CPU when they are not on screen then I won't use them. I already know Konfabulator is a pig because of its runtime environment. So Dashboard can be no worse the Konfablutor in my eyes.
  • Reply 24 of 51
    hobbeshobbes Posts: 1,252member
    The Konfab / Dashboard resources question seems simple enough to answer, or at least get a sense of an answer... if someone with access to the Tiger seed is willing to chime in with a report. Anyone out there?
  • Reply 25 of 51
    johnjohn Posts: 99member
    Quote:

    If Dashboard gadget suck up RAM and CPU when they are not on screen then I won't use them.



    Why do you think that "being on screen" makes such a big difference? If a widget is polling a web site periodically to get stock prices or the weather or whatever, it's going to do so whether or not it's visible, so that when it does become visible it has the correct stock prices or the weather.



    Maybe a widget with constant animation will take less CPU if it isn't visible, but if you are running such an annoying widget, you deserve what you get, IMO



    As for memory usage, it's pretty much the same for visible and invisible windows (+/- compression, but visible windows can be compressed too--check QuartzDebug)



    Finally, as for the runtime, WebKit is not small. Of course, if you're using Safari, you're running it already anyway, which helps. But the Konfab runtime on my system has an an RPRVT of 1.68M. It's going to be hard for WebKit to beat that by much.



    IMO, the only real hope for a big difference in CPU or memory usage is if Dashboard isn't running at all until the first time you call it up. But in that case, you can also simply bind Konfabulator to an F-key not run it until you need it to get the same effect.
  • Reply 26 of 51
    kerbkerb Posts: 4member
    will the current G4 iBook support CoreImage?



    and if not how will Dashboard run?
  • Reply 27 of 51
    squozensquozen Posts: 66member
    Quote:

    Originally posted by Hobbes

    The Konfab / Dashboard resources question seems simple enough to answer, or at least get a sense of an answer... if someone with access to the Tiger seed is willing to chime in with a report. Anyone out there?



    Sure. The default widgets on the Tiger build I played with ate 6Mb each. They seemed to use virtually no CPU at all when displayed and none when they were hidden. I assume the more complicated widgets to come will eat more, but from what I've seen it's far less taxing than Konfabulator.
  • Reply 28 of 51
    mattbmattb Posts: 59member
    Quote:

    Originally posted by John

    Again, what makes you think Dashboard will be better in this regard? I'm not claiming anything one way or the other, I'm just asking why everyone seems so sure that similar widgets will have wildly different CPU and memory usage behaviors in Dashboard vs. Konfab.



    Here's a quote from developer John Gruber:

    "Konfabulator is not a lightweight or small-footprint environment ? every Konfabulator widget runs as a separate process, with its own runtime environment in memory. Most Konfabulator widgets use more memory than typical full-blown Mac OS X applications. Not just Konfabulator as a whole ? but each widget. Install it, fire up Process Viewer, and see for yourself. (Ironically, the Konfabulator ?CPU Portal? widget seems to leak memory.)"



    For more, see: http://daringfireball.net/2004/06/da...s_konfabulator
  • Reply 29 of 51
    woosterwooster Posts: 27member
    Quote:

    will the current G4 iBook support CoreImage?



    and if not how will Dashboard run?



    CoreImage is only used for the watersplash-effect when a new widget is activated. You can use Dashboard on any graphic-card shipped but will not get the above mentioned effect.
  • Reply 30 of 51
    krispiekrispie Posts: 260member
    There's an excellent debunking of Gruber's piece in a recent MDJ. (macjournals.com) though you'll have to pay to read it.
  • Reply 31 of 51
    Care to elaborate on what was debunked? Or copy and paste the whole article?



    I'd be very surprised if his argument was taken apart as he was merely popping the balloons of a bunch of (how can I put this?) whining, ignorant bitches.



    I don't agree with everything that he writes but on this point his 'opponents' were barely rational, spouting knee-jerk reactions based on nothing more than screenshots and misplaced outrage. It would have been near miraculous if they had accidentally made a point that was actually correct.
  • Reply 32 of 51
    Sorry, but that opinion piece by daring fireball was nothing but slight of hand in regards to Konfab/DB.



    Who cares where certain, very basic, ideas may have originated, it;s how they are executed that counts. We could go back in time and say how this and that just copied from x, y, or z. But what Apple have done, is to wholesale copy and jump onto a bandwagon that the likes of Konfab. and Desktop X (Windows) made popular.



    Look, if these new programs hadn't have become popular, do you thin Apple would be introducing something like them now? Nah, don't think so. The popularity of Konfab and the like is what drove Apple to do this.



    I don't give a toss if way back in time Apple had some crazy idea of desktop accessories, they were nothing. Now we see Apple introducing something that hops onto this trend, introduces something that resembles konfab. The style, the idea, and the fact that konfab did it, in this manner, before Apple.



    Quote:

    Originally posted by stupider...likeafox

    Care to elaborate on what was debunked? Or copy and paste the whole article?



    I'd be very surprised if his argument was taken apart as he was merely popping the balloons of a bunch of (how can I put this?) whining, ignorant bitches.



    I don't agree with everything that he writes but on this point his 'opponents' were barely rational, spouting knee-jerk reactions based on nothing more than screenshots and misplaced outrage. It would have been near miraculous if they had accidentally made a point that was actually correct.




  • Reply 33 of 51
    mattbmattb Posts: 59member
    Quote:

    Originally posted by sanity assassin

    Sorry, but that opinion piece by daring fireball was nothing but slight of hand in regards to Konfab/DB.



    Who cares where certain, very basic, ideas may have originated, it;s how they are executed that counts. We could go back in time and say how this and that just copied from x, y, or z. But what Apple have done, is to wholesale copy and jump onto a bandwagon that the likes of Konfab. and Desktop X (Windows) made popular.




    Konfabulator looks like Desktop X too. In fact anything using non-rectangular windows and trying to mimic other real life devices like clocks, etc will look like this. If a developer was given a modern operating system and told to port Desk Accessories to it with no prior knowledge of Desktop X and Konfab I suspect it would look surprisingly similar. Using a compositing layer is totally obvious if you have one available. Even if Apple should be paying "we ripped you off" money to Arlo and Perry for Konfabulator then surely Arlo and Perry in turn should be paying money to the Desktop X developers and they aren't doing that as far as I know.



    All that aside though, you're right, it is how they are executed that counts and from all accounts in the areas that matter, i.e. the runtime, Dashboard appears to be very different to Konfabulator. I'm more than willing though to see what was debunked in MDJ.
  • Reply 34 of 51
    tuttletuttle Posts: 301member
    Quote:

    Originally posted by sanity assassin

    The popularity of Konfab and the like is what drove Apple to do this.





    Evidence for that assertion?
  • Reply 35 of 51
    johnjohn Posts: 99member
    Quote:

    Here's a quote from developer John Gruber:

    "Konfabulator is not a lightweight or small-footprint environment ? every Konfabulator widget runs as a separate process, with its own runtime environment in memory. Most Konfabulator widgets use more memory than typical full-blown Mac OS X applications.



    I think Gruber was looking at VSIZE or something equally misleading. I have Konfabulator and can look for myself at the memory usage. I posted some numbers earlier. None of the widgets I have open right now (iTunes Bar, Weather, To Do) are using any CPU (0.0% in top).



    As for running each widget in separate processes, someone with Tiger can comment on whether or not Dashboard widgets are separate processes, and what their memory footprints are like.
  • Reply 36 of 51
    krispiekrispie Posts: 260member
    Quote:

    Originally posted by stupider...likeafox

    Care to elaborate on what was debunked? Or copy and paste the whole article?



    As it's a pay-for service, I don't think I can really post it here any more than I can post pirated songs here.



    It's a very long and detailed piece - with the high quality analysis one expects from MDJ. It's in the 21st July edition.



    You can get a free trial sub from macjournals.com



    (I have no connection with MDJ other than as a subscriber - but I really really recommend it if you can afford it).
  • Reply 37 of 51
    Quote:

    Originally posted by Tuttle

    Evidence for that assertion?



    Observation of the developing programs. If program x exists for a certain amount of time and is popular; then program y comes along in which the implentation is virtually the same. Then it seems logical that program y's authors have based their idea n existing lines, but like most developers, they implement a slight twist to things.
  • Reply 38 of 51
    jmoneyjmoney Posts: 133member
    I think as opposed to trying to "fight the big Apple", if I were him I would offer my services to Apple and see if they'd pull me on to help oversee the project. Or see if he could sell some of his widgets so they could "improve" on them or whatever..



    It's all salmon in the fish game.. marinate bitches..
  • Reply 39 of 51
    cooopcooop Posts: 390member
    Quote:

    Originally posted by sanity assassin

    Observation of the developing programs. If program x exists for a certain amount of time and is popular; then program y comes along in which the implentation is virtually the same. Then it seems logical that program y's authors have based their idea n existing lines, but like most developers, they implement a slight twist to things.



    Yes, but while Dashboard may be similar to Konfabulator in concept, their implementations (underlying codebase) are quite different. And while the two may look similar, Apple has provided a number of "twists" on the backend. Apple's inclusion of Webcore and Exposé are two extremely significant alterations to the widgets concept and should not be overlooked. (Konsposé or whatever the hell it's called was introduced well after Arlo Rose was aware of Dashboard). In the end, while it may initially seem like Apple is exercising its monolithic/monopolistic presence to stifle the "creativity" of smaller developers, looking a bit deeper reveals that Apple is doing nothing more than extending the concepts and "goals" of the decades-old desk accessories and providing several, dare I say it, innovations along the way. From my point of view, about the only things Dashboard rips off from Konfabulator are the crappy widget interfaces.
  • Reply 40 of 51
    Quote:

    Originally posted by sanity assassin

    If program x exists for a certain amount of time and is popular; then program y comes along in which the implentation is virtually the same.



    I'm beginning to think people posting in this thread haven't read the Gruber piece. You're offering opinions that were popular before people knew what the hell Dashboard actually was.



    Now that people know better, no-one is claiming the implementation is virtually the same, and if you are then you'd better justify that comment.
Sign In or Register to comment.