unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
* Cairo branch.
@ 2015-02-11 15:16 Jan Djärv
  2015-02-11 21:49 ` Stefan Monnier
  0 siblings, 1 reply; 9+ messages in thread
From: Jan Djärv @ 2015-02-11 15:16 UTC (permalink / raw)
  To: emacs-devel

Hi.

I have pushed a cairo branch.

	Jan D.



^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: Cairo branch.
  2015-02-11 15:16 Cairo branch Jan Djärv
@ 2015-02-11 21:49 ` Stefan Monnier
  2015-02-12 15:01   ` Jan D.
  0 siblings, 1 reply; 9+ messages in thread
From: Stefan Monnier @ 2015-02-11 21:49 UTC (permalink / raw)
  To: Jan Djärv; +Cc: emacs-devel

> I have pushed a cairo branch.

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


        Stefan



^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: Cairo branch.
  2015-02-11 21:49 ` Stefan Monnier
@ 2015-02-12 15:01   ` Jan D.
  2015-02-12 16:04     ` Eli Zaretskii
  2015-02-12 16:18     ` Stefan Monnier
  0 siblings, 2 replies; 9+ messages in thread
From: Jan D. @ 2015-02-12 15:01 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: emacs-devel

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.




^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: Cairo branch.
  2015-02-12 15:01   ` Jan D.
@ 2015-02-12 16:04     ` Eli Zaretskii
  2015-02-12 19:17       ` Jan D.
  2015-02-12 16:18     ` Stefan Monnier
  1 sibling, 1 reply; 9+ messages in thread
From: Eli Zaretskii @ 2015-02-12 16:04 UTC (permalink / raw)
  To: Jan D.; +Cc: monnier, emacs-devel

> 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.



^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: Cairo branch.
  2015-02-12 15:01   ` Jan D.
  2015-02-12 16:04     ` Eli Zaretskii
@ 2015-02-12 16:18     ` Stefan Monnier
  2015-02-12 19:20       ` Jan D.
  1 sibling, 1 reply; 9+ messages in thread
From: Stefan Monnier @ 2015-02-12 16:18 UTC (permalink / raw)
  To: Jan D.; +Cc: emacs-devel

> 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



^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: Cairo branch.
  2015-02-12 16:04     ` Eli Zaretskii
@ 2015-02-12 19:17       ` Jan D.
  2015-02-12 20:06         ` Eli Zaretskii
  0 siblings, 1 reply; 9+ messages in thread
From: Jan D. @ 2015-02-12 19:17 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: monnier, emacs-devel

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.





^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: Cairo branch.
  2015-02-12 16:18     ` Stefan Monnier
@ 2015-02-12 19:20       ` Jan D.
  0 siblings, 0 replies; 9+ messages in thread
From: Jan D. @ 2015-02-12 19:20 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: emacs-devel


> 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.




^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: Cairo branch.
  2015-02-12 19:17       ` Jan D.
@ 2015-02-12 20:06         ` Eli Zaretskii
  2015-02-12 20:51           ` Jan D.
  0 siblings, 1 reply; 9+ messages in thread
From: Eli Zaretskii @ 2015-02-12 20:06 UTC (permalink / raw)
  To: Jan D.; +Cc: monnier, emacs-devel

> 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.



^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: Cairo branch.
  2015-02-12 20:06         ` Eli Zaretskii
@ 2015-02-12 20:51           ` Jan D.
  0 siblings, 0 replies; 9+ messages in thread
From: Jan D. @ 2015-02-12 20:51 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: monnier, emacs-devel

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.




^ permalink raw reply	[flat|nested] 9+ messages in thread

end of thread, other threads:[~2015-02-12 20:51 UTC | newest]

Thread overview: 9+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2015-02-11 15:16 Cairo branch Jan Djärv
2015-02-11 21:49 ` Stefan Monnier
2015-02-12 15:01   ` Jan D.
2015-02-12 16:04     ` Eli Zaretskii
2015-02-12 19:17       ` Jan D.
2015-02-12 20:06         ` Eli Zaretskii
2015-02-12 20:51           ` Jan D.
2015-02-12 16:18     ` Stefan Monnier
2015-02-12 19:20       ` Jan D.

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).