On Sep 12, 2017, at 5:56 PM, Jon Steinhart
<jon(a)fourwinds.com> wrote:
Bakul Shah writes:
Unix still needs a decent graphics API (ideally one that can work over a network).
Any thoughts on that?
Wow, big topic. Rather than getting into it in detail at the moment I'm curious
as to why you think that it's important for it to work over a network.
Heavy number crunching generating some data for display may be far
from the one displaying the data.
[sensor input | storage] => [computation} <=> [display/user input]
Before you bite my head off for that question,
I'm not suggesting that there's
no value in taking data from somewhere on a network and using it on a local
machine.
...
So before getting off into graphics APIs I think that
it would be interesting
to hash this out.
Indeed. The question really is where in the pipeline from gobs
of raw data to number crunching transformations to display
does the network split lie. In a sense we already have a
split (GPU vs CPU) but it is highly specialized.
Camera, mouse, graphics tablet, keyboard, other sensor inputs
will be (or should be) near the display but may be processed far
away in an application specific manner.
I suspect here too we may go through Sutherland's wheel of
reincarnation. We can offload more GUI processing in the
server but as GUI becomes more sophisticated (or complicated),
it will feel slow.
I can envision using a RaspberryPi as a "graphics processor"
but we still need a protocol between the 'Pi and the
"backend". If done right, I wouldn't want to touch the innards
of the s/w running on the 'Pi when writing a game or something
needing visualization.
BTW, one of the best things about NeWS was the fact
that with a reasonable set
of conventions the user interface personality could live in the server and be
applied to all applications. Contrast that with X where each application links
in a UI library, and if your screen looks anything like mine there isn't a lot
of consistency because different applications use different libraries.