`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
|