From: Ilmari Heikkinen <kig@...>
Date: 2005-04-16T07:17:03+09:00
Subject: Re: What's beyond Rails?


On 16.4.2005, at 00:09, jason_watkins@pobox.com wrote:

> Well, I guess I have a dissenting opinion:
>
> 1.) You could do photoshop via http.
>
> It may interest you to skim http://opensource.adobe.com/ and realize
> that for a couple versions now, photoshop's UI logic has been written
> with declairative sublanguages of their own design. It's fairly
> straightforward to imagine treating the UI componant as a declariative
> document in xml, that specifies logic for preparing computational
> transactions that are relayed via http. It's quite accurrate to think
> of applications as a giant spreadsheet, where when a cell is notified
> it's invalid it dispatches the requests necessary to re-evaluate it's
> contents via http post or xmlhttprequest.
>
> The only real barrier to photoshop via http is not http, it's the lack
> of a toolkit for the client side portions. Once uppon a time I would
> have said there's no high performance client side language, but these
> days, I imagine javascript and most browsers html rendering would
> actually be fast enough to handle the various graphics rendering tasks
> a photoshop like application does.
>

The problem is that there are no high-performance libraries for 
javascript to munge image data. To do arbitrary edits to an image in 
javascript, you need to use a single div(or somesuch element) per 
pixel, and do all the calculation in js. Even when it's a small 640x480 
image with a single layer, it's going to be 307200 pixels. And that's 
going to be slow going in dhtml. The browsers'll probably blow up at 
around hundred thousand elements.

When you can run Quake 1 with software rendering in a 320x240 window 
with html + javascript, it'll be about fast enough for Photoshop. 
(Maybe there is there a port of q1?)

Maybe if there was a fast VM for javascript and direct rendering access 
in DOM...

*shrug* who knows what the future brings :)