Beta 2 actually slower than beta 1? (Yes, in one way!)

[William Shipley]

I thought I'd let everyone know that, in one crucial way, beta 2 is  
slower than beta 1.  Right now the way we have fixed the  
text-jumpy-when-images-load-in bug is we only process HTML up to the  
first image for which we don't have a size, then we block waiting for the  
server to return us enough of the image so we can figure out the size.

The problem with this approach is, unlike in beta 1, this means that  
images will generally be requested one at a time.  Unfortunately, on a  
decent speed link the slowest part of getting an image is just  
establishing a connection.  On our T1, we still find it'll take about  
half a second to establish a connection with any site, even if they have  
a T1 and can blat the image to us in no time.

Thus, under beta 1 we'd start all the image downloads more-or-less  
simultaneously, which would result in all of those half-second connect  
times overlapping each other, resulting in a total latency of about a  
half second for any page with any number of images.

Under beta 2 we start one image fetch and wait until we've gotten some  
response before we can fetch another, so the (rough average) total  
latency for a page will be about the .5 seconds times the number of  
images.  Actualy download times are the same for beta 1 and beta 2, but  
on a fast network you are more worried about latency than download times.  
 On pages with a zillion tiny images, beta 2 will be a dog on any  
system.  (Note that OmniWeb 1.0 serialized image fetching to an even  
greater degree, so you won't win anything by going back.  In fact, it's  
the deserialization of image fetching that produces the dramatic speedup  
between OmniWeb 1.0 and 2.0 on fast links and fast processors.)

This serialization will be fixed in beta 3; I just thought I'd let  
everyone know that although beta 2 is a lot faster for drawing text and  
parsing HTML, it's actually slower for downloading images.

-Wil