`just slow it`....

John M McIntosh johnmci at smalltalkconsulting.com
Thu Feb 8 05:28:47 UTC 2001


>
>As I recall, the Sunrays rely on the network to display every pixel. 
>While the Sunrays are truly wonderful in regards (particularly the 
>capacity to copy images to plural terminals identified by 
>smartcards. they may not be ideally suited for or matched to the 
>particular manner with which your VM is redrawing the screen.  Does 
>MVC work substantially better through the sunray?
>


A while back I posted some patches on my source code page. Now this 
hasn't be updated for awhile, but you could take it and see if it 
makes any difference for you. Beware the change set might require 
modification to live in a 3.0 image.

http://www.smalltalkconsulting.com/papers/tipsAndThoughts/codeFragments.html

See the part about

4) Squeak deferred screen updates. (a change set)

(some thoughts on MinCycleLapse first)

To implement this change you must file in this change set, then 
create a new interp.c, then build a new VM.

When Squeak alters it's screen image it is writing to an internal 
bitmap. From time to time the VM asks the platform specific code to 
copy those bits to the actual BitMap that is the window. I have an 
example where 100 screen restores causes 41,168 copies to occur, well 
over 1000 updates per second on my Mac. Cool but a problem occurs 
when using Squeak as a X-Client were the X-Server is remotely 
located. Then those thousands of updates take a long time to do since 
network latency plays a big part in the equation. In fact my friends 
tell me they just watch the screen paint, slowly...

My solution is to change the VM, by changing the Squeak Interpreter 
of course. My change focuses around alter the original calls to 
ioShowScreen to call deferShowDisplayBits. My modified routine is 
responsible for remembering the largest enclosing rectangle, and 
tracking how long a screen update has been deferred for. If it is 
called and the time limit has been exceeded then the original 
ioShowScreen is invoked using the rectangle that should encompass all 
required drawing.

To ensure pending screen updates occur in a timely manner, I altered 
checkForInterrupts to ensure if an update is pending then an update 
is forced once the timer expires.

For my previous example we can reduce the actual number of bitmap 
copies to 1,885 if you set the update frequency to 16 milliseconds, 
or 60 times a second.

Note in order to tell the VM about the update frequency I created a 
method SystemDictionary>>delayScreenUpdatesBy: Use this method to set 
the defer delay to zero to get original behavior, otherwise use a 
number that gives good performance, but doesn't impact animation. You 
must set this value each time you restart your VM since the VM does 
not remember it from execution to execution.

{Of course a preference using the perference framework will allow you 
to setup a preference and have that executed at image startup time 
now}

-- 
--
===========================================================================
John M. McIntosh <johnmci at smalltalkconsulting.com> 1-800-477-2659
Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
===========================================================================
Custom Macintosh programming & various Smalltalk dialects
PGP Key: DSS/Diff/46FC3BE6
Fingerprint=B22F 7D67 92B7 5D52 72D7  E94A EE69 2D21 46FC 3BE6
===========================================================================





More information about the Squeak-dev mailing list