From: Francis Hwang <sera@...>
Date: 2005-04-16T22:21:38+09:00
Subject: Re: What's beyond Rails?


On Apr 16, 2005, at 2:49 AM, jason_watkins@pobox.com wrote:
> Still the wrong model. If you were providing Photoshop as a web
> application, presumibly you'd be providing storage on the server
> itself.
>
> So after your guassian blur filter runs, the app only need to send you
> back a ~1000x1000 pixel image that reflects the portion of the image in
> display.

Okay, but that portion itself represents a significant enough time lag 
to cause a serious problem for the person who relies on Photoshop to 
get work done. A 1000x1000 image, at 24-bit color, is about a 2.9 MB 
image. My downstream is 5 Mbps which means that under peak conditions 
it takes about 0.48 seconds to download the view. Not the entire image, 
just the view itself.

Also, 1 million pixels is a fairly conservative estimate for the size 
of the view you have to deal with. On a full-screen image on my paltry 
17" monitor that's about what I get. Apple's 30-inch cinema display 
gives you 4 times that many pixels.

I guess the point I'm trying to make is that although it's easy for me 
to see certain apps move to web-land, Photoshop isn't one of them. When 
you're a serious Photoshop user, everything you do sloshes around a lot 
of data, so the network itself becomes an obstacle, and until you solve 
the last-mile bandwidth problem you can't deliver something like this 
as a web app to the home user.

>>>> This is similar
> to the problem faced by online FPS engines: Since you can't rely on
> subsecond response times when you're playing CounterStrike over the
> network, the server has to give the client more information than
> strictly necessary and trust it to do what's right until the next time
> contact is established.
> <<<
>
> While that's true for modems, it's not necessarily true once you get to
> broadband. This is a complex topic with a lot of details. I happen to
> have a friend who works professionally in this area. I've played
> versions of quake3 that remove all prediction and run at a locked 60hz
> rate both for client side graphics and network state update. Latency
> isn't necessarily the same as throughput, and human beings are
> surprisingly tolerant of latency. You can hit up citeseer for the
> relevant basic research done by the .gov in the initial military
> simulation days: the net result is that humans can tolerate as much as
> 150ms of local lag, and that at around 50ms of local lag human
> observers begin to have trouble distinguishing between lagged and
> unlagged input.
>
> 50ms round trip is possible on broadband these days, though not assured
> coast to coast in the US or anything.

Maybe you know more about this than I do, but how much data does a FPS 
have to send out and receive, anyway? It's been my impression that a 
FPS server sets a lot of the original model when the game sets up, and 
then sends the clients a continuous stream of location and status 
updates. I imagine the size of these updates is measurable in bytes or 
kilobytes.

> Anyhow, the point is not weither it's a good idea to do PS as a web
> app. I think it's a miserible idea. The point is that html+javascript
> rendering is sufficiently fast to serve as the basic drawing layer of a
> GUI abstraction. Of course something purpose designed for it would be
> better, but with the possible exception of flash, I don't think
> anything is going to get enough market penetration: html+javascript are
> good enough (barely).
>

Yeah, I agree with you there. Applications like Google Maps make the 
case for a lot of really astounding web apps, possible in the 
near-term.

Francis Hwang
http://fhwang.net/