Date: Thu, 20 Aug 2015 11:17:35 +0100 From: Steve O'Hara-Smith <steve@sohara.org> To: freebsd-questions@freebsd.org Cc: mexas@bris.ac.uk Subject: Re: running a graphical application over ssh - where is rendering done? Message-ID: <20150820111735.bfbba2567ac9d797e7c0eecb@sohara.org> In-Reply-To: <201508200907.t7K97ITO033940@mech-as222.men.bris.ac.uk> References: <201508200907.t7K97ITO033940@mech-as222.men.bris.ac.uk>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 20 Aug 2015 10:07:18 +0100 (BST) Anton Shterenlikht <mexas@bris.ac.uk> wrote: > If I conect from my laptop to a server via ssh -XY, > and then launch a 3D graphical application on the server, > and view the results back on my laptop, which side > is doing the rendering? With X the rendering is always done by the X server (the thing with the screen, keyboard and pointer) what goes over the network are commands to the server (this can include bitmaps to be placed in windows). > So does the graphical application send the data over the > network back to my laptop, where I render it using the local resources? The graphical application communicates with the display server using X11 protocol (and whatever extensions are available which includes GLX and DRI on most systems these days) the rendering is done by the display server. It doesn't have to be, the application could present a bitmap and update it leaving the server to place the bitmap into a window. A high resolution, 24 bit colour animation can eat a lot of network bandwidth done this way, and network latency can really kill interactive behaviour. > Is there any control over where the rendering is actually done? You could disable the GLX extension and see if the application has some other way of getting the data across - it is likely to be painful unless you have a very fast network, and the chances are that the application will simply fail. -- Steve O'Hara-Smith <steve@sohara.org>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20150820111735.bfbba2567ac9d797e7c0eecb>