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>
