I wonder, if that would really help much. I suppose, quite some CPU cycles get consumed by enourmous amounts of glue code to map RB's event/widget model to the target event/widget model.
I doubt that. The program just doesn't spend enough time in any such glue code to make a difference. Unless they did a really terrible job at RS (which I doubt), the layer between OS GUI API's and an abstract, cross platform API is wide (lots of things to glue) but pretty thin in respect to what has to happen for a given widget.
If not, I really wonder, why RB apps - at least sometimes - feel slow with respect to the GUI, while Cocoa apps generally feel fast.
In my experience when the GUI has been slow it has always been something I was doing behind the scenes. Having said that, if you get enough controls on a form you could get drawing issues with Quartz. I'm guessing the refresh handling in RB may not be as efficient as possible from some stuff I've seen (and some problems mentioned on the list), and Quartz demands every last bit of effort on the part of a developer to run at a decent clip. (While we're at it, for all the talk about optimizing RB...why in heaven's name hasn't Apple optimized Quartz? It is a complete dog and does more to eat up CPU bandwidth than any other single item in the entire OS.) Daniel L. Taylor Taylor Design Computer Consulting & Software Development [EMAIL PROTECTED] www.taylor-design.com _______________________________________________ Unsubscribe or switch delivery mode: <http://www.realsoftware.com/support/listmanager/> Search the archives of this list here: <http://support.realsoftware.com/listarchives/lists.html>
