Some observations about --with-cairo

Some observations about --with-cairo

[David Kastrup]

[-- Attachment #1: Type: text/plain, Size: 344 bytes --]


Well, just out of interest, I compiled emacs using --with-cairo.
Redraws are unusably slow and partly incorrect and font display is
pretty bad.

That being said,
M-: (with-temp-file "/tmp/frame.pdf" (insert (x-export-frames)))

as a screen dump is, well, interesting.

I append a resulting file from using this in an Info buffer with images.


[-- Attachment #2: frame.pdf --]
[-- Type: application/pdf, Size: 35936 bytes --]

[-- Attachment #3: Type: text/plain, Size: 564 bytes --]


If you take a look at it in a PDF viewer, you'll notice that the fonts
from this frame dump scale to arbitrary size, in contrast to the
included PNG image.

This could be an interesting starting angle for creating a manual with
included images/screens that do not suffer from rasterization.  Since
the corresponding fonts would likely be included only once, such
"graphics" would actually require very little actual space in the PDF
file.

Also, one could copy&paste from the frames in such a manual, in contrast
to actual raster screen dumps.

-- 
David Kastrup

Re: Some observations about --with-cairo

[Clément Pit-Claudel]

On 2017-06-04 22:03, David Kastrup wrote:
> Well, just out of interest, I compiled emacs using --with-cairo.
> Redraws are unusably slow and partly incorrect and font display is
> pretty bad.
> 
> That being said,
> M-: (with-temp-file "/tmp/frame.pdf" (insert (x-export-frames)))
> as a screen dump is, well, interesting.
> I append a resulting file from using this in an Info buffer with images.

Beautiful!
Is anyone currently working on improving Cairo support?  Is there a roadmap / task list somewhere?

> Also, one could copy&paste from the frames in such a manual, in contrast
> to actual raster screen dumps.

Indeed, except for the usual problem with indentation and spaces being lost.

Clément.

Re: Some observations about --with-cairo

[Noam Postavsky]

On Sun, Sep 24, 2017 at 10:11 AM, Clément Pit-Claudel
<cpitclaudel@gmail.com> wrote:
> Is anyone currently working on improving Cairo support?

No, as far as I know.

> Is there a roadmap / task list somewhere?

There are several open bugs:
https://debbugs.gnu.org/cgi/pkgreport.cgi?package=emacs;include=subject%3Acairo

Re: Some observations about --with-cairo

[Robert Pluim]

Noam Postavsky <npostavs@users.sourceforge.net> writes:

> On Sun, Sep 24, 2017 at 10:11 AM, Clément Pit-Claudel
> <cpitclaudel@gmail.com> wrote:
>> Is anyone currently working on improving Cairo support?
>
> No, as far as I know.
>
>> Is there a roadmap / task list somewhere?
>
> There are several open bugs:
> https://debbugs.gnu.org/cgi/pkgreport.cgi?package=emacs;include=subject%3Acairo

One bug not on that list is
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=20890 which I run into
every time I try a --with-cairo build. It was reported more than two
years ago, any chance of a fix?

Re: Some observations about --with-cairo

[Noam Postavsky]

On Mon, Sep 25, 2017 at 10:12 AM, Robert Pluim <rpluim@gmail.com> wrote:
>> There are several open bugs:
>> https://debbugs.gnu.org/cgi/pkgreport.cgi?package=emacs;include=subject%3Acairo
>
> One bug not on that list is
> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=20890 which I run into
> every time I try a --with-cairo build.

Oh, retitled so it's on the list now.

> It was reported more than two
> years ago, any chance of a fix?

I mean, there is always *some* chance, but since the number of people
working on Cairo support is the same as it was 2 years ago (i.e.,
zero), I wouldn't hold my breath...

Re: Some observations about --with-cairo

[YAMAMOTO Mitsuharu]

>>>>> On Sun, 24 Sep 2017 16:11:14 +0200, Clément Pit-Claudel <cpitclaudel@gmail.com> said:

> On 2017-06-04 22:03, David Kastrup wrote:
>> Well, just out of interest, I compiled emacs using --with-cairo.
>> Redraws are unusably slow and partly incorrect and font display is
>> pretty bad.
>> 
>> That being said, M-: (with-temp-file "/tmp/frame.pdf" (insert
>> (x-export-frames))) as a screen dump is, well, interesting.  I
>> append a resulting file from using this in an Info buffer with
>> images.

> Beautiful!  Is anyone currently working on improving Cairo support?
> Is there a roadmap / task list somewhere?

Roughly speaking, the current cairo code is based on my old code in

  http://lists.gnu.org/archive/html/emacs-devel/2009-04/msg00096.html

and Jan's double-buffering code that draws into an image surface.  I
think a possible next step would be to see if one can drop the latter
and use Daniel's Xdbe code instead as in the Xlib version.  If this
works, then it will make the cairo code simpler and more maintainable.

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp

Re: Some observations about --with-cairo

[Eli Zaretskii]

> Date: Tue, 26 Sep 2017 19:13:09 +0900
> From: YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp>
> Cc: emacs-devel@gnu.org
> 
> > Is there a roadmap / task list somewhere?
> 
> Roughly speaking, the current cairo code is based on my old code in
> 
>   http://lists.gnu.org/archive/html/emacs-devel/2009-04/msg00096.html
> 
> and Jan's double-buffering code that draws into an image surface.  I
> think a possible next step would be to see if one can drop the latter
> and use Daniel's Xdbe code instead as in the Xlib version.  If this
> works, then it will make the cairo code simpler and more maintainable.

I'm okay with going with your proposal, but please note that XDBE
support has a few bugs of its own, which are not being worked on
either.  So, while going with your proposal would probably make
maintenance easier, my main concern is that I don't currently see
anyone maintaining either of these two features, at least not as far
as fixing known bugs is concerned.

So I'm not sure your proposal will improve the situation with the bugs
related to these 2 features, unfortunately.  And without fixing these
bugs, we cannot in good faith claim these features are supported as
everything else in Emacs is.