For whatever it is worth, I checked out the branch
origin/old-branches/cairo compiled it and it seemed to work just fine under
Fedora 24. I couldn't reproduce either of the bugs #20997 nor #23925.

In any case these two bugs both discuss refresh issues, which is outside of
the scope of cairo which is a rendering engine.

My feeling is that the only issue in the bug tracker that you may need an
"cairo expert" for, is the memory leak in #22961. The rest of the bugs are
more related to exposure triggered redraws and interaction with the window
manager. These are certainly related to the cairo branch, but have nothing
to do with cairo per se.

Regards,
Dov


On Thu, Oct 20, 2016 at 6:42 PM, Eli Zaretskii <eliz@gnu.org> wrote:

> > Date: Thu, 20 Oct 2016 11:15:27 -0400
> > From: "Perry E. Metzger" <perry@piermont.com>
> > Cc: rekado@elephly.net, jwiegley@gmail.com, emacs-devel@gnu.org,
> >  rms@gnu.org, monnier@iro.umontreal.ca
> >
> > (There are four front ends now, right? MS Windows, X, NextStep and
> > tty, yes?)
>
> Yes.  Although the TTY back-end has some quirks in the MS-Windows
> build, because termcap/terminfo is not supported by the Windows
> console (or wasn't until Windows 10.1).
>
> > Is there any documentation about the internal interfaces between the
> > terminal layer and the back end?
>
> Look at 'struct redisplay_interface' (for X it gets populated around
> line 12470 of xterm.c) and at hooks in 'struct terminal' (populated
> for X in x_create_terminal).  TTYs don't have 'struct
> redisplay_interface' (for historical reasons), but instead call the
> corresponding functions directly.
>
> > I doubt I'm skilled enough in something like Wayland to do this work
> > but I'd like to get a bit of a sense of how awful the work is.
>
> Thanks for trying.
>
> > And what *did* happen to the Cairo stuff?
>
> I has bugs that we cannot fix because no one knowns enough about Cairo
> drawing.  The person who wrote the code left the Emacs development
> short time after merging the code.
>
> > Cairo would make Wayland easy if I recall correctly.
>
> That was the idea behind introducing it.
>
> > > IMO, working on that is much more important for the future of Emacs
> > > than any other improvements, including, but not limited to, the
> > > "future of Emacs Lisp" discussions, the "feature/integrated-elpa"
> > > discussions, etc.  Developing Emacs without first-class experts on X
> > > on board makes no sense to me.
> >
> > Perhaps no first class experts in the area are aware that Emacs needs
> > the help?
>
> Perhaps.
>
>