slow X11 frame creation and refresh after occlusion (was: gnus-server-to-method crash on virtual server name in gnus-secondary-select-methods)

[Greg Klanderman]

Hi Robert,

Thank you for your response!


>>>>> On January 26, 2021 Robert Pluim <rpluim@gmail.com> wrote:

>>>>> On Mon, 25 Jan 2021 12:51:04 -0500, Greg Klanderman <gak@klanderman.net> 
>>>>> said:
Greg> My biggest concern now with fully transitioning, other than a lot more
Greg> time, is how slow it is over ssh forwarded X11.  As I said xemacs is
Greg> perfectly snappy, but Emacs is taking sometimes 30-60+ sec just to
Greg> create a new frame.

> Does the attached patch improve frame creation?

Let me get back to you.. I did clone the git repository last week but
have not gotten around to building yet.. I did just look and find the
building guide so hopefully get to that in the next couple days..

But IIUC the patch removes one of two XOpenDisplay() calls, so at best
would halve the latency in opening a new frame, so I can't see it
completely solving the problem.

Also, shouldn't the opening of the display only take place for the
first frame on that display?

Greg> I turned off tooltips which seemed to be causing much of the latency
Greg> issues, then it seemed that toolbars & menubars were the issue because
Greg> after dragging another window over an Emacs frame, everything would
Greg> redraw immediately but the menubars and toolbars, which could again
Greg> take 30-60+ seconds with Emacs being essentially frozen to input.
Greg> Switching gtk to lucid (Debian testing) did not make appreciable
Greg> difference.

Greg> I've now noticed that the problem only occurs when a frame of
Greg> an Emacs is dragged over another frame of the same Emacs, so I suspect
Greg> some problem with the event handling loop.  I will submit a bug
Greg> report; this is perfectly reproducible with emacs -Q after ssh'ing
Greg> from my work laptop (on home network) to my work desktop (in office
Greg> 30mi away) and then back to my personal home desktop, even with
Greg> tooltips/tool bars/menu bars/scroll bars off.

> Which X server are you using? I don?t see this at all (but admittedly
> the two machines in question are a meter apart)

Yeah I do not see it between my work laptop and home desktop plugged
into the same switch (I am working fully remote, from home).

Displaying from my work desktop (in office 30 mi away) to work laptop
on my home network it is very obvious, and even more so displaying
from my home desktop via work desktop and back onto my work laptop
(again, on my home network).

My home desktop is running Debian testing, and the work laptop and
desktop are running Debian testing with work's patches applied.

Generally I am running in "old-school" mode, without a desktop
environment, using fvwm2 2.6.9 + a few local patches, started via
startx from a terminal login.

I will check if I see the issue using the default desktop environment
(I think cinnamon is standard on the work laptop).. and get back to
you on that as well.

X server is whatever is default on Debian testing, let me know if
there is some command you want me to run to determine any specific
details..

thanks,
Greg


> diff --git a/src/xterm.c b/src/xterm.c
> index 2e0407aff4..448e06eb8b 100644
> --- a/src/xterm.c
> +++ b/src/xterm.c
> @@ -12709,8 +12709,6 @@ x_term_init (Lisp_Object display_name, char 
> *xrm_option, char *resource_name)
>        ++x_initialized;
>      }

> -  if (! x_display_ok (SSDATA (display_name)))
> -    error ("Display %s can't be opened", SSDATA (display_name));

>  #ifdef USE_GTK
>    {
> @@ -12838,6 +12836,7 @@ #define NUM_ARGV 10
>    /* Detect failure.  */
>    if (dpy == 0)
>      {
> +      error ("Display %s can't be opened", SSDATA (display_name));
>        unblock_input ();
>        return 0;
>      }