bug#33442: 26.1.90; Cairo side-by-side windows scrolling fix should be cherry-picked

bug#33442: 26.1.90; Cairo side-by-side windows scrolling fix should be cherry-picked

[Ari Roponen]

Scrolling in --with-cairo -build doesn't work when there are
side-by-side split windows. That was fixed in the master branch by
commit 6e362a32bc9d21f73a0f29ca6f45481edeea6f29

    Author: Ari Roponen <ari.roponen@gmail.com>
    Date:   Sun May 6 15:29:28 2018 +0300
    
        Fix cairo scrolling for side-by-side windows
        
        * src/xterm.c (x_scroll_run) [USE_CAIRO]: Fix scrolling for
        side-by-side split windows.  (Bug#31288)
    
Cherry-picking that commit fixes the problem in 26 branch too.

In GNU Emacs 26.1.90 (build 6, x86_64-pc-linux-gnu, GTK+ Version 3.24.1, cairo version 1.16.0)
 of 2018-11-20 built on arirop
Repository revision: d667318a7f89a9daeffca6fb47503889bd23f3bd
Windowing system distributor 'Fedora Project', version 11.0.12003000
System Description:	Fedora release 29 (Twenty Nine)

Configured using:
 'configure --with-cairo'

Configured features:
XPM JPEG TIFF GIF PNG RSVG CAIRO IMAGEMAGICK SOUND DBUS GSETTINGS GLIB
NOTIFY LIBSELINUX GNUTLS LIBXML2 FREETYPE M17N_FLT LIBOTF XFT ZLIB
TOOLKIT_SCROLL_BARS GTK3 X11 XDBE XIM THREADS LIBSYSTEMD LCMS2

bug#33442: 26.1.90; Cairo side-by-side windows scrolling fix should be cherry-picked

[Eli Zaretskii]

> From: Ari Roponen <ari.roponen@gmail.com>
> Date: Tue, 20 Nov 2018 10:15:09 +0200
> 
> Scrolling in --with-cairo -build doesn't work when there are
> side-by-side split windows. That was fixed in the master branch by
> commit 6e362a32bc9d21f73a0f29ca6f45481edeea6f29
> 
>     Author: Ari Roponen <ari.roponen@gmail.com>
>     Date:   Sun May 6 15:29:28 2018 +0300
>     
>         Fix cairo scrolling for side-by-side windows
>         
>         * src/xterm.c (x_scroll_run) [USE_CAIRO]: Fix scrolling for
>         side-by-side split windows.  (Bug#31288)
>     
> Cherry-picking that commit fixes the problem in 26 branch too.

Thanks, but I'm not convinced we should backport that change.  We
don't fix every bug on the release branch, only the important onces.
And the Cairo configuration doesn't strike me as important, what with
all the additional known bugs specific to it.

That said, I'm open to arguments to the contrary.

bug#33442: 26.1.90; Cairo side-by-side windows scrolling fix should be cherry-picked

[Dmitry Gutov]

On 20.11.2018 17:58, Eli Zaretskii wrote:

> Thanks, but I'm not convinced we should backport that change.  We
> don't fix every bug on the release branch, only the important onces.

An argument could be made about the lesser impotance of stability 
guarantees for the Cairo users (since it's already broken). So I'd ask 
whether the given patch makes it considerably more usable, so that more 
people are likely to try the --with-cairo build and submit patches/bug 
reports/etc.

> And the Cairo configuration doesn't strike me as important, what with
> all the additional known bugs specific to it.

IIRC, somebody said it's the best approach we have for supporting 
Wayland someday. I think it's a worthy goal.

bug#33442: 26.1.90; Cairo side-by-side windows scrolling fix should be cherry-picked

[Eli Zaretskii]

> Cc: 33442@debbugs.gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Tue, 20 Nov 2018 18:16:19 +0200
> 
> On 20.11.2018 17:58, Eli Zaretskii wrote:
> 
> > Thanks, but I'm not convinced we should backport that change.  We
> > don't fix every bug on the release branch, only the important onces.
> 
> An argument could be made about the lesser impotance of stability 
> guarantees for the Cairo users (since it's already broken). So I'd ask 
> whether the given patch makes it considerably more usable, so that more 
> people are likely to try the --with-cairo build and submit patches/bug 
> reports/etc.

Good point.  I'd like to know the answer to that.

> > And the Cairo configuration doesn't strike me as important, what with
> > all the additional known bugs specific to it.
> 
> IIRC, somebody said it's the best approach we have for supporting 
> Wayland someday. I think it's a worthy goal.

Sure, but it needs someone to work on making it usable and on fixing
the bugs.  Otherwise, it's just a teaser.

bug#33442: 26.1.90; Cairo side-by-side windows scrolling fix should be cherry-picked

[Ari Roponen]

Eli Zaretskii <eliz@gnu.org> writes:

>> Cc: 33442@debbugs.gnu.org
>> From: Dmitry Gutov <dgutov@yandex.ru>
>> Date: Tue, 20 Nov 2018 18:16:19 +0200
>> 
>> On 20.11.2018 17:58, Eli Zaretskii wrote:
>> 
>> > Thanks, but I'm not convinced we should backport that change.  We
>> > don't fix every bug on the release branch, only the important onces.
>> 
>> An argument could be made about the lesser impotance of stability 
>> guarantees for the Cairo users (since it's already broken). So I'd ask 
>> whether the given patch makes it considerably more usable, so that more 
>> people are likely to try the --with-cairo build and submit patches/bug 
>> reports/etc.
>
> Good point.  I'd like to know the answer to that.

Cairo fixes went to the release branch after 26.1 was tagged
(commit aac541e75e2c22d05752025c2087ae2eea4cb525). 
This patch is a left-over that fixes the scrolling when the window is
split side-by-side.

I have been using --with-cairo for my Emacs builds for six months, and
haven't had any major problems with it.

bug#33442: 26.1.90; Cairo side-by-side windows scrolling fix should be cherry-picked

[Dmitry Gutov]

On 21.11.2018 9:11, Ari Roponen wrote:

> I have been using --with-cairo for my Emacs builds for six months, and
> haven't had any major problems with it.

Curious.

I've just tried building the master branch --with-cairo (on GNU/Linux), 
and I see crippling rendering problems right away. Maybe the same issue 
as reported at https://debbugs.gnu.org/cgi/bugreport.cgi?bug=23925.

bug#33442: 26.1.90; Cairo side-by-side windows scrolling fix should be cherry-picked

[Ari Roponen]

Dmitry Gutov <dgutov@yandex.ru> writes:

> On 21.11.2018 9:11, Ari Roponen wrote:
>
>> I have been using --with-cairo for my Emacs builds for six months, and
>> haven't had any major problems with it.
>
> Curious.
>
> I've just tried building the master branch --with-cairo (on
> GNU/Linux), and I see crippling rendering problems right away. Maybe
> the same issue as reported at
> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=23925.
>

It does work here. I use gnome-shell on Xwayland.
Could you try the following patch, if it helps?

diff --git a/src/xterm.c b/src/xterm.c
index 3a7e31e712..e82beacd7d 100644
--- a/src/xterm.c
+++ b/src/xterm.c
@@ -992,6 +992,9 @@ x_update_begin (struct frame *f)
   if (FRAME_TOOLTIP_P (f) && !FRAME_VISIBLE_P (f))
     return;
 
+  if (FRAME_GARBAGED_P (f))
+    x_cr_destroy_surface (f);
+
   if (! FRAME_CR_SURFACE (f))
     {
       int width, height;

bug#33442: 26.1.90; Cairo side-by-side windows scrolling fix should be cherry-picked

[Dmitry Gutov]

On 22.11.2018 8:44, Ari Roponen wrote:

> It does work here. I use gnome-shell on Xwayland.
> Could you try the following patch, if it helps?

No change.

It's probably also related to HiDPI: the area that gets refreshed is at 
half the window size and height. And my desktop scaling factor is 2.

X+Unity+Compiz+Ubuntu 18.04.1 here, though. I'll have to try it with 
GNOME sometime.

bug#33442: 26.1.90; Cairo side-by-side windows scrolling fix should be cherry-picked

[Ari Roponen]

Dmitry Gutov <dgutov@yandex.ru> writes:

> On 22.11.2018 8:44, Ari Roponen wrote:
>
>> It does work here. I use gnome-shell on Xwayland.
>> Could you try the following patch, if it helps?
>
> No change.
>
> It's probably also related to HiDPI: the area that gets refreshed is
> at half the window size and height. And my desktop scaling factor is
> 2.

That seems to be it: Starting Emacs with
  GDK_SCALE=2 emacs -Q
shows the problem here, too.

bug#33442: 26.1.90; Cairo side-by-side windows scrolling fix should be cherry-picked

[Dmitry Gutov]

On 22.11.2018 14:19, Ari Roponen wrote:

> That seems to be it: Starting Emacs with
>    GDK_SCALE=2 emacs -Q
> shows the problem here, too.

Thanks for that. I've just tried a --with-cairo build with

     GDK_SCALE=1 emacs

and it seems to work well, (even) without your extra patch. Aside from 
the expected problems with toolbar icons and scrollbar (too small), 
which I don't use anyway.

So maybe we shouldn't think of the Cairo build as too broken anymore.

bug#33442: 26.1.90; Cairo side-by-side windows scrolling fix should be cherry-picked

[Eli Zaretskii]

> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Thu, 22 Nov 2018 16:05:18 +0200
> Cc: 33442@debbugs.gnu.org
> 
> Thanks for that. I've just tried a --with-cairo build with
> 
>      GDK_SCALE=1 emacs
> 
> and it seems to work well, (even) without your extra patch. Aside from 
> the expected problems with toolbar icons and scrollbar (too small), 
> which I don't use anyway.
> 
> So maybe we shouldn't think of the Cairo build as too broken anymore.

How many users will agree to demote the DPI just to have the Cairo
build working?  IOW, is the above a viable solution, or is it
something many users will regard as unacceptable?

bug#33442: 26.1.90; Cairo side-by-side windows scrolling fix should be cherry-picked

[Dmitry Gutov]

On 22.11.2018 16:52, Eli Zaretskii wrote:

> How many users will agree to demote the DPI just to have the Cairo
> build working?  IOW, is the above a viable solution, or is it
> something many users will regard as unacceptable?

I think so. The toolbar buttons and the scrollbar handle are simply 
smaller, and a lot of hardcore users disable them anyway.

The font size or rendering quality don't seem to be affected by the 
scaling factor.

Still, some users won't like it, or will simply be confused if they have 
to hunt for "GDK_SCALE=1 emacs" in the PROBLEMS file, so we have to fix 
that sooner a later, too. But it seems to be a separate bug, not one 
we've already seen reported. And, judging from the past bug reports, 
problems like this are relatively easy to fix.

bug#33442: 26.1.90; Cairo side-by-side windows scrolling fix should be cherry-picked

[Dmitry Gutov]

On 22.11.2018 17:22, Dmitry Gutov wrote:
> On 22.11.2018 16:52, Eli Zaretskii wrote:
> 
>> How many users will agree to demote the DPI just to have the Cairo
>> build working?  IOW, is the above a viable solution, or is it
>> something many users will regard as unacceptable?
> 
> I think so. <...>

In any case, HiDPI users are still the minority, and the commit 
requested to be backported is a localized fix for an obvious, 
easy-to-reproduce regression (scrolling is indeed broken, I tested with 
and without the patch).

So I highly suggest we allow it.

bug#33442: 26.1.90; Cairo side-by-side windows scrolling fix should be cherry-picked

[Ari Roponen]

Dmitry Gutov <dgutov@yandex.ru> writes:

> On 22.11.2018 14:19, Ari Roponen wrote:
>
>> That seems to be it: Starting Emacs with
>>    GDK_SCALE=2 emacs -Q
>> shows the problem here, too.
>
> Thanks for that. I've just tried a --with-cairo build with
>
>     GDK_SCALE=1 emacs
>
> and it seems to work well, (even) without your extra patch. Aside from
> the expected problems with toolbar icons and scrollbar (too small),
> which I don't use anyway.

With the following patch, GDK_SCALE=2 seems to work for me.

diff --git a/src/xterm.c b/src/xterm.c
index 3a7e31e712..42ddc4f5b1 100644
--- a/src/xterm.c
+++ b/src/xterm.c
@@ -360,10 +360,15 @@ x_begin_cr_clip (struct frame *f, GC gc)
 
       if (! FRAME_CR_SURFACE (f))
         {
+	  int scale = 1;
+#ifdef USE_GTK
+	  scale = xg_get_scale (f);
+#endif
+
 	  FRAME_CR_SURFACE (f) =
 	    cairo_image_surface_create (CAIRO_FORMAT_ARGB32,
-					FRAME_PIXEL_WIDTH (f),
-					FRAME_PIXEL_HEIGHT (f));
+					scale * FRAME_PIXEL_WIDTH (f),
+					scale * FRAME_PIXEL_HEIGHT (f));
 	}
       cr = cairo_create (FRAME_CR_SURFACE (f));
       FRAME_CR_CONTEXT (f) = cr;
@@ -999,8 +1004,9 @@ x_update_begin (struct frame *f)
       if (FRAME_GTK_WIDGET (f))
         {
           GdkWindow *w = gtk_widget_get_window (FRAME_GTK_WIDGET (f));
-          width = gdk_window_get_width (w);
-          height = gdk_window_get_height (w);
+	  int scale = xg_get_scale (f);
+	  width = scale * gdk_window_get_width (w);
+          height = scale * gdk_window_get_height (w);
         }
       else
 #endif

bug#33442: 26.1.90; Cairo side-by-side windows scrolling fix should be cherry-picked

[Robert Pluim]

Ari Roponen <ari.roponen@gmail.com> writes:

> Dmitry Gutov <dgutov@yandex.ru> writes:
>
>> On 22.11.2018 14:19, Ari Roponen wrote:
>>
>>> That seems to be it: Starting Emacs with
>>>    GDK_SCALE=2 emacs -Q
>>> shows the problem here, too.
>>
>> Thanks for that. I've just tried a --with-cairo build with
>>
>>     GDK_SCALE=1 emacs
>>
>> and it seems to work well, (even) without your extra patch. Aside from
>> the expected problems with toolbar icons and scrollbar (too small),
>> which I don't use anyway.
>
> With the following patch, GDK_SCALE=2 seems to work for me.
>

Works for me. Since this is all Cairo-only code, it could even go into
emacs-26, I think (with a ChangeLog and perhaps some comments).

Robert

bug#33442: 26.1.90; Cairo side-by-side windows scrolling fix should be cherry-picked

[Eli Zaretskii]

> From: Robert Pluim <rpluim@gmail.com>
> Date: Thu, 29 Nov 2018 14:19:56 +0100
> Cc: 33442@debbugs.gnu.org, Dmitry Gutov <dgutov@yandex.ru>
> 
> > With the following patch, GDK_SCALE=2 seems to work for me.
> >
> 
> Works for me. Since this is all Cairo-only code, it could even go into
> emacs-26, I think (with a ChangeLog and perhaps some comments).

OK, let's do that.

bug#33442: 26.1.90; Cairo side-by-side windows scrolling fix should be cherry-picked

[Ari Roponen]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Robert Pluim <rpluim@gmail.com>
>> Date: Thu, 29 Nov 2018 14:19:56 +0100
>> Cc: 33442@debbugs.gnu.org, Dmitry Gutov <dgutov@yandex.ru>
>> 
>> > With the following patch, GDK_SCALE=2 seems to work for me.
>> >
>> 
>> Works for me. Since this is all Cairo-only code, it could even go into
>> emacs-26, I think (with a ChangeLog and perhaps some comments).
>
> OK, let's do that.
>

The following patch fixes the scaling problem in Cairo builds. The
scrolling issue with side-by-side windows is in master branch (commit
6e362a32bc9d21f73a0f29ca6f45481edeea6f29), and can be cherry-picked.


From c76a784f7c345031f9bf1f88d2e4b13e44053638 Mon Sep 17 00:00:00 2001
From: Ari Roponen <ari.roponen@gmail.com>
Date: Fri, 30 Nov 2018 14:09:09 +0200
Subject: [PATCH 1/1] Fix scaling problem in cairo builds

* src/xterm.c (x_begin_cr_clip) [USE_GTK]:
(x_update_begin) [USE_CAIRO && USE_GTK]: Support scaling.
---
 src/xterm.c | 14 ++++++++++----
 1 file changed, 10 insertions(+), 4 deletions(-)

diff --git a/src/xterm.c b/src/xterm.c
index 3a7e31e712..42ddc4f5b1 100644
--- a/src/xterm.c
+++ b/src/xterm.c
@@ -360,10 +360,15 @@ x_begin_cr_clip (struct frame *f, GC gc)
 
       if (! FRAME_CR_SURFACE (f))
         {
+	  int scale = 1;
+#ifdef USE_GTK
+	  scale = xg_get_scale (f);
+#endif
+
 	  FRAME_CR_SURFACE (f) =
 	    cairo_image_surface_create (CAIRO_FORMAT_ARGB32,
-					FRAME_PIXEL_WIDTH (f),
-					FRAME_PIXEL_HEIGHT (f));
+					scale * FRAME_PIXEL_WIDTH (f),
+					scale * FRAME_PIXEL_HEIGHT (f));
 	}
       cr = cairo_create (FRAME_CR_SURFACE (f));
       FRAME_CR_CONTEXT (f) = cr;
@@ -999,8 +1004,9 @@ x_update_begin (struct frame *f)
       if (FRAME_GTK_WIDGET (f))
         {
           GdkWindow *w = gtk_widget_get_window (FRAME_GTK_WIDGET (f));
-          width = gdk_window_get_width (w);
-          height = gdk_window_get_height (w);
+	  int scale = xg_get_scale (f);
+	  width = scale * gdk_window_get_width (w);
+          height = scale * gdk_window_get_height (w);
         }
       else
 #endif
-- 
2.19.2

bug#33442: 26.1.90; Cairo side-by-side windows scrolling fix should be cherry-picked

[Eli Zaretskii]

> From: Ari Roponen <ari.roponen@gmail.com>
> Cc: Robert Pluim <rpluim@gmail.com>,  33442@debbugs.gnu.org,  dgutov@yandex.ru
> Date: Fri, 30 Nov 2018 14:31:51 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> From: Robert Pluim <rpluim@gmail.com>
> >> Date: Thu, 29 Nov 2018 14:19:56 +0100
> >> Cc: 33442@debbugs.gnu.org, Dmitry Gutov <dgutov@yandex.ru>
> >> 
> >> > With the following patch, GDK_SCALE=2 seems to work for me.
> >> >
> >> 
> >> Works for me. Since this is all Cairo-only code, it could even go into
> >> emacs-26, I think (with a ChangeLog and perhaps some comments).
> >
> > OK, let's do that.
> >
> 
> The following patch fixes the scaling problem in Cairo builds.

I pushed this to the emacs-26 branch, thanks.

Not sure there was a consensus about this part:

> The
> scrolling issue with side-by-side windows is in master branch (commit
> 6e362a32bc9d21f73a0f29ca6f45481edeea6f29), and can be cherry-picked.

Thoughts?

bug#33442: 26.1.90; Cairo side-by-side windows scrolling fix should be cherry-picked

[Dmitry Gutov]

On 08.12.2018 11:55, Eli Zaretskii wrote:
> Not sure there was a consensus about this part:
> 
>> The
>> scrolling issue with side-by-side windows is in master branch (commit
>> 6e362a32bc9d21f73a0f29ca6f45481edeea6f29), and can be cherry-picked.
> Thoughts?

Yes?

https://debbugs.gnu.org/cgi/bugreport.cgi?bug=33442#47

bug#33442: 26.1.90; Cairo side-by-side windows scrolling fix should be cherry-picked

[Eli Zaretskii]

> Cc: rpluim@gmail.com, 33442@debbugs.gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Sat, 8 Dec 2018 12:42:29 +0200
> 
> On 08.12.2018 11:55, Eli Zaretskii wrote:
> > Not sure there was a consensus about this part:
> > 
> >> The
> >> scrolling issue with side-by-side windows is in master branch (commit
> >> 6e362a32bc9d21f73a0f29ca6f45481edeea6f29), and can be cherry-picked.
> > Thoughts?
> 
> Yes?
> 
> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=33442#47

That was about scaling, no?  And Robert only replied to the scaling
part, AFAIU.

Why is side-by-side scrolling important enough to get it in emacs-26?

bug#33442: 26.1.90; Cairo side-by-side windows scrolling fix should be cherry-picked

[Dmitry Gutov]

On 08.12.2018 13:15, Eli Zaretskii wrote:

>> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=33442#47
> 
> That was about scaling, no?

In part it was about "so what if the scaling is broken".

> Why is side-by-side scrolling important enough to get it in emacs-26?

You mean why 'C-x 3 C-v C-v C-v' should work? Seems like a basic 
functionality.

bug#33442: 26.1.90; Cairo side-by-side windows scrolling fix should be cherry-picked

[Eli Zaretskii]

> Cc: ari.roponen@gmail.com, rpluim@gmail.com, 33442@debbugs.gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Sat, 8 Dec 2018 15:03:12 +0200
> 
> On 08.12.2018 13:15, Eli Zaretskii wrote:
> 
> >> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=33442#47
> > 
> > That was about scaling, no?
> 
> In part it was about "so what if the scaling is broken".
> 
> > Why is side-by-side scrolling important enough to get it in emacs-26?
> 
> You mean why 'C-x 3 C-v C-v C-v' should work? Seems like a basic 
> functionality.

Yes, and it works on master.  And never worked before since the code
was written.  I was asking why it has to be on emacs-26, and hoped for
responses that take the pros and cons into consideration and show how
the pros win over cons.

bug#33442: 26.1.90; Cairo side-by-side windows scrolling fix should be cherry-picked

[Dmitry Gutov]

On 08.12.2018 16:24, Eli Zaretskii wrote:

> And never worked before since the code
> was written.

If that is true, I have no strong arguments for why it "has to" be on 
emacs-26.

> I was asking why it has to be on emacs-26, and hoped for
> responses that take the pros and cons into consideration and show how
> the pros win over cons.

But I'm not seeing any cons either. It's not like there are any 
plausible Cairo build users that are fine with the current state of 
emacs-26 but would get annoyed by any possible regression that the patch 
in question might introduce.

Anyway, it seems I've already made all the applicable arguments at the 
beginning of this discussion. So I'll stop here.

bug#33442: 26.1.90; Cairo side-by-side windows scrolling fix should be cherry-picked

[Robert Pluim]

Dmitry Gutov <dgutov@yandex.ru> writes:

> On 08.12.2018 16:24, Eli Zaretskii wrote:
>
>> And never worked before since the code
>> was written.
>
> If that is true, I have no strong arguments for why it "has to" be on
> emacs-26.
>
>> I was asking why it has to be on emacs-26, and hoped for
>> responses that take the pros and cons into consideration and show how
>> the pros win over cons.
>
> But I'm not seeing any cons either. It's not like there are any
> plausible Cairo build users that are fine with the current state of
> emacs-26 but would get annoyed by any possible regression that the
> patch in question might introduce.
>
> Anyway, it seems I've already made all the applicable arguments at the
> beginning of this discussion. So I'll stop here.

I thought we were in a state on emacs-26 where we can get away with
cherry-picking minor fixes like the side-by-side stuff, precisely
because cairo is disabled by default.  Also if any brave soul does
turn it on on emacs-26, we should probably strive to have fixed things
for them that are easy to fix.

On a separate note, should we turn cairo on by default in master? It
will still only get compiled for people who have the appropriate
development packages installed.

Robert

bug#33442: 26.1.90; Cairo side-by-side windows scrolling fix should be cherry-picked

[Eli Zaretskii]

> From: Robert Pluim <rpluim@gmail.com>
> Cc: Eli Zaretskii <eliz@gnu.org>,  ari.roponen@gmail.com,  33442@debbugs.gnu.org
> Date: Sun, 09 Dec 2018 23:08:06 +0100
> 
> Dmitry Gutov <dgutov@yandex.ru> writes:
> 
> > On 08.12.2018 16:24, Eli Zaretskii wrote:
> >
> >> And never worked before since the code
> >> was written.
> >
> > If that is true, I have no strong arguments for why it "has to" be on
> > emacs-26.
> >
> >> I was asking why it has to be on emacs-26, and hoped for
> >> responses that take the pros and cons into consideration and show how
> >> the pros win over cons.
> >
> > But I'm not seeing any cons either. It's not like there are any
> > plausible Cairo build users that are fine with the current state of
> > emacs-26 but would get annoyed by any possible regression that the
> > patch in question might introduce.
> >
> > Anyway, it seems I've already made all the applicable arguments at the
> > beginning of this discussion. So I'll stop here.
> 
> I thought we were in a state on emacs-26 where we can get away with
> cherry-picking minor fixes like the side-by-side stuff, precisely
> because cairo is disabled by default.  Also if any brave soul does
> turn it on on emacs-26, we should probably strive to have fixed things
> for them that are easy to fix.

OK, please cherry-pick that part as well.

> On a separate note, should we turn cairo on by default in master?

I have no strong opinion on this.  IMO, the decision should be based
on what those who use Cairo say about its stability.  I'd also
encourage people to see whether the reported bugs are still there, or
maybe they were solved indirectly.

bug#33442: 26.1.90; Cairo side-by-side windows scrolling fix should be cherry-picked

[Robert Pluim]

tags 33442 fixed
close 33442 26.2
quit

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Robert Pluim <rpluim@gmail.com>
>> I thought we were in a state on emacs-26 where we can get away with
>> cherry-picking minor fixes like the side-by-side stuff, precisely
>> because cairo is disabled by default.  Also if any brave soul does
>> turn it on on emacs-26, we should probably strive to have fixed things
>> for them that are easy to fix.
>
> OK, please cherry-pick that part as well.

Done as 0220391c00

Closing this bug.

>> On a separate note, should we turn cairo on by default in master?
>
> I have no strong opinion on this.  IMO, the decision should be based
> on what those who use Cairo say about its stability.  I'd also
> encourage people to see whether the reported bugs are still there, or
> maybe they were solved indirectly.

I donʼt use it myself at the moment. Iʼve only seen Ari report that he
uses is regularly.

Robert

bug#33442: 26.1.90; Cairo side-by-side windows scrolling fix should be cherry-picked

[Dmitry Gutov]

On 10.12.2018 8:20, Eli Zaretskii wrote:

>> On a separate note, should we turn cairo on by default in master?
> 
> I have no strong opinion on this.  IMO, the decision should be based
> on what those who use Cairo say about its stability.  I'd also
> encourage people to see whether the reported bugs are still there, or
> maybe they were solved indirectly.

I won't presume to speak about stability, but I've tried whatever 
related bug reports I could find, and most seem fixed (bug#28236 being 
the exception).

bug#33442: 26.1.90; Cairo side-by-side windows scrolling fix should be cherry-picked

[Dmitry Gutov]

On 11.12.2018 4:33, Dmitry Gutov wrote:
> bug#28236 being the exception

...and the font rendering difference mentioned in bug#23925.

bug#33442: 26.1.90; Cairo side-by-side windows scrolling fix should be cherry-picked

[Eli Zaretskii]

> From: Dmitry Gutov <dgutov@yandex.ru>
> Cc: ari.roponen@gmail.com, 33442@debbugs.gnu.org
> Date: Tue, 11 Dec 2018 05:37:34 +0200
> 
> On 11.12.2018 4:33, Dmitry Gutov wrote:
> > bug#28236 being the exception
> 
> ...and the font rendering difference mentioned in bug#23925.

Good to know, thanks.  I think 28236 is important enough to try to
solve it before we re-enable Cairo by default.

bug#33442: 26.1.90; Cairo side-by-side windows scrolling fix should be cherry-picked

[Eli Zaretskii]

> Cc: ari.roponen@gmail.com, 33442@debbugs.gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Tue, 11 Dec 2018 04:33:21 +0200
> 
> On 10.12.2018 8:20, Eli Zaretskii wrote:
> 
> >> On a separate note, should we turn cairo on by default in master?
> > 
> > I have no strong opinion on this.  IMO, the decision should be based
> > on what those who use Cairo say about its stability.  I'd also
> > encourage people to see whether the reported bugs are still there, or
> > maybe they were solved indirectly.
> 
> I won't presume to speak about stability, but I've tried whatever 
> related bug reports I could find, and most seem fixed (bug#28236 being 
> the exception).

Thanks.

bug#33442: 26.1.90; Cairo side-by-side windows scrolling fix should be cherry-picked

[Dmitry Gutov]

On 29.11.2018 14:15, Ari Roponen wrote:

> With the following patch, GDK_SCALE=2 seems to work for me.

Works for me as well. Please install it into master, at least.

Thank you!