Alan,

I've never had the sense that there would be good interaction until all the images were loaded. In the case of the space invader project, there are some 40 separate pictures to retrieve - all done at higher-than-UI priority. The real killer timewise is that each of these pictures gets written to a file and runs afoul of the garbage collection we inflict on testing for the existence of a file. These gc's consumed 30 of the 50 seconds it took me to retrieve the project from start to finish and virtually all of the time once the project was visible, but not responsive.

Cheers,
Bob

On Sun, 4 Nov 2001 10:23:25 -0800 Alan Kay <Alan.Kay at squeakland.org> wrote:
>I'm not sure why they take so long in this particular case. The 
>process is just like that of HTML pages with embedded images. The 
>"text" of the page is sent separately, and then the images are sent 
>as they can. Usually, the system allows good interaction with the 
>base info while the images are being sent. In this case the Geemail 
>is essentially noninteractive until all the images have been sent -- 
>and this is a bug. Perhpas Bob Arning, Mike Rueger, or Andreas can 
>give us some help here.
>
>Cheers,
>
>Alan
>
>-------
>
>At 9:41 AM +0100 11/4/01, Karl Ramberg wrote:
>>Alan Kay wrote:
>>>
>>>  John and Karl --
>>>
>>>  The blurry images are ones that have not yet been downloaded
>>>  automatically from the server.
>>Explains why they are hard to make sence of.
>>
>>
>>>  What is the advantage of putting a Geemail in a window? -- it already
>>>  has scrollbars. (You may not think so because they are very much
>>>  delayed in appearing because of the slow picture download, but a
>>>  mouseover the Geemail will eventually make them appear.)
>>
>>Why do the images take so long ? Is each image gzipped by it self
>>and upploaded ? Could it speed stuff up if they got zipped in a
>>archive with the relatively new archive zip tool so the
>>time wasted on each part got eliminated ?
>>
>>Karl