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

Intriguing. But leaving aside the issue of whether it would be 
economically worth it to offer such software as a web service, I wonder 
how good your bandwidth would have to be for this to be sensible with 
high-definition images.

For example. I've got Photoshop files on my machine that easily top 100 
MB in size, but let's just 100 MB as a representative sample. Let's say 
I've got that file living in this web app, and I run a one-pixel 
gaussian blur on the whole thing. The web client issues the command to 
the server, the server churns on this for a few seconds, and sends the 
whole image down the pipe again ... My cable modem at home has a peak 
downstream of 5 Mpbs, so it's going to take 20 seconds for me to get 
the new image -- and that's assuming the app doesn't have to share the 
pipe with any other program like BitTorrent or Acquisition, or, hell, 
my mail program, which checks my mail every 5 minutes.

Now, you can try to run some lossless compression on the file to try to 
get it down to, say, 10 seconds, but that makes everything more complex 
and, oh, sometimes you've got high-entropy images so you've gone to all 
the trouble for very little gain.

You can also try to serve only the view of the image that the user 
needs right that instant, but that doesn't so much kill the lag as 
spread it around. The monitor I use at home, for example, is a 1280x960 
resolution with 24-bit color, which means, if my math is right, that 
filling my screen requires 3.5 MB worth of pixels. It takes me 0.7 
seconds to download that much data if my cable modem's doing well. That 
doesn't sound like so much until you realize you have to have that wait 
every single time you zoom in or out, or scroll up or down, or even 
change the background color from white to transparent. 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.

And by the way, if you're dealing with 24-bit images on an app driven 
by HTTP+JavaScript, how good is the color fidelity going to be?

I'm happy to do plenty of things on the web, but image processing ain't 
one of them.

Francis Hwang
http://fhwang.net/




On Apr 15, 2005, at 7:19 PM, jason_watkins@pobox.com wrote:

> You're missing the architecture. Html+javascript for just the UI layer.
> The pixel munging is done on the server in whatever language you
> please. Display of results is done by regenerating results on the
> server, which the client refreshes.
>
> The html+javascript is just used as a sort of very bare bones 2d scene
> graph, like a stripped down gdi or xwindows.
>
> In other words, very similar to google maps.
>
> Like I said, you can think of it abstractly as a spreadsheet where the
> client has all the logic for cell interdependancies, but the heavy
> calculations for cell re-evaluation is done by posting and getting to
> the server.
>
>
>