Morphic is already frame-rate limitted internally, so it doesn't update
any pixel on the display more often than whatever the frame rate limit
is.  MVC isn't bad at this, either.  So, limitting the frame rate
inside the VM isn't real likely to help.

Also, have you noticed the "defer updates" feature?  This causes
a similar caching effect to the one you describe, but it's not
based on time.  Instead, updates to the screen don't actually get
posted until you call the magic primitive which forces updates.
The benefit is that if several morphs are drawn on top of each other,
then only the final draw commands gets forwarded to the server.

I think the best solution to remote display is to forget about X-Windows
and write a solution in Squeak!  Write a Squeak display server, and 
write a Squeak display client that displays things by talking to a
server.  That is, use the basic X-Windows model, but don't bother trying
to force your stuff into the specific X-Windows protocol.  That
way, you get a cross-platform remote display, and you get to
do it well.

I started an effort at this approach a few months ago, but then got
buried in more important priorities.  I dunno when I'll be able to get
back to it, but would be happy to supply code to anyone wanting to
try and continue it.  I limitted attention to Morphic, and have a
couple of things that might help:

	- basic network protocols

	- a way to reduce "display a paragraph" down to "display
	  these lines with these fonts and these colors".  Otherwise,
	  you have to transmit an entire paragraph, which is a *really*
	  complex data structure


The big things that are needed for anyone who wanted to continue
down this path would be:

	- Handling transformations.  For instance, handling
	  the interior of a ScrollPane that has been scrolled

	- Handling connecting clients to servers.  Right now you
	  have to create and connect a socket by hand; it would 
	  be nice to have some simple menu items to handle this all.



Lex



> 
> A week back I asked about the poor performance of X-Windows updates.
> 
> I was told lots of bits flow across the wire.
> 
> So I looked
> 
> On the mac in my test case of doing 100 Display restore I get 55,320 calls
> to ioShowDisplay and of course to the Mac's CopyBits. Nice but expensive. My
> mac does this in 52 seconds, so I'm getting at least 1000 screen updates a
> second.
> 
> I changed the code to cache updates which I then trigger each 1/60 of a
> second if required. This reduces the CopyBits calls to 2417.
> 
> Now Before I hack the X-Window's implementation I'm wondering if some other
> squeaker has taken this path before?
> 
> PS Lastly I'm actually not caching the incoming bits since I assume we are
> drawing from special object TheDisplay, and I can just cache the region to
> display versus all the bits. I couldn't see a case where the incoming bitmap
> was different, but I am willing to be correct this assumption this early in
> the morning.
> 
> PPS stXPutImage looks like an interesting place to update with some caching
> code eh?
> 
> 
> --
> ===========================================================================
> 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
> ===========================================================================
> 
>