On Thu, Aug 15, 2013 at 08:35:20PM +0200, Joakim wrote:
> On Thursday, 15 August 2013 at 16:44:21 UTC, H. S. Teoh wrote:
> >On Thu, Aug 15, 2013 at 06:03:35PM +0200, Wyatt wrote:
> >>On Thursday, 15 August 2013 at 14:50:43 UTC, Joakim wrote:
> >>>
> >>>Sure, but X forwarding is still laggy, as you pointed out.
> >>>
> >>I think that's only because it's a naive, uncompressed implementation.  Proper protocol compression pretty much removes that for most use cases.
> >[...]
> >
> >I've run X11 forwarding over a compressed SSH tunnel before. It's actually usable. Not fast, but usable. (And this was over the internet, not in a LAN, which would be significantly faster.) I used to run X11 forwarding over an uncompressed channel, and it was unusably slow.
> I've only done X11 forwarding over ssh, both WAN and LAN, it was incredibly laggy in both cases.

You need to run ssh -C, otherwise it just goes uncompressed plus the overhead of encrypting/decrypting each packet.

But yeah, it's not exactly fast. Definitely can't play FPS's over it. :)


> >X11 was really designed for server + many workstations LAN setups, and it still works pretty well in those scenarios. It was never designed to be used over WANs, so it performs poorly when your link goes through the internet. It also wasn't designed for desktop apps, though modern X servers bypass most of the performance overhead by extensions that allow direct memory mapping between the server and client, so you could, e.g., directly access VRAM once it's negotiated with the server.
> What is the latency or bandwidth threshold that X11 needs?  I've found it slow even with low latency and plenty of bandwidth, ie over a local LAN.  "It also wasn't designed for desktop apps:" what was it designed for then, xterm and xclock and that's it?
[...]

Sorry, I was unclear, I meant that it wasn't really intended to have the server and client both run on the same box. Of course, this problem is largely alleviated by X extensions that allow direct memory mapping between server and client. But the base protocol wasn't really designed for optimized localhost communication (needing to talk to a localhost server via sockets adds a lot of overhead, esp. given X11's verboseness in terms of protocol).


T

-- 
The fact that anyone still uses AOL shows that even the presence of options doesn't stop some people from picking the pessimal one. - Mike Ellis

On Thursday, 15 August 2013 at 18:38:40 UTC, sclytrack@tired.com wrote:
> Gtk Broadway.

nice. My first draft for my idea had an html client too, but this was some years ago before the html5 stuff was around, so it did ajax long polling for events and tried to map it to JS. Didn't work out super well, but did actually work - my three example apps (notepad, calculator, and an AIM client) all functioned on it, with minor bugs.

WebSockets and <canvas> make me want to do it again. In simpledisplay.d, I added a version(html5) but didn't actually get anywhere with it...

On Thursday, 15 August 2013 at 18:38:40 UTC, sclytrack@tired.com wrote:
>
>> There are a lot of possibilities: you could run Qt or Gtk+ on the server and then write a backend for each of those toolkits so they can call the simple Crack server APIs and render to the Crack client.
>
> Gtk Broadway.
>
> http://www.youtube.com/watch?v=fr8eo4RlPw4

I saw that a couple years ago, cool demo, though I wonder how precise or laggy it'd be over the network.  Do you know if they're using canvas or webGL to render?  All I see online is that they used websockets for networking.  I did find this cool post when looking for more info:

https://brendaneich.com/2013/05/today-i-saw-the-future/

I'm skeptical about all the engineering challenges of that GPU cloud stuff though.

I'd rather work on getting a good thin client going first, which the web should have been but never got right, before getting into all this whiz-bang stuff with so many moving parts.

On Thursday, 15 August 2013 at 18:35:22 UTC, Joakim wrote:
> I've only done X11 forwarding over ssh, both WAN and LAN, it was incredibly laggy in both cases.

You're probably using bloated apps! I'm using my crappygui.d on remote X and it works quite well. Of course it is mostly rectangles of solid colors :)

I also just tried creating an OpenGL window remotely, and it performed reasonably well too, drawing some colorful triangles. I think I'll add some minimal support for creating opengl contexts to simpledisplay.d, that's useful stuff.


> I don't think "blending in with the rest of the desktop" is a worthwhile goal.

Eh, it is something I can live without, but would like to have. Applications just feel more complete when they blend in.

I've been tinkering with a GUI framework in D myself to use in my own project. This is how it looks:

https://www.youtube.com/watch?v=IfloImORm74&hd=1

* OpenGL

* FreeType for glyphs

* Text layout engine inspired by Qt

* Widget layout inspired by OSX

* SDL for input - would be awesome to get rid of this by using some of AdamRuppes work maybe.

* Animations (by using CTFE)(The youtube video is laggy, it looks smooth on the machine). I've done this in C++ before and D rocks compared!

Project layout:

https://dl.dropboxusercontent.com/u/188292/Capture1.PNG
https://dl.dropboxusercontent.com/u/188292/Capture.PNG

It is Work In Progress but ping me if anyone would like partner up on this. I'm open to radical changes and redesigns... whatever it takes to make it awesome.

I does require a bit of work to separate it out and put it on github so therefore I'm not posting a link to the source before someone is interested.

/Jonas

On 8/15/13 12:42 PM, Adam D. Ruppe wrote:
> On Thursday, 15 August 2013 at 18:35:22 UTC, Joakim wrote:
>> I've only done X11 forwarding over ssh, both WAN and LAN, it was
>> incredibly laggy in both cases.
>
> You're probably using bloated apps! I'm using my crappygui.d on remote X
> and it works quite well. Of course it is mostly rectangles of solid
> colors :)
>
> I also just tried creating an OpenGL window remotely, and it performed
> reasonably well too, drawing some colorful triangles. I think I'll add
> some minimal support for creating opengl contexts to simpledisplay.d,
> that's useful stuff.

The X Window System is slow by design, particularly when used over a network (regardless how fast). There are various proxies and alternate remoting protocols that avoid its inherent latencies. At work we use OpenNX.


Andrei

On 08/13/2013 03:23 PM, Paul Z. Barsan wrote:
> Jacob Carlborg:
> * You would still need to some graphics primitives. Do you want to
> implement them yourself as well? I mean, you have to draw the line
> somewhere. There's always a layer beneath you that you rely on, if
> you're not doing embedded or similar.
> * you want a non-native toolkit.
> * primitives would be implemented on top of OpenGL or DirectX. OpenGL is
> implemented in the graphics drivers, don't know how it works with DirectX.

Writing a rasterizer isn't actually that hard.
https://github.com/dawgfoto/graphics

Andrei Alexandrescu wrote:

> On 8/15/13 12:42 PM, Adam D. Ruppe wrote:
>> On Thursday, 15 August 2013 at 18:35:22 UTC, Joakim wrote:
>>> I've only done X11 forwarding over ssh, both WAN and LAN, it was incredibly laggy in both cases.
>>
>> You're probably using bloated apps! I'm using my crappygui.d on remote X and it works quite well. Of course it is mostly rectangles of solid colors :)
>>
>> I also just tried creating an OpenGL window remotely, and it performed reasonably well too, drawing some colorful triangles. I think I'll add some minimal support for creating opengl contexts to simpledisplay.d, that's useful stuff.
> 
> The X Window System is slow by design, particularly when used over a network (regardless how fast). There are various proxies and alternate remoting protocols that avoid its inherent latencies. At work we use OpenNX.

If we are discussing X's shortcomings: why don't we use something like http://wayland.freedesktop.org/ which will (hopefully) become next big standard and which addresses many of X's flaws?

-- 
Marek Janukowicz

On Thursday, 15 August 2013 at 18:35:22 UTC, Joakim wrote:
>
> I've only done X11 forwarding over ssh, both WAN and LAN, it was incredibly laggy in both cases.
>
As Andrei and I have pointed out, NX does a much better job of things.  If nothing else, read the explanation of how it works-- there are perceptual subtleties to this that aren't apparent at first glance:
http://www.nomachine.com/documents/NX-XProtocolCompression.php

> What is the latency or bandwidth threshold that X11 needs?

They talk a bit about this in the above link, too.

-Wyatt

On Thursday, 15 August 2013 at 18:52:21 UTC, H. S. Teoh wrote:
>
> You need to run ssh -C, otherwise it just goes uncompressed plus the
> overhead of encrypting/decrypting each packet.
>
SSH compression is something of a worst-case scenario for compressing remote X traffic.  As a fun aside, for X forwarding on LAN I find -c arcfour offers better performance. -C just slows things down.

> But yeah, it's not exactly fast. Definitely can't play FPS's over it. :)
>
This...  I was going to say it's pretty much impossible, but thinking about it, I'm not so sure.  X forwarding uses indirect rendering, which has never given me good performance, but it MAY be possible on modern hardware with good bandwidth, clever compression, and client-side prediction (Something like Frankensteining NX, GGPO, VirtualGL, and ICER together?).

Probably not for FPS, so much, but a lot of other semi-realtime applications. Fundamentally, you have to deal with getting a frame up inside of 33 milliseconds, however you do it, and input latency somewhere in the same apartment block as 50ms (else people hem and haw like you wouldn't believe).  OnLive, for how they hilariously over-promised on infrastructural matters, looked to have some pretty interesting tech underneath; but they claim to have relied heavily on custom ASICs to pull it off.

-Wyatt