Cairo branch.

Cairo branch.

[Jan Djärv]

Hi.

I have pushed a cairo branch.

	Jan D.

Re: Cairo branch.

[Stefan Monnier]

> I have pushed a cairo branch.

Can you give a short summary of what it brings (and/or what it could
bring)?


        Stefan

Re: Cairo branch.

[Jan D.]

Stefan Monnier skrev den 2015-02-11 22:49:
>> I have pushed a cairo branch.
>
> Can you give a short summary of what it brings (and/or what it could
> bring)?
>


YAMAMOTO Mitsuharu made the patch to demonstrate printing, so that is 
new (see x-print-frames-dialog or the Printing section in xfns.c).

Otherwise it is just a step to keep up with the times, i.e. server side 
(as in X11 server) rendering is going away as it seems.  So Emacs must 
at some point develop client side (cairo) rendering.

It could form a basis for porting to other window systems like Wayland, 
that has no rendering of its own, but relies on cairo.  That takes more 
effort, the cairo branch is X only.  Note that porting to Wayland isn't 
as simple as switching rendering, the whole event handling must be 
implemented.

As for user visible changes, there is nothing, except printing.  The 
current X rendering is still better, for speed and image support.
Image support when using cairo is lacking, PNG only.  Work needs to be 
done here (hint, hint :-).

I think using cairo and going double buffer in Emacs is easier than 
making X double buffered.  The main obstacle to double buffering is the 
way Emacs does redraw, i.e. not in the GUI loop, but outside it.  This 
is tricky to change, as there are lots of flags in the redraw code that 
gets set and reset at various points.  Figuring all that stuff out is 
not easy.

	Jan D.

Re: Cairo branch.

[Eli Zaretskii]

> Date: Thu, 12 Feb 2015 16:01:11 +0100
> From: "Jan D." <jan.h.d@swipnet.se>
> Cc: emacs-devel@gnu.org
> 
> YAMAMOTO Mitsuharu made the patch to demonstrate printing, so that is 
> new (see x-print-frames-dialog or the Printing section in xfns.c).
> 
> Otherwise it is just a step to keep up with the times, i.e. server side 
> (as in X11 server) rendering is going away as it seems.  So Emacs must 
> at some point develop client side (cairo) rendering.

Is the intent to use Cairo alone, or also use Pango?

If the latter, then one problem we'd need to figure out is what to do
with bidirectional display, since AFAIR Pango does its own reordering.

Another interesting issue is whether we want to use Cairo on Windows
as well, and eventually drop the w32-specific display back-end.

Re: Cairo branch.

[Jan D.]

Hi.

> 12 feb 2015 kl. 17:04 skrev Eli Zaretskii <eliz@gnu.org>:
> 
>> Date: Thu, 12 Feb 2015 16:01:11 +0100
>> From: "Jan D." <jan.h.d@swipnet.se>
>> Cc: emacs-devel@gnu.org
>> 
>> YAMAMOTO Mitsuharu made the patch to demonstrate printing, so that is 
>> new (see x-print-frames-dialog or the Printing section in xfns.c).
>> 
>> Otherwise it is just a step to keep up with the times, i.e. server side 
>> (as in X11 server) rendering is going away as it seems.  So Emacs must 
>> at some point develop client side (cairo) rendering.
> 
> Is the intent to use Cairo alone, or also use Pango?

Cairo alone.  We use the normal font backend stuff, there is a new one for cairo (ftcrfont.c), based on the Freetype backend (ftfont.c).

> 
> If the latter, then one problem we'd need to figure out is what to do
> with bidirectional display, since AFAIR Pango does its own reordering.
> 
> Another interesting issue is whether we want to use Cairo on Windows
> as well, and eventually drop the w32-specific display back-end.

You have to separate the event and system interaction from the rendering in w32, but also in the X backend so to have a pure resuable cairo rendering code base.  Right now its all kind of mixed in.

	Jan D.

Re: Cairo branch.

[Eli Zaretskii]

> From: "Jan D." <jan.h.d@swipnet.se>
> Date: Thu, 12 Feb 2015 20:17:34 +0100
> Cc: monnier@iro.umontreal.ca,
>  emacs-devel@gnu.org
> 
> > Another interesting issue is whether we want to use Cairo on Windows
> > as well, and eventually drop the w32-specific display back-end.
> 
> You have to separate the event and system interaction from the rendering in w32, but also in the X backend so to have a pure resuable cairo rendering code base.  Right now its all kind of mixed in.

Not sure I'm following: could you elaborate about them being mixed?  I
seem to remember that they are separate, at least in w32.  In
particular, event input is in a separate thread, while drawing happens
in the main thread, I think.

Re: Cairo branch.

[Jan D.]

Hi.

> 12 feb 2015 kl. 21:06 skrev Eli Zaretskii <eliz@gnu.org>:
> 
>> From: "Jan D." <jan.h.d@swipnet.se>
>> Date: Thu, 12 Feb 2015 20:17:34 +0100
>> Cc: monnier@iro.umontreal.ca,
>> emacs-devel@gnu.org
>> 
>>> Another interesting issue is whether we want to use Cairo on Windows
>>> as well, and eventually drop the w32-specific display back-end.
>> 
>> You have to separate the event and system interaction from the rendering in w32, but also in the X backend so to have a pure resuable cairo rendering code base.  Right now its all kind of mixed in.
> 
> Not sure I'm following: could you elaborate about them being mixed?  I
> seem to remember that they are separate, at least in w32.  In
> particular, event input is in a separate thread, while drawing happens
> in the main thread, I think.

The rendering code and the event handling code are in the same file usually (XXterm.c).
They might be logically separated or logically independent.  We are also using GC:s in the core drawing routines, or an emulation of GC:s, but they are really an X system thing.  There are other X-isms that a pure renderer has to deal with.

	Jan D.

Re: Cairo branch.

[Stefan Monnier]

> YAMAMOTO Mitsuharu made the patch to demonstrate printing, so that is new
> (see x-print-frames-dialog or the Printing section in xfns.c).

Oh, yes, I had forgotten about that one.

> Otherwise it is just a step to keep up with the times, i.e. server side (as
> in X11 server) rendering is going away as it seems.  So Emacs must at some
> point develop client side (cairo) rendering.

So, IIUC the effect is to change the underlying code used to *draw* the
actual windows (but not the widgets like menubar, scrollbars, ...).
Does it affect font selection?

> It could form a basis for porting to other window systems like Wayland, that
> has no rendering of its own, but relies on cairo.  That takes more effort,
> the cairo branch is X only.  Note that porting to Wayland isn't as simple as
> switching rendering, the whole event handling must be implemented.

OK.

> I think using cairo and going double buffer in Emacs is easier than making
> X double buffered.  The main obstacle to double buffering is the way Emacs
> does redraw, i.e. not in the GUI loop, but outside it.  This is tricky to
> change, as there are lots of flags in the redraw code that gets set and
> reset at various points.  Figuring all that stuff out is not easy.

I don't understand this part of the code nearly enough to say something
intelligent, but based on my work on the pre-redisplay-function
feature (trying to optimize the set of windows that need to be redrawn),
I think I understand a bit of what you mean.


        Stefan

Re: Cairo branch.

[Jan D.]

> 12 feb 2015 kl. 17:18 skrev Stefan Monnier <monnier@iro.umontreal.ca>:
> 
>> YAMAMOTO Mitsuharu made the patch to demonstrate printing, so that is new
>> (see x-print-frames-dialog or the Printing section in xfns.c).
> 
> Oh, yes, I had forgotten about that one.
> 
>> Otherwise it is just a step to keep up with the times, i.e. server side (as
>> in X11 server) rendering is going away as it seems.  So Emacs must at some
>> point develop client side (cairo) rendering.
> 
> So, IIUC the effect is to change the underlying code used to *draw* the
> actual windows (but not the widgets like menubar, scrollbars, ...).

Yes, draw the text, lines, etc.

> Does it affect font selection?

Not much.  It has its on font backend, but uses Freetype (Xft) fonts like the X backend.
There should be no display difference between cairo and X, they use the same fonts.

	Jan D.