Hi john

Have you ever noticed that sometimes the complete windows get redrawn  
extremely slowly on your mac?
We noticed with nathanael that this was related with the use of  
different processes.
I tried several times to reproduce it without success. I noticed that  
this behavior happens
when I get a deprecated method called and once I click proceed, then  
the redraw gets really slow.

Stef



On Thursday, July 3, 2003, at 08:52 AM, John M McIntosh wrote:

>>
>> While it's neat to think about where these calls are coming from, IMHO
>> it doesn't seem valuable to try and remove them. If you want to speed
>> things up, try reducing the number of redundent things that get  
>> redrawn
>> for common operations in Morphic. :)
>>
>>
>> Lex
>>
>
> Well it's idle curiosity, and fiddling with Apple's new set of  
> hardware analysis tools.
> That pointed to the fact we were doing a millisecond clock check every  
> 2ish milliseconds from
> the Smalltalk code when the system is IDLE. If it's idle why is it so  
> busy....
>
>
> PS part of this was discovering how to tune the Mpeg plugin to take a  
> test case from
> 49.38 to  69.67 frames per second, that is quite a major change (gcc  
> 3.3 & some code changes) it was
> not at all obvious from earlier codewarrior based tuning tools.  So  
> it's not all wasted effort.
> and I did learn for the mpeg plugin the number of syscalls required to  
> do disk io is low, a
> question in the  past which requires no further thought.
>
> Funny you should mention Morphic drawing
>
> As part of my work I did insert a Transcript print into the ioprocess  
> loop. That results in a slowdown
> of the entire drawing cycle and you get to observe some *very  
> interesting* drawing behaviour.
>
> I've also noted that in
> BitBltSimulation>>copyLoop you've got.
>
> 				2 to: nWords-1 do:
> 					[ :word |  "Note loop starts with prevWord loaded (due to  
> preload)"
> 					self dstLongAt: destIndex put: prevWord.
> 					destIndex _ destIndex + hInc.
> 					prevWord _ self srcLongAt: sourceIndex.
> 					sourceIndex _ sourceIndex + hInc]]]
>
> This resolves  (with my previous copyloop code change to)
> 					for (word = 2; word <= nWordsMinusOne; word += 1) {
> 						longAtput(destIndexLocal, prevWord);
> 						destIndexLocal += hInc;
> 						prevWord = longAt(sourceIndexLocal);
> 						sourceIndexLocal += hInc;
> 					}
>
> mmm which really implies you want to move a bunch of words from  
> sourceIndexLocal to destIndexLocal assuming hInc is 4 with special  
> care for the first and last words based on masking bits.  So with the  
> above C, does
> your compiler really optimize the assembler instructions correctly to  
> make it happy?
>
> --
> ======================================================================= 
> ====
> John M. McIntosh <johnmci at smalltalkconsulting.com> 1-800-477-2659
> Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
> ======================================================================= 
> ====
>
>