The difference here is that VisualStudio code fully runs the GUI on the local machine and only file IO or external programs (compiler, the actual program being devleoped, ...) run remotely. Thus the UI reacts promptly to all interactions and many of the remote interactions happen asynchronously, thus even saving a file will not block further actions.
Whereas any non trivial X application does work in the client, thus even basic interactions have a notable delay, depending on connection.
I'm sorry to say I'm as confused as I was before I read these sentences.
Let me try to rephrase: with X Windows, the UI server runs on your local machine, while the UI client runs on the remote machine (e.g. your application's server). Is that correct?
I'm surprised pjmip is missing the point here. Or maybe I am
> Instead of sending streams of bytes to render text, it sends streams of encoded X Windows commands to draw the UI.
(Simplified) VSCode is sending no bytes to a server when you're editing a file. The entire file exists on the client, you can edit all you want and everything stays on the client. Only when you pick "save" is a data sent to the server.
My understanding with X Windows is as you mentioned above, you press a key, that key it sent app on another machine, that other machine sends back rendering commands. Correct? Vs VSCode, you press a key, nothing is sent remotely
Note: There's more to VSCode, while it doesn't have to send keystrokes and it is effectively editing the file locally (so fast). It does send changes asynchronously to the remote machine to run things like the Language Server Protocol stuff and asychronously sending the results back. But, you don't have to wait for that info to continue to edit.
Thanks for elaborating, it helped a bit and now this section of the Wikipedia article fully clicked for me:
"""The X server is typically the provider of graphics resources and keyboard/mouse events to X clients, meaning that the X server is usually running on the computer in front of a human user, while the X client applications run anywhere on the network and communicate with the user's computer to request the rendering of graphics content and receive events from input devices including keyboards and mice."""
The point still stands, though. You need a roundtrip, even if it starts from the X server rather than the X client.
You always need some level of round trip between keyboard and UNIX procecess.
The server application isn't guessing keys, regardless of the connection format.
What matters is how the communication is being compressed and local optimizations.
The difference here is that VisualStudio code fully runs the GUI on the local machine and only file IO or external programs (compiler, the actual program being devleoped, ...) run remotely. Thus the UI reacts promptly to all interactions and many of the remote interactions happen asynchronously, thus even saving a file will not block further actions.
Whereas any non trivial X application does work in the client, thus even basic interactions have a notable delay, depending on connection.
11 replies →
I'm sorry to say I'm as confused as I was before I read these sentences.
Let me try to rephrase: with X Windows, the UI server runs on your local machine, while the UI client runs on the remote machine (e.g. your application's server). Is that correct?
No, the whole UI runs on the client machine, which in X Windows nomenclature is the server.
The client application (on X Windows nomenclature), runs on the remote server and is headless.
Instead of sending streams of bytes to render text, it sends streams of encoded X Windows commands to draw the UI.
Everything else regarding compilers, subprocesses and what have you keeps running on the server, regardless how the connection is made.
Think big X Windows terminals or green/ambar phosphor terminals accessing the single UNIX server, used by the complete university department.
I'm surprised pjmip is missing the point here. Or maybe I am
> Instead of sending streams of bytes to render text, it sends streams of encoded X Windows commands to draw the UI.
(Simplified) VSCode is sending no bytes to a server when you're editing a file. The entire file exists on the client, you can edit all you want and everything stays on the client. Only when you pick "save" is a data sent to the server.
My understanding with X Windows is as you mentioned above, you press a key, that key it sent app on another machine, that other machine sends back rendering commands. Correct? Vs VSCode, you press a key, nothing is sent remotely
Note: There's more to VSCode, while it doesn't have to send keystrokes and it is effectively editing the file locally (so fast). It does send changes asynchronously to the remote machine to run things like the Language Server Protocol stuff and asychronously sending the results back. But, you don't have to wait for that info to continue to edit.
1 reply →
Thanks for elaborating, it helped a bit and now this section of the Wikipedia article fully clicked for me:
"""The X server is typically the provider of graphics resources and keyboard/mouse events to X clients, meaning that the X server is usually running on the computer in front of a human user, while the X client applications run anywhere on the network and communicate with the user's computer to request the rendering of graphics content and receive events from input devices including keyboards and mice."""