Fast drag option, not really fast

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Fast drag option, not really fast

HilaireFernandes
Hi,

Will it be possible to have the really *fast* drag option back as we had
in old time and does in Squeak?

Even over LAN X11 exported display, the fast drag option is slow.
Obvisouly graphic translucent operations can't be fast.

As far as I can rewind, fast drag is slow since at least Pharo3

Hilaire

--
Dr. Geo
http://drgeo.eu


Reply | Threaded
Open this post in threaded view
|

Re: Fast drag option, not really fast

HilaireFernandes
In the other hand it is likely the Pharo image does know about drawing
operations on a remote X server, and it may just result in bitmap buffer
transfers to repair damaged areas... Neverthless, the damaged area is
still smaller when dragging with only line outlines.

Le 28/03/2017 à 15:20, Hilaire a écrit :
> Hi,
>
> Will it be possible to have the really *fast* drag option back as we had
> in old time and does in Squeak?
>
> Even over LAN X11 exported display, the fast drag option is slow.
> Obvisouly graphic translucent operations can't be fast.
>
> As far as I can rewind, fast drag is slow since at least Pharo3

--
Dr. Geo
http://drgeo.eu


Reply | Threaded
Open this post in threaded view
|

Re: Fast drag option, not really fast

Stephan Eggermont-3
In reply to this post by HilaireFernandes
On 28/03/17 15:20, Hilaire wrote:
> Even over LAN X11 exported display, the fast drag option is slow.
> Obvisouly graphic translucent operations can't be fast.

You are using a compression protocol for X11 communication, I assume?

Stephan



Reply | Threaded
Open this post in threaded view
|

Re: Fast drag option, not really fast

HilaireFernandes
No I did not because I am in a fast local area netwrok.
SSh documentation mention compression should not be used on fast LAN:

>   -C      Requests compression of all data (including stdin, stdout, stderr, and data for forwarded X11 and TCP connections).  The compression algorithm is the same used by gzip(1),
>              and the “level” can be controlled by the CompressionLevel option for protocol version 1.  Compression is desirable on modem lines and other slow connections, but will only
>              slow down things on fast networks.  The default value can be set on a host-by-host basis in the configuration files; see the Compression option.


As you mention it, I tested it and it happens to improve the situation.
So I guess the VM does not play nice with X server and may only transfer
X pixmap over the wire, so the cost of compression will be lower than
the cost to send hudge pixmap over the wire in this specific situation.

Hilaire

Le 28/03/2017 à 21:25, Stephan Eggermont a écrit :
>
> You are using a compression protocol for X11 communication, I assume?
>
> Stephan

--
Dr. Geo
http://drgeo.eu