I have a feeling it probably has a lot more to do with the framework
(though some of the framework is RB code). But you don't have to wait
for RS to get drawing tips - Apple has a whole book dedicated to the
topic:
<http://developer.apple.com/documentation/Performance/Conceptual/
Drawing/index.html>
Frank.
<http://developer.chaoticbox.com/>
On 11-Jan-07, at 5:20 PM, Daniel Stenning wrote:
When these issues get fixed, and it turns out that the solution was
made by
changing the RB code ( as opposed to framework ) it would be a
helpful if RS
posted an article detailing all the techniques used to speed the GUI
performance re redraws etc etc. I'd be curious to know what the
underlying
reasons are and the solutions.
On 11/1/07 21:01, "Frank Condello" <[EMAIL PROTECTED]> wrote:
Quartz is going to slow things down - no question - but the IDE (and
RB apps in general) are _really_ bad at limiting screen updates to
stuff that actually needs to be updated. The window UI editor
refreshes the entire canvas whenever anything changes, and if that
change triggers a control elsewhere to change (like a scrollbar, or a
field in the property editor) then the whole IDE window refreshes.
The fact that the whole window redraws when a single control element
is manipulated makes the IDE slower all around, especially for things
like scrolling through code. The code editor itself has some typing
optimizations, but blank regions past the last line are redrawn on
every keypress, and some actions (like deleting a single character)
cause the whole window to refresh. The framework could use some
serious work in this area - selecting one line in a listbox should
refresh that one line, not the entire listbox, and certainly not the
whole window, but that's exactly what RB does :/
_______________________________________________
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>