caching of screen display...

John M McIntosh johnmci at smalltalkconsulting.com
Fri Dec 3 21:31:49 UTC 1999


> The traffic is not only (mainly?!) depending from the number of updates. If
> you would count the number of *pixels* that are actually drawn you should
> end up with very much the same number. See above, #forceToScreen: is used to
> update the display partially so there is no need to make a roundtrip to the
> server with the full display bitmap (if that's the case it's a bug). A small
> portion does just fine - in fact one could think about forcing the update
> immediately after drawing completed which should make drawing and
> transmission parallel and thus faster.

OK, I did this and ran my morphic test.
For a normal case I got 1919 screen updates across 6,115,757 pixels, or
about a 56 pixel square updated for each update. Now If I change
MinCycleLapse to 250 then we get 1165 updates for 5490835 pixels, or a 69
pixel square.

Less updates and roughly the same amount of data moved as Andreas pointed
out, so win win.

Now for my deferred VM at 250 millisecond delay I get 247 updates, but it
moves 16,669,139 pixels or a square of 260 pixels. More data, less updates.

The trade is data movement versus latency in doing the x-windows call for
remote servers.


PS I'm going to validate that a 3.6 inch square is reasonable for my update
and that it encompasses the two morphic that move... Seems larger, perhaps
I've a bug...


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