[FoRK] The Future of Desktops
J. Andrew Rogers
andrew at jarbox.org
Sun Mar 2 13:17:30 PST 2014
On Mar 2, 2014, at 2:39 AM, Stephen Williams <sdw at lig.net> wrote:
> Sometimes you want to render on the server and pass the result (tiled result or video or baked 3D) to the client and sometimes you want to compute on the client. There's no point in sending the result of mundane operations over a link like manipulation of data or viewport of fixed or locally generated (games etc.) viz: that would be jaggy. Certainly there are interesting cases that need to be done in the hive / megaframe, where the source data size swamps the vizualization bandwidth. Often, the viz is generated from much smaller data: in those cases, client-side is usually better.
The issue is data *velocity*, not volume per se. The data model size could be quite modest but the update rate extremely high. This does violence to traditional UI rendering models, whether client or server side. These cases used to be an outlier a few years ago but now show up in all kinds of applications, mostly thanks to the Internet of Everything. Real-time entity tracking and analysis, a sexy growth area in just about every industry, is a canonical example of this type of usage pattern.
When the data model that is being rendered in a UI is changing a billion times per second, you can’t push the render to the client and you can’t ship a static reduction either. In fact, you can’t even afford to render everything on the server cluster by default; you have to be selective about the parts of the data model that need to be rendered in any particular instance.
This has created a positive environmental pressure in analytic software: it has forced people to design systems that remove the human element entirely. Humans were the only reason the UI existed in the first place; it is easier to design around the human.
> It should be possible to stream textures and meshes in an efficient way and incorporate those into local rendering. That allows interaction controls and other locally generated viz to be smooth and fast. Google Maps and Google Earth are examples of this.
Google Maps and Earth are essentially static data models. It makes the problem trivial. A meaningfully “live” version of Google Earth would require a rewrite of both the front and back.
More information about the FoRK