Emacs, QT and Cairo Was: Re: Efforts to attract more users?

Emacs, QT and Cairo Was: Re: Efforts to attract more users?

[Stephen Eilert]

On Mon, Jul 12, 2010 at 2:25 PM, Bernardo Barros
<bernardobarros2@gmail.com> wrote:
> many people in the gnu world are using qt4. are there reasons not to
> consider it?
>

Does it matter?

You see, it is not like Emacs has stretched GTK's capabilities to the
limit. Actually there isn't much being used: menu, the window itself,
scrollbars and a very primitive toolbar (that I always turn off), as
far as I can tell.

What about exposing Cairo bindings (GTK already uses it, so it is not
exactly a new dependency, only the headers) to elisp so that we can
actually draw a prettier user interface? Things like real lines
instead of "-" for the modeline (and a better looking modeline
itself), better looking widgets (the horrendous fake buttons created
by customize, for example), better fringe layer or even, say, an UML
mode with good-looking classes. And perhaps a cute speedbar.

Yes, looks do matter. Most Emacs screenshots look kinda dated and
primitive - and this carries over to the overall perception. I've
added hundreds of lines to my .emacs for looks alone, but I can't draw
something better programatically.


--Stephen

Sent from my Emacs

Re: Emacs, QT and Cairo Was: Re: Efforts to attract more users?

[Chong Yidong]

Stephen Eilert <spedrosa@gmail.com> writes:

> Things like real lines instead of "-" for the modeline (and a better
> looking modeline itself)

FWIW, I don't think the "-"'s are necessary nowadays.  It may be a good
idea to eliminate them.

Re: Emacs, QT and Cairo Was: Re: Efforts to attract more users?

[Chad Brown]

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


On Jul 13, 2010, at 12:29 PM, Chong Yidong wrote:

> Stephen Eilert <spedrosa@gmail.com> writes:
> 
>> Things like real lines instead of "-" for the modeline (and a better
>> looking modeline itself)
> 
> FWIW, I don't think the "-"'s are necessary nowadays.  It may be a good
> idea to eliminate them.

FWIW, I removed them years ago.  I haven't encountered a situation where I've missed them since emacs 20.

*Chad

[-- Attachment #2: Type: text/html, Size: 945 bytes --]

Re: Emacs, QT and Cairo Was: Re: Efforts to attract more users?

[Jan Djärv]

Stephen Eilert skrev 2010-07-13 21.02:
>
> What about exposing Cairo bindings (GTK already uses it, so it is not
> exactly a new dependency, only the headers) to elisp so that we can
> actually draw a prettier user interface?

You would have to have a proper Cairo implementation of Emacs redisplay before 
that can be useful.  There was a patch for it here once.

	Jan D.

Re: Emacs, QT and Cairo

[Chad Brown]

On Jul 13, 2010, at 1:48 PM, Jan Djärv wrote:
> You would have to have a proper Cairo implementation of Emacs redisplay before that can be useful.  There was a patch for it here once.

It would be interesting to see an analysis of emacs' redisplay needs in light of modern cpu/gpu/network usage, or even a list of needs for emacs' redisplay priorities.  I recall the 18->19->20 discussions vaguely, but I'm willing to wager that there are far fewer people using x-terminals over 14.4k modem lines these days.  :-)

A `truly excellent' effort in this space would almost certainly require a huge amount of work from at least one of the already generous/overburdened developers who truly understands the redisplay internals, and I would be surprised to hear that any such feels that they have the free time to devote to such a blue-sky project.  I do wonder if anyone has concrete suggestions for a starting point for some of us `younger' people, though.

Thanks in advance,
*Chad

Re: Emacs, QT and Cairo

[Stephen J. Turnbull]

Chad Brown writes:

 > It would be interesting to see an analysis of emacs' redisplay
 > needs in light of modern cpu/gpu/network usage, or even a list of
 > needs for emacs' redisplay priorities.  I recall the 18->19->20
 > discussions vaguely, but I'm willing to wager that there are far
 > fewer people using x-terminals over 14.4k modem lines these days.
 > :-)

Nowadays redisplay is all about memory and networks.  Forget CPU and
GPU.  Client memory is probably not that important (unless you cache a
lot of off-screen real estate), and even server memory shouldn't be a
problem for Emacs, which makes fairly modest demands (except for glyph
caching if you're using Xft).

I regularly get complaints from people about redisplay over the
network.  The problem as usual is not bandwidth (what is measured by
"14.4k"), but latency.  It's the number of roundtrips that matters,
and modern WANs often have greater average latency than a modem line.
I'm typing this on a link that goes through 10 hosts with IPs to
travel a net of 4.5km, and the performance is, if anything, worse than
the 28.8k modem I used to use; on my sabbatical that was 15-20 hosts
and 10,000km, so speed of light became a factor and it could be awful.
Of course if you've got lots of toolbar icons and suchlike, it takes
more time to upload them to the X server over a 14.4k line, but once
they're uploaded, they generally hang around for a long time since
server memory has expanded enormously.

 > A `truly excellent' effort in this space would almost certainly
 > require a huge amount of work from at least one of the already
 > generous/overburdened developers who truly understands the
 > redisplay internals,

That's not clear (although my opinion may not be accurate since the
XEmacs redisplay is quite different).  For example, one of the tasks
that has a very complicated implementation in the XEmacs redisplay is
drawing the cursor.  But that's because in the basic X protocol you
need to draw things in layers.  It's possible that in a Cairo
implementation some of these things could call out to the RENDER
protocol, which would allow full use of Porter-Duff.  While that would
indeed require somebody to book up on Porter-Duff and probably some
ingenuity in figuring out how to use the 31 (IIRC) composition
operators to achieve minimal roundtrips, this would be quite local,
and not require overall redisplay complexity.

Re: Emacs, QT and Cairo

[Óscar Fuentes]

"Stephen J. Turnbull" <stephen@xemacs.org> writes:

[snip]

> I regularly get complaints from people about redisplay over the
> network.  The problem as usual is not bandwidth (what is measured by
> "14.4k"), but latency.  It's the number of roundtrips that matters,
> and modern WANs often have greater average latency than a modem line.

Using NX improves things a lot. I find it usable over 50 Kbps Internet
connections, with a ping of ~100 ms.

[snip]

Re: Emacs, QT and Cairo

[Eli Zaretskii]

> From: Chad Brown <yandros@MIT.EDU>
> Date: Tue, 13 Jul 2010 15:30:49 -0700
> Cc: Emacs development discussions <emacs-devel@gnu.org>
> 
> 
> On Jul 13, 2010, at 1:48 PM, Jan Djärv wrote:
> > You would have to have a proper Cairo implementation of Emacs redisplay before that can be useful.  There was a patch for it here once.
> 
> It would be interesting to see an analysis of emacs' redisplay needs in light of modern cpu/gpu/network usage, or even a list of needs for emacs' redisplay priorities.  I recall the 18->19->20 discussions vaguely, but I'm willing to wager that there are far fewer people using x-terminals over 14.4k modem lines these days.  :-)

As Stephen wrote, the display optimizations are still relevant.  We
had at least 2 reminders of this lately:

  . Stefan's frustration with his nhexl mode, which somehow succeeds
    to bring the redisplay code to its knees, even on a local
    terminal.

  . Stefan's complaints about the slow-down related to the bidi
    reordering, when there are many frames simultaneously visible on
    the screen.

> A `truly excellent' effort in this space would almost certainly require a huge amount of work from at least one of the already generous/overburdened developers who truly understands the redisplay internals, and I would be surprised to hear that any such feels that they have the free time to devote to such a blue-sky project.

You are looking at the problem from the wrong angle.  For such an
effort to be worth our while, Someone(TM) should first present a
plausible and convincing case for reimplementing the Emacs display
engine.  At the very least, there should be an analysis of the
features we would like to have in Emacs, but cannot add without unduly
large effort, and which are available "for free" in Cairo or other
display engines, or would be available "for free" in the suggested new
implementation of our own.  And the number of these features should be
large enough to provide a "critical mass" sufficient to make the
redesign decision.  Then, and only then, the next step would be to
look for volunteers to do the job.

> I do wonder if anyone has concrete suggestions for a starting point for some of us `younger' people, though.

The starting point is, of course, a thorough study of the current
display engine.

Re: Emacs, QT and Cairo

[Chad Brown]

On Jul 14, 2010, at 12:29 AM, Eli Zaretskii wrote:

>> A `truly excellent' effort in this space would almost certainly require a huge amount of work from at least one of the already generous/overburdened developers who truly understands the redisplay internals, and I would be surprised to hear that any such feels that they have the free time to devote to such a blue-sky project.
> 
> You are looking at the problem from the wrong angle. [...]

> The starting point is, of course, a thorough study of the current
> display engine.

I'm actually not looking at it as a problem to be solved at all, but rather as a blue-sky project to investigate what might be possible with new display toolkits.  By way of example, in past discussions about using systems like (but not exactly) khtml, gecko, or gnome's canvas with emacs, it was suggested that emacs had certain requirements that such systems could not meet.  My guess is that while this is still true to some degree, there might be new systems that could get along with emacs' needs, and that might offer features not currently available to emacs.

Since my above wording might have been unclear, let me try again:  I expect that this request will demand too much time and effort to be viable for the people that already have the expertise required.  I was hoping for some partial effort, such as a document, discussion thread, or short ``as I remember it'' essay that might provide a good starting place.  I was expecting (since this is potentially a lot of effort for a blue-sky project) something more akin to your ``start by thoroughly studying the current display engine''.

Thanks for your time,
*Chad

Re: Emacs, QT and Cairo

[Eli Zaretskii]

> From: Chad Brown <yandros@MIT.EDU>
> Date: Wed, 14 Jul 2010 11:37:09 -0700
> Cc: Emacs development discussions <emacs-devel@gnu.org>
> 
> 
> I'm actually not looking at it as a problem to be solved at all, but rather as a blue-sky project to investigate what might be possible with new display toolkits.  By way of example, in past discussions about using systems like (but not exactly) khtml, gecko, or gnome's canvas with emacs, it was suggested that emacs had certain requirements that such systems could not meet.  My guess is that while this is still true to some degree, there might be new systems that could get along with emacs' needs, and that might offer features not currently available to emacs.

I'm not sure I follow: are you looking for toolkits that can be used
to replace the Emacs display engine, i.e. those toolkits that support
everything Emacs needs and does today?

Re: Emacs, QT and Cairo

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Chad Brown <yandros@MIT.EDU>
>> 
>> I'm actually not looking at it as a problem to be solved at all, but
>> rather as a blue-sky project to investigate what might be possible
>> with new display toolkits.  By way of example, in past discussions
>> about using systems like (but not exactly) khtml, gecko, or gnome's
>> canvas with emacs, it was suggested that emacs had certain
>> requirements that such systems could not meet.

I'm very interested on this. Which are those requirements that gnome's
canvas can not meet? Is it because gnome's canvas has some special
limitations that other systems (such as Qt's Graphics View Framework) do
not suffer?

>> My guess is that while this is still true to some degree, there might
>> be new systems that could get along with emacs' needs, and that might
>> offer features not currently available to emacs.
>
> I'm not sure I follow: are you looking for toolkits that can be used
> to replace the Emacs display engine, i.e. those toolkits that support
> everything Emacs needs and does today?

I think he is looking for something that *expands* what Emacs can do
today. I'm not a GUI guy, but having a display engine that works on a
drawing surface instead of a TTY on steroids would open an entire new
field of posibilities for Emacs.

Re: Emacs and Gnome Canvas (was: Emacs, QT and Cairo)

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Date: Wed, 14 Jul 2010 23:24:03 +0200
> 
> I'm very interested on this. Which are those requirements that gnome's
> canvas can not meet?

To answer that, we need someone with good knowledge of both the
requirements of the Emacs display engine and of the features and
possibilities of the Gnome Canvas library.  Do we have such an
individual?

This white paper:

   http://developer.gnome.org/doc/whitepapers/canvas/canvas.html

gives some initial overview of Canvas, but a more in-depth description
is required to fully understand the impact of using Gnome Canvas as
the Emacs display engine.  A few initial thoughts from someone who is
entirely ignorant about Canvas, based on that white paper (which could
be outdated, since it was written 11 years ago):

 . Canvas seems to need GTK+.  What does this mean for platforms where
   GTK+ is unavailable or not maintained?  What about supporting the
   TTY?  Do these issues mean we will need to keep the existing
   display engine in parallel with the Canvas-based one?

 . The Canvas redisplay runs from the GTK+ idle handlers.  In Emacs,
   the idle loop, in addition to triggering redisplay, also checks for
   input from the keyboard and from subprocesses.  Does this mean that
   part of the input handling will need to be run by GTK+?

 . Canvas redisplay is caused by requests from the application to
   update some "canvas item" when the underlying application's objects
   are modified; these requests are then served when GTK+ idle
   handlers are run.  Emacs display engine works differently: changes
   that require redisplay are not considered until redisplay is
   entered; the "requests" to update the display are implicitly
   recorded in the buffers and in the various related data structures
   (text properties and overlays, display strings, etc.), but not
   explicitly translated to display terms until redisplay time, and as
   an inherent part of redisplay itself.  These two very different
   models will need to be reconciled in some reasonably efficient way.

> > I'm not sure I follow: are you looking for toolkits that can be used
> > to replace the Emacs display engine, i.e. those toolkits that support
> > everything Emacs needs and does today?
> 
> I think he is looking for something that *expands* what Emacs can do
> today.

To be able to expand Emacs you need first be able to do what Emacs
does today.

Re: Emacs and Gnome Canvas

[Jan Djärv]

Eli Zaretskii skrev 2010-07-15 08.55:
>
>   . Canvas seems to need GTK+.  What does this mean for platforms where
>     GTK+ is unavailable or not maintained?  What about supporting the
>     TTY?  Do these issues mean we will need to keep the existing
>     display engine in parallel with the Canvas-based one?

Gtk+ is required, you would have to have a parallel display engine for all 
non-Gtk+ cases.
>
>   . The Canvas redisplay runs from the GTK+ idle handlers.  In Emacs,
>     the idle loop, in addition to triggering redisplay, also checks for
>     input from the keyboard and from subprocesses.  Does this mean that
>     part of the input handling will need to be run by GTK+?

Yes.  Now we run the Gtk+ event loop (or actually not the loop, just a step) 
only when we know there is events pending.  Again, parallel implementation for 
non-Gtk+.  But normal redisplay for Gtk+ also happens in idle handlers.  We 
are in the Gtk+ event loop often enough for this to happen often enough. 
Sometimes though (scroll bars mainly) we force redisplay in Gtk+.  I assume 
you can do that for the Canvas also.

>
>   . Canvas redisplay is caused by requests from the application to
>     update some "canvas item" when the underlying application's objects
>     are modified; these requests are then served when GTK+ idle
>     handlers are run.  Emacs display engine works differently: changes
>     that require redisplay are not considered until redisplay is
>     entered; the "requests" to update the display are implicitly
>     recorded in the buffers and in the various related data structures
>     (text properties and overlays, display strings, etc.), but not
>     explicitly translated to display terms until redisplay time, and as
>     an inherent part of redisplay itself.  These two very different
>     models will need to be reconciled in some reasonably efficient way.

The changes that require redisplay would have to notify the Canvas that things 
changed.  I think this style is more efficient.

But I'm not sure it is the right way to go for Emacs unless Gtk+ can run on 
all platforms now.  Even if it can, do we want Gtk+ look and feel on W32, OSX, 
Nextstep etc.?  TTY is still a separate issue though.

	Jan D.

Re: Emacs and Gnome Canvas

[Jan Djärv]

And besides this, you would have to have a GnomeCanvas per Emacs window.

	Jan D.

Jan Djärv skrev 2010-07-15 09.46:
>
>
> Eli Zaretskii skrev 2010-07-15 08.55:
>>
>> . Canvas seems to need GTK+. What does this mean for platforms where
>> GTK+ is unavailable or not maintained? What about supporting the
>> TTY? Do these issues mean we will need to keep the existing
>> display engine in parallel with the Canvas-based one?
>
> Gtk+ is required, you would have to have a parallel display engine for all
> non-Gtk+ cases.
>>
>> . The Canvas redisplay runs from the GTK+ idle handlers. In Emacs,
>> the idle loop, in addition to triggering redisplay, also checks for
>> input from the keyboard and from subprocesses. Does this mean that
>> part of the input handling will need to be run by GTK+?
>
> Yes. Now we run the Gtk+ event loop (or actually not the loop, just a step)
> only when we know there is events pending. Again, parallel implementation for
> non-Gtk+. But normal redisplay for Gtk+ also happens in idle handlers. We are
> in the Gtk+ event loop often enough for this to happen often enough. Sometimes
> though (scroll bars mainly) we force redisplay in Gtk+. I assume you can do
> that for the Canvas also.
>
>>
>> . Canvas redisplay is caused by requests from the application to
>> update some "canvas item" when the underlying application's objects
>> are modified; these requests are then served when GTK+ idle
>> handlers are run. Emacs display engine works differently: changes
>> that require redisplay are not considered until redisplay is
>> entered; the "requests" to update the display are implicitly
>> recorded in the buffers and in the various related data structures
>> (text properties and overlays, display strings, etc.), but not
>> explicitly translated to display terms until redisplay time, and as
>> an inherent part of redisplay itself. These two very different
>> models will need to be reconciled in some reasonably efficient way.
>
> The changes that require redisplay would have to notify the Canvas that things
> changed. I think this style is more efficient.
>
> But I'm not sure it is the right way to go for Emacs unless Gtk+ can run on
> all platforms now. Even if it can, do we want Gtk+ look and feel on W32, OSX,
> Nextstep etc.? TTY is still a separate issue though.
>
> Jan D.

Re: Emacs and Gnome Canvas

[joakim]

Jan Djärv <jan.h.d@swipnet.se> writes:

> And besides this, you would have to have a GnomeCanvas per Emacs window.

If we are considering new display engines, I think we should have
pluggable display engines.

As a stupid example, consider embedding emacs within emacs, using the
xwidget branch. The embedding emacs can then send a lisp representation
of the buffer to the embedded emacs that will then display it.

Im not saying the above example is the way forward technically, but
having pluggble display engines would be very interesting.

Something similar I'm working on is having Inkscape embedded in
Emacs. Emacs then communicates with Inkscape via dbus.

>
> 	Jan D.
>
> Jan Djärv skrev 2010-07-15 09.46:
>>
>>
>> Eli Zaretskii skrev 2010-07-15 08.55:
>>>
>>> . Canvas seems to need GTK+. What does this mean for platforms where
>>> GTK+ is unavailable or not maintained? What about supporting the
>>> TTY? Do these issues mean we will need to keep the existing
>>> display engine in parallel with the Canvas-based one?
>>
>> Gtk+ is required, you would have to have a parallel display engine for all
>> non-Gtk+ cases.
>>>
>>> . The Canvas redisplay runs from the GTK+ idle handlers. In Emacs,
>>> the idle loop, in addition to triggering redisplay, also checks for
>>> input from the keyboard and from subprocesses. Does this mean that
>>> part of the input handling will need to be run by GTK+?
>>
>> Yes. Now we run the Gtk+ event loop (or actually not the loop, just a step)
>> only when we know there is events pending. Again, parallel implementation for
>> non-Gtk+. But normal redisplay for Gtk+ also happens in idle handlers. We are
>> in the Gtk+ event loop often enough for this to happen often enough. Sometimes
>> though (scroll bars mainly) we force redisplay in Gtk+. I assume you can do
>> that for the Canvas also.
>>
>>>
>>> . Canvas redisplay is caused by requests from the application to
>>> update some "canvas item" when the underlying application's objects
>>> are modified; these requests are then served when GTK+ idle
>>> handlers are run. Emacs display engine works differently: changes
>>> that require redisplay are not considered until redisplay is
>>> entered; the "requests" to update the display are implicitly
>>> recorded in the buffers and in the various related data structures
>>> (text properties and overlays, display strings, etc.), but not
>>> explicitly translated to display terms until redisplay time, and as
>>> an inherent part of redisplay itself. These two very different
>>> models will need to be reconciled in some reasonably efficient way.
>>
>> The changes that require redisplay would have to notify the Canvas that things
>> changed. I think this style is more efficient.
>>
>> But I'm not sure it is the right way to go for Emacs unless Gtk+ can run on
>> all platforms now. Even if it can, do we want Gtk+ look and feel on W32, OSX,
>> Nextstep etc.? TTY is still a separate issue though.
>>
>> Jan D.
>
-- 
Joakim Verona

Re: Emacs and Gnome Canvas

[Eli Zaretskii]

> Date: Thu, 15 Jul 2010 09:53:21 +0200
> From: Jan Djärv <jan.h.d@swipnet.se>
> CC: Óscar Fuentes <ofv@wanadoo.es>, 
>  emacs-devel@gnu.org
> 
> And besides this, you would have to have a GnomeCanvas per Emacs window.

Window or frame?  It sounds like the canvas supports tree-like
objects, and Emacs windows on every frame are organized in a tree.

Re: Emacs and Gnome Canvas

[Jan Djärv]

Eli Zaretskii skrev 2010-07-15 10.40:
>> Date: Thu, 15 Jul 2010 09:53:21 +0200
>> From: Jan Djärv<jan.h.d@swipnet.se>
>> CC: Óscar Fuentes<ofv@wanadoo.es>,
>>   emacs-devel@gnu.org
>>
>> And besides this, you would have to have a GnomeCanvas per Emacs window.
>
> Window or frame?  It sounds like the canvas supports tree-like
> objects, and Emacs windows on every frame are organized in a tree.


You could do that, but then Canvas native scrolling could not be used (think 
split windows).  Maybe it can't be used anyway, I don't know if its native 
scrolling relies on having the whole data rendered.  This would take a lot of 
memory for big buffers.

	Jan D.

Re: Emacs and Gnome Canvas

[Eli Zaretskii]

> Date: Thu, 15 Jul 2010 09:46:36 +0200
> From: Jan Djärv <jan.h.d@swipnet.se>
> CC: Óscar Fuentes <ofv@wanadoo.es>, 
>  emacs-devel@gnu.org
> 
> >   . Canvas redisplay is caused by requests from the application to
> >     update some "canvas item" when the underlying application's objects
> >     are modified; these requests are then served when GTK+ idle
> >     handlers are run.  Emacs display engine works differently: changes
> >     that require redisplay are not considered until redisplay is
> >     entered; the "requests" to update the display are implicitly
> >     recorded in the buffers and in the various related data structures
> >     (text properties and overlays, display strings, etc.), but not
> >     explicitly translated to display terms until redisplay time, and as
> >     an inherent part of redisplay itself.  These two very different
> >     models will need to be reconciled in some reasonably efficient way.
> 
> The changes that require redisplay would have to notify the Canvas that things 
> changed.  I think this style is more efficient.

What do you mean by "changes that require redisplay"?  Suppose a
character was inserted or deleted -- would that need to notify the
Canvas?  How about an arbitrary mouse move?

Re: Emacs and Gnome Canvas

[Jan Djärv]

Eli Zaretskii skrev 2010-07-15 10.38:
>> Date: Thu, 15 Jul 2010 09:46:36 +0200
>> From: Jan Djärv<jan.h.d@swipnet.se>
>> CC: Óscar Fuentes<ofv@wanadoo.es>,
>>   emacs-devel@gnu.org
>>
>>>    . Canvas redisplay is caused by requests from the application to
>>>      update some "canvas item" when the underlying application's objects
>>>      are modified; these requests are then served when GTK+ idle
>>>      handlers are run.  Emacs display engine works differently: changes
>>>      that require redisplay are not considered until redisplay is
>>>      entered; the "requests" to update the display are implicitly
>>>      recorded in the buffers and in the various related data structures
>>>      (text properties and overlays, display strings, etc.), but not
>>>      explicitly translated to display terms until redisplay time, and as
>>>      an inherent part of redisplay itself.  These two very different
>>>      models will need to be reconciled in some reasonably efficient way.
>>
>> The changes that require redisplay would have to notify the Canvas that things
>> changed.  I think this style is more efficient.
>
> What do you mean by "changes that require redisplay"?  Suppose a
> character was inserted or deleted -- would that need to notify the
> Canvas?

Yes.

>  How about an arbitrary mouse move?

If it resulted in a different highlightning of a link, yes.

	Jan D.

>

Re: Emacs and Gnome Canvas

[Eli Zaretskii]

> Date: Thu, 15 Jul 2010 10:48:12 +0200
> From: Jan Djärv <jan.h.d@swipnet.se>
> CC: ofv@wanadoo.es, emacs-devel@gnu.org
> 
> >> The changes that require redisplay would have to notify the Canvas that things
> >> changed.  I think this style is more efficient.
> >
> > What do you mean by "changes that require redisplay"?  Suppose a
> > character was inserted or deleted -- would that need to notify the
> > Canvas?
> 
> Yes.

But the inserted character could be in the portion that is not
displayed at all, in which case it does not "require redisplay".  Who
should decide whether redisplay is necessary?  If that's Emacs, then
it should know a lot about the display layout.  If its the Canvas,
then it should know a lot about what portions of the buffer text are
on the screen.

Besides, this mean a thorough redesign of Emacs objects.  Currently,
they are totally unaware of the display engine, and don't request any
redisplays.  They just modify themselves and that's it.

> >  How about an arbitrary mouse move?
> 
> If it resulted in a different highlightning of a link, yes.

Again, how to know that?  Note that some mouse movements perform
complex operations on Emacs objects, like popping up windows and
frames.

Re: Emacs and Gnome Canvas

[Jan Djärv]

Eli Zaretskii skrev 2010-07-15 10.59:
>> Date: Thu, 15 Jul 2010 10:48:12 +0200
>> From: Jan Djärv<jan.h.d@swipnet.se>
>> CC: ofv@wanadoo.es, emacs-devel@gnu.org
>>
>>>> The changes that require redisplay would have to notify the Canvas that things
>>>> changed.  I think this style is more efficient.
>>>
>>> What do you mean by "changes that require redisplay"?  Suppose a
>>> character was inserted or deleted -- would that need to notify the
>>> Canvas?
>>
>> Yes.
>
> But the inserted character could be in the portion that is not
> displayed at all, in which case it does not "require redisplay".  Who
> should decide whether redisplay is necessary?  If that's Emacs, then
> it should know a lot about the display layout.  If its the Canvas,
> then it should know a lot about what portions of the buffer text are
> on the screen.

You probably have your text in an CanvasItem that has a GtkTextBuffer.  When a 
character is inserted, you insert in to the GtkTextBuffer.  The redisplay part 
is then handeled internally between GtkTextBuffer, GnomeCanvas(Rich)TextItem 
and GnomeCanvas.

As I said, it probably relies on having all text in the GtkTextBuffer.

>
> Besides, this mean a thorough redesign of Emacs objects.  Currently,
> they are totally unaware of the display engine, and don't request any
> redisplays.  They just modify themselves and that's it.
>
>>>   How about an arbitrary mouse move?
>>
>> If it resulted in a different highlightning of a link, yes.
>
> Again, how to know that?  Note that some mouse movements perform
> complex operations on Emacs objects, like popping up windows and
> frames.

Each CanvasItem can have callbacks for mouse move, click, key press and so on. 
  The idea is to have separate CanvasItems for the items that should react to 
mouse events and then register callbacks for those events.  The callback then 
pops up windows or whatever.

It is a more event driven approach, and that in itself is a big modification 
for Emacs which is more sequential in nature.

	Jan D.

Re: Emacs and Gnome Canvas

[Eli Zaretskii]

> Date: Thu, 15 Jul 2010 11:29:29 +0200
> From: Jan Djärv <jan.h.d@swipnet.se>
> CC: ofv@wanadoo.es, emacs-devel@gnu.org
> 
> > But the inserted character could be in the portion that is not
> > displayed at all, in which case it does not "require redisplay".  Who
> > should decide whether redisplay is necessary?  If that's Emacs, then
> > it should know a lot about the display layout.  If its the Canvas,
> > then it should know a lot about what portions of the buffer text are
> > on the screen.
> 
> You probably have your text in an CanvasItem that has a GtkTextBuffer.  When a 
> character is inserted, you insert in to the GtkTextBuffer.  The redisplay part 
> is then handeled internally between GtkTextBuffer, GnomeCanvas(Rich)TextItem 
> and GnomeCanvas.
> 
> As I said, it probably relies on having all text in the GtkTextBuffer.

But GtkTextBuffer needs text with attributes, right?  Currently, we
compute these attributes as part of redisplay, and only for the
displayed portion of the text.  Using GtkTextBuffer, it seems like we
will need to have a part (or an equivalent) of that redisplay code,
which would need to recompute the attributes for _all_ of the text,
after each modification of buffer text?  How can this be fast enough?
E.g., what if I'm viewing a large log file with non-trivial
fontification and clickable parts?

And what about redisplay optimizations?  For example, we now have a
special method that updates a window if the only change is that point
moved.  We don't care _why_ it moved -- there could be any number of
input events that cause this.  However, _determining_ that only point
moved is a non-trivial job, which examines about a dozen conditions on
some internal variables and flags.  Then there's another non-trivial
job: where on screen to move the cursor given the position of point.

If the communications with the Canvas is by means of a GtkTextBuffer,
how can these chores be done?  Won't we need to regenerate the
GtkTextBuffer, or at least its large parts, even when the only change
is point movement?

> >>>   How about an arbitrary mouse move?
> >>
> >> If it resulted in a different highlightning of a link, yes.
> >
> > Again, how to know that?  Note that some mouse movements perform
> > complex operations on Emacs objects, like popping up windows and
> > frames.
> 
> Each CanvasItem can have callbacks for mouse move, click, key press and so on. 
>   The idea is to have separate CanvasItems for the items that should react to 
> mouse events and then register callbacks for those events.  The callback then 
> pops up windows or whatever.

Which means running Lisp from redisplay, something we currently barely
support and generally discourage.

> It is a more event driven approach, and that in itself is a big modification 
> for Emacs which is more sequential in nature.

I understand the approach.  I'm trying to see how this approach can be
used without throwing most of the Emacs design out the window.

Re: Emacs and Gnome Canvas

[Jan Djärv]

Eli Zaretskii skrev 2010-07-15 12.24:
>> Date: Thu, 15 Jul 2010 11:29:29 +0200
>> From: Jan Djärv<jan.h.d@swipnet.se>
>> CC: ofv@wanadoo.es, emacs-devel@gnu.org
>>
>>> But the inserted character could be in the portion that is not
>>> displayed at all, in which case it does not "require redisplay".  Who
>>> should decide whether redisplay is necessary?  If that's Emacs, then
>>> it should know a lot about the display layout.  If its the Canvas,
>>> then it should know a lot about what portions of the buffer text are
>>> on the screen.
>>
>> You probably have your text in an CanvasItem that has a GtkTextBuffer.  When a
>> character is inserted, you insert in to the GtkTextBuffer.  The redisplay part
>> is then handeled internally between GtkTextBuffer, GnomeCanvas(Rich)TextItem
>> and GnomeCanvas.
>>
>> As I said, it probably relies on having all text in the GtkTextBuffer.
>
> But GtkTextBuffer needs text with attributes, right?  Currently, we
> compute these attributes as part of redisplay, and only for the
> displayed portion of the text.  Using GtkTextBuffer, it seems like we
> will need to have a part (or an equivalent) of that redisplay code,
> which would need to recompute the attributes for _all_ of the text,
> after each modification of buffer text?  How can this be fast enough?
> E.g., what if I'm viewing a large log file with non-trivial
> fontification and clickable parts?

If you need to recalculate attributes for the whole buffer because of one 
character was inserted, then that is what you have to do.  But I don't think 
that is the case.  You would have to compute the changes, and only that and 
update your text buffer for the changed part.  You wouldn't have to do 
redisplay all the time just in case something changed (like now), if you 
propagated the change the whole way when it happened.  This is a big 
difference on how Emacs works now.

>
> And what about redisplay optimizations?  For example, we now have a
> special method that updates a window if the only change is that point
> moved.  We don't care _why_ it moved -- there could be any number of
> input events that cause this.  However, _determining_ that only point
> moved is a non-trivial job, which examines about a dozen conditions on
> some internal variables and flags.  Then there's another non-trivial
> job: where on screen to move the cursor given the position of point.
>
> If the communications with the Canvas is by means of a GtkTextBuffer,
> how can these chores be done?  Won't we need to regenerate the
> GtkTextBuffer, or at least its large parts, even when the only change
> is point movement?

The communication with the Canvas is through CanvasItems (lines, text, images, 
and so on).  Only the text item uses GtkTextBuffer.  The text canvas item 
keeps track of the insertion point itself.  You would move out the whole 
cursor movement, text insertion, copy/paste, ... to the canvas item.  Move the 
lowlevel stuff handling to the Canvas components.

	Jan D.

Re: Emacs and Gnome Canvas

[Eli Zaretskii]

> Date: Thu, 15 Jul 2010 12:54:14 +0200
> From: Jan Djärv <jan.h.d@swipnet.se>
> Cc: ofv@wanadoo.es, emacs-devel@gnu.org
> 
> >> As I said, it probably relies on having all text in the GtkTextBuffer.
> >
> > But GtkTextBuffer needs text with attributes, right?  Currently, we
> > compute these attributes as part of redisplay, and only for the
> > displayed portion of the text.  Using GtkTextBuffer, it seems like we
> > will need to have a part (or an equivalent) of that redisplay code,
> > which would need to recompute the attributes for _all_ of the text,
> > after each modification of buffer text?  How can this be fast enough?
> > E.g., what if I'm viewing a large log file with non-trivial
> > fontification and clickable parts?
> 
> If you need to recalculate attributes for the whole buffer because of one 
> character was inserted, then that is what you have to do.  But I don't think 
> that is the case.  You would have to compute the changes, and only that and 
> update your text buffer for the changed part.

Inserting one character moves all the attributes after it by one
character position, doesn't it?

> You wouldn't have to do redisplay all the time just in case
> something changed (like now)

?? We don't _do_ redisplay now all the time.  We _enter_ redisplay
every time Emacs is idle, but if nothing's changed, we exit it almost
immediately, after testing a bunch of flags.

> if you propagated the change the whole way when it happened.  This
> is a big difference on how Emacs works now.

The way it looks, parts of the current redisplay code will have to run
whenever there's a change, any change, to some buffer or some related
data structure.  If the parts affected by these changes are not
displayed, or become not displayed before the GTK+ idle handlers run,
propagating those changes would be a waste of CPU cycles.

So you win some and you lose some.  Not sure about the balance.
Basically, scrolling should be very fast (assuming it is done entirely
on the Canvas side), but I'm not sure if everything else won't be
significantly slower.

Re: Emacs and Gnome Canvas

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

[snip]

Thanks Eli and Jan for your comments.

From your discussion it seems that the only serious "problem" with Emacs
and Gnome's canvas (or any other canvas) is coupling the Emacs display
system with it. AFAIK the display system have evolved from the tty one
by incremental updates, which makes it very complex and hard to
maintain. My plan is radical: bypass the current Emacs display system
and implement a new one on top of the canvas. This would be purely
event-driven, hopefully with very little special cases for the platforms
where Emacs runs, and substantially simpler because the canvas would
take care of the low level chores.

On the long term, this could allow to remove the GUI code from the current
display system and left the tty code alone.

If the display system is decoupled from the buffer-handling code, the
high-level event system (Elisp hooks, etc) and the rest of Emacs in
general, it could be doable with a reasonable amount of work for a
single developer. Maybe I'm being too optimistic.

Re: Emacs and Gnome Canvas

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Date: Thu, 15 Jul 2010 16:18:47 +0200
> 
> From your discussion it seems that the only serious "problem" with Emacs
> and Gnome's canvas (or any other canvas) is coupling the Emacs display
> system with it.

I wish!  That was just the first thing on my mind after reading that
white paper.  The tip of the iceberg, so to say.  There are other
"lesser" considerations, that are nevertheless quite serious and
should be considered up front.

I already mentioned the fact that input processing and the whole logic
of the Emacs idle loop will need to be reconsidered and modified.  A
few more examples of the issues that need to be considered:

  . We represent characters as a super-set of Unicode, using upper
    planes for characters that are not unified (for cultural reasons)
    and eight-bit raw bytes.  I'm quite sure Canvas can deal with
    UTF-8 encoded characters, but what will it do with codepoints that
    extend Unicode?  How to tell it which fonts to use for them and
    how to interpret them in general?

  . Display of composed characters.  Emacs specifies compositions via
    either (a) text properties or (b) char-tables.  I'm quite sure
    that display of composed character is supported by Canvas, but how
    to we communicate the above two types of specifications from Emacs
    to Canvas?

  . Jan says we need to maintain a GtkTextBuffer object for every
    buffer we have in Emacs.  Does that mean buffer text will be held
    twice in memory, once as it is today, the other as GtkTextBuffer?
    What will that do to Emacs's ability to visit very large files?
    Even today there's demand to be able to visit files that are 1GB
    or 2GB in size.  Doubling that would be a serious impediment.

    Or maybe you are thinking about _replacing_ buffer text with
    GtkTextBuffer?  That would mean you'd need to redesign buffer
    management code.

And those are just examples.

> My plan is radical: bypass the current Emacs display system
> and implement a new one on top of the canvas. This would be purely
> event-driven, hopefully with very little special cases for the platforms
> where Emacs runs, and substantially simpler because the canvas would
> take care of the low level chores.
> 
> On the long term, this could allow to remove the GUI code from the current
> display system and left the tty code alone.
> 
> If the display system is decoupled from the buffer-handling code, the
> high-level event system (Elisp hooks, etc) and the rest of Emacs in
> general, it could be doable with a reasonable amount of work for a
> single developer. Maybe I'm being too optimistic.

I hope you are not overly optimistic, and I wish you success.  I
really do.  But because there's no formal specification of the Emacs
display system, you have no exhaustive list of requirements which you
will need to implement.  May I suggest to begin with some process of
requirements capture?  That would at least allow to produce some kind
of plan, identify the possible difficulties, and outline ways of
overcoming them.  Note that doing what you want will touch not only
the display, but also all of the basic objects and probably change
quite a lot the whole top-level architecture.  That kind of open heart
surgery is not recommended without at least some prior analysis.  And
since no one knows enough of Emacs internals in enough detail, no
single person can do all that and succeed.

Just to put things in perspective: the integration of bidi reordering
into the display engine was intensively discussed over a period of 2
years, with active participation of Gerd Möllmann, the architect and
implementor of the current display code.  At least 2 other designs
were proposed (and one of them was even implemented) and rejected,
before the current design was agreed upon.  Needless to say, the bidi
support is nowhere near the redesign you are proposing, in terms of
complexity and overall effect on parts of Emacs outside display
proper.

I'm not trying to spook you off, and I really welcome an attempt to
revamp the display engine.  I'm just saying that without some minimal
analysis of requirements and possible high-level design decisions,
this project will have very small chance of delivering.

Re: Emacs and Gnome Canvas

[Miles Bader]

Eli Zaretskii <eliz@gnu.org> writes:
>   . Jan says we need to maintain a GtkTextBuffer object for every
>     buffer we have in Emacs.  Does that mean buffer text will be held
>     twice in memory, once as it is today, the other as GtkTextBuffer?
>     What will that do to Emacs's ability to visit very large files?
>     Even today there's demand to be able to visit files that are 1GB
>     or 2GB in size.  Doubling that would be a serious impediment.

... and it's not just memory -- a serious problem with many
"pre-rendered" text display implementations (e.g., most web-browsers) is
that there's a _massive_ delay/slowdown when displaying a huge
documents.

[Most people don't display huge documents (especially in web-browsers
etc), of course, so these implementations work OK for "typical" use.
But AFAICT, it's definitely an important goal of Emacs to handle more
extreme cases too.]

> Or maybe you are thinking about _replacing_ buffer text with
> GtkTextBuffer?  That would mean you'd need to redesign buffer
> management code.

and pretty much rewrite or toss out a lot of lisp code that uses any but
the most basic features.

I think code re-use and sharing commonly used libraries is a very good
thing, and should be done as often as practical -- but I just don't
think it's practical in the case of Emacs buffers/high-level-redisplay.
Emacs is simply too different.

[If someone wanted to _rewrite_ emacs from scratch, not maintaining
compatibility with the vast majority of legacy code, this would likely
be a good route to follow of course (though even in that case, there's
always the possibility that implementations like GtkTextBuffer are
simply not good enough to handle more hardcore use).]

Of course, using a lower-level interface, e.g., GTK/cairo/whatever as a
drawing library (which Emacs redisplay would call to display), instead
of e.g. X, would probably be practical though, and might even be fairly
easy to do given that the drawing layer already has an abstract
interface because of the various backends already supported.

-Miles

-- 
Once, adj. Enough.

Re: Emacs and Gnome Canvas

[Chong Yidong]

Óscar Fuentes <ofv@wanadoo.es> writes:

> AFAIK the display system have evolved from the tty one by incremental
> updates

No, the redisplay system was redesigned during Emacs 21 specifically
with both tty and graphical terminals in mind.  It did not evolve
mindlessly; the design has a very specific logic behind it.  As long as
we support tty, there is no getting rid of the redisplay iterator.
Since we have the redisplay iterator, the same system might as well be
used for graphical displays; it would terribly problematic to switch
between completely different rendering schemes for tty and graphical
displays to render the same underlying content.

It is still not too clear to me what we would gain from a Canvas-type
revamp of redisplay, relative to the large costs involved.  It does not
seem like a promising avenue of development.

A more promising route is the one that Yamamoto Mitsuharu has explored,
mentioned earlier in this thread, which (IIUC) treats Cairo as a
graphical terminal to render onto, on the same footing as the
tty/X/Windows/NS terminals.  Here, I can see a reasonable path to real
improvement.  For example, it might allow us to use the GTK printing
infrastructure, which operates on Cairo contexts.  If you are interested
in redisplay development, that is the direction I'd suggest looking
into.

Re: Emacs and Gnome Canvas

[Óscar Fuentes]

Chong Yidong <cyd@stupidchicken.com> writes:

> Óscar Fuentes <ofv@wanadoo.es> writes:
>
>> AFAIK the display system have evolved from the tty one by incremental
>> updates
>
> No, the redisplay system was redesigned during Emacs 21 specifically
> with both tty and graphical terminals in mind.  It did not evolve
> mindlessly; the design has a very specific logic behind it.  As long as
> we support tty, there is no getting rid of the redisplay iterator.

What I'm thinking on is not to remove the current display system. Is
about implementing a parallel one. I know from the start that the stuff
I'll use *if* the plan goes ahead is not acceptable for key Emacs
developers, so it would be a throw-away project, but nevertheless it
would give information about what can be expected from that approach.

[snip]

> It is still not too clear to me what we would gain from a Canvas-type
> revamp of redisplay, relative to the large costs involved.  It does not
> seem like a promising avenue of development.

One of the main insights we could get from the experimental plan I
referred to above is to know the cost/benefit ratio.

> A more promising route is the one that Yamamoto Mitsuharu has explored,
> mentioned earlier in this thread, which (IIUC) treats Cairo as a
> graphical terminal to render onto, on the same footing as the
> tty/X/Windows/NS terminals.  Here, I can see a reasonable path to real
> improvement.  For example, it might allow us to use the GTK printing
> infrastructure, which operates on Cairo contexts.  If you are interested
> in redisplay development, that is the direction I'd suggest looking
> into.

Would that system allow to draw UML diagrams with real graphics, instead
of ASCII? Would it allow to implement a real graphical view for the DAG
of a dVCS history? In short, would it a real drawing surface where you
can draw arbitrary stuff and react to user actions such as the user
clicking and dragging a line, preferably from Elisp code?

Anyways, I'm not interested on learning about the current display
engine. I was told that it is very complex and only a few gurus have a
real grasp of it, so very likely adding the features I'll like to see in
Emacs would be a daunting task. I'm more interested on a simpler
approach: here is the data, display it. The only thing I really fear is
finding that other parts of Emacs (high-level event handling or content
change management, for instance) are tightly coupled with the current
display engine.

Re: Emacs and Gnome Canvas

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Date: Thu, 15 Jul 2010 18:27:49 +0200
> 
> I know from the start that the stuff I'll use *if* the plan goes
> ahead is not acceptable for key Emacs developers

Why the defeatism?  Yidong expressed an understandable skepticism, but
if you present a persuasive case for the Canvas, I don't think it will
be rejected without consideration.

> Anyways, I'm not interested on learning about the current display
> engine.

How you will be able to implement a new display engine without at
least some familiarity with what the current one does?

> I'm more interested on a simpler approach: here is the data, display
> it.

This isn't Emacs.  You are describing Gnuplot.  The most important
problem a display engine needs to solve is: here's the new data and
the old display, now update the display.  And the data is not all
given in one place.

> The only thing I really fear is finding that other parts of Emacs
> (high-level event handling or content change management, for
> instance) are tightly coupled with the current display engine.

What do you mean by ``tightly coupled''?  The current display stops if
input becomes available -- is that tight enough?

In general, if you make all kinds of assumptions that would break your
approach, I'd suggest to publish those assumptions -- that's the
fastest way to validating them, short of studying the code yourself.

Re: Emacs and Gnome Canvas

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

>> I know from the start that the stuff I'll use *if* the plan goes
>> ahead is not acceptable for key Emacs developers
>
> Why the defeatism?

I would use Qt, hence C++, not being shy about using advanced language
features if necessary. That is for getting a working system as soon as
possible.

[snip]

>> Anyways, I'm not interested on learning about the current display
>> engine.
>
> How you will be able to implement a new display engine without at
> least some familiarity with what the current one does?

I expect that if the internal layout of the data to be displayed is
clear enough, that is sufficient for the display engine writer. I mean,
knowing "this represents a text property" is what you need. Knowing how
the current display engine deals with it shouldn't be necessary. I'm
sure there is a lot of wisdom on the current display system wrt dealing
with difficulties of representing Emacs' data on a screen, but I suspect
that learn-by-doing is faster than stopping everything while one studies
the details of the current implementation and elaborated plans. I have a
tendency to analysis-paralysis and that approach won't work for me on
hobby projects :-)

>> I'm more interested on a simpler approach: here is the data, display
>> it.
>
> This isn't Emacs.  You are describing Gnuplot.  The most important
> problem a display engine needs to solve is: here's the new data and
> the old display, now update the display.  And the data is not all
> given in one place.

That's implicit in the above. The "data" contains info about what
changed.

>> The only thing I really fear is finding that other parts of Emacs
>> (high-level event handling or content change management, for
>> instance) are tightly coupled with the current display engine.
>
> What do you mean by ``tightly coupled''?  The current display stops if
> input becomes available -- is that tight enough?

No, that's fine because the low-level input handling will be part of the
new system. By "tightly coupled" I mean there are blurred areas where it
is hard to say if they belong to the display engine or to other
system. Ideally, if Emacs were well modularized, adding a new display
engine wouldn't require any modifications to other areas.

> In general, if you make all kinds of assumptions that would break your
> approach, I'd suggest to publish those assumptions -- that's the
> fastest way to validating them, short of studying the code yourself.

That's a good idea.

Re: Emacs and Gnome Canvas

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Date: Thu, 15 Jul 2010 19:48:50 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> I know from the start that the stuff I'll use *if* the plan goes
> >> ahead is not acceptable for key Emacs developers
> >
> > Why the defeatism?
> 
> I would use Qt, hence C++, not being shy about using advanced language
> features if necessary. That is for getting a working system as soon as
> possible.

C++ is not the fastest language to get a job done.  Plus, you'll have
unrelated job on your hands of making Emacs C++-compliant, as
discussed in another thread.

Unless you are rewriting the whole Emacs, that is ;-)

> > How you will be able to implement a new display engine without at
> > least some familiarity with what the current one does?
> 
> I expect that if the internal layout of the data to be displayed is
> clear enough, that is sufficient for the display engine writer. I mean,
> knowing "this represents a text property" is what you need. Knowing how
> the current display engine deals with it shouldn't be necessary.

I said "knowing WHAT the current does", not HOW it does that.  The
problem is, you cannot know WHAT it does without at least some study
of the code, because there's no requirements document.

Take the font-lock, for example -- it has special support in the
display engine.  Without implementing the APIs for this support, JIT
Lock, which is standard since Emacs 21.1, will not work.

Re: Emacs and Gnome Canvas

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

>> I would use Qt, hence C++, not being shy about using advanced language
>> features if necessary. That is for getting a working system as soon as
>> possible.
>
> C++ is not the fastest language to get a job done.

That's very true. Unfortunately, AFAIK there is no Free high quality
cross platform GUI for Lisp :-)

> Plus, you'll have unrelated job on your hands of making Emacs
> C++-compliant, as discussed in another thread.

Only the Emacs header files that the display engine needs must be
acceptable by g++. The .c files would be compiled by gcc as usual.

> Unless you are rewriting the whole Emacs, that is ;-)

Others are already doing that :-)

>> > How you will be able to implement a new display engine without at
>> > least some familiarity with what the current one does?
>> 
>> I expect that if the internal layout of the data to be displayed is
>> clear enough, that is sufficient for the display engine writer. I mean,
>> knowing "this represents a text property" is what you need. Knowing how
>> the current display engine deals with it shouldn't be necessary.
>
> I said "knowing WHAT the current does", not HOW it does that.  The
> problem is, you cannot know WHAT it does without at least some study
> of the code, because there's no requirements document.
>
> Take the font-lock, for example -- it has special support in the
> display engine.  Without implementing the APIs for this support, JIT
> Lock, which is standard since Emacs 21.1, will not work.

I see. That's probably one instance of the "tight coupling" I was
talking about before.

Apart from reading all the source code, I hope that it is possible to
look into just a few header files for learning the interface of the
display engine.

Re: Emacs and Gnome Canvas

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Date: Thu, 15 Jul 2010 23:27:14 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> I would use Qt, hence C++, not being shy about using advanced language
> >> features if necessary. That is for getting a working system as soon as
> >> possible.
> >
> > C++ is not the fastest language to get a job done.
> 
> That's very true. Unfortunately, AFAIK there is no Free high quality
> cross platform GUI for Lisp :-)

If we are talking a throw-away project, why not Python?

> > Plus, you'll have unrelated job on your hands of making Emacs
> > C++-compliant, as discussed in another thread.
> 
> Only the Emacs header files that the display engine needs must be
> acceptable by g++. The .c files would be compiled by gcc as usual.

I meant link-time and run-time compatibility, not syntactic
compatibility.

> Apart from reading all the source code, I hope that it is possible to
> look into just a few header files for learning the interface of the
> display engine.

Unfortunately, I'm not sure.  The header is dispextern.h, but if you
read through it, you will find that it mixes internal details of the
current implementation with external APIs in a way that discerning one
from the other is not trivial.

I would suggest instead to study the basic display iterator (defined
as `struct it') and the iteration process, implemented in two parts:
get_next_display_element and set_iterator_to_next.  These two and the
subroutines of get_next_display_element (next_element_from_*) are
where you see all the top-level features that the current display
engine implements; reading the relevant parts of the ELisp manual will
complete the picture regarding each one of the features.

Re: Emacs and Gnome Canvas

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

>> > C++ is not the fastest language to get a job done.
>> 
>> That's very true. Unfortunately, AFAIK there is no Free high quality
>> cross platform GUI for Lisp :-)
>
> If we are talking a throw-away project, why not Python?

That's a lot of work, because requires creating the necessary
bindings. With C++ all Emacs structures and functions are readily
accessible.

> I meant link-time and run-time compatibility, not syntactic
> compatibility.

I use C code on my C++ projects all the time, without those issues. Why
Emacs should be different?

>> Apart from reading all the source code, I hope that it is possible to
>> look into just a few header files for learning the interface of the
>> display engine.
>
> Unfortunately, I'm not sure.  The header is dispextern.h, but if you
> read through it, you will find that it mixes internal details of the
> current implementation with external APIs in a way that discerning one
> from the other is not trivial.

I was expecting that and it is the reason why I'm not very enthusiastic
about studying the source code.

> I would suggest instead to study the basic display iterator (defined
> as `struct it') and the iteration process, implemented in two parts:
> get_next_display_element and set_iterator_to_next.  These two and the
> subroutines of get_next_display_element (next_element_from_*) are
> where you see all the top-level features that the current display
> engine implements; reading the relevant parts of the ELisp manual will
> complete the picture regarding each one of the features.

Noted. Thanks!

Re: Emacs and Gnome Canvas

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Date: Fri, 16 Jul 2010 16:24:11 +0200
> 
> > I meant link-time and run-time compatibility, not syntactic
> > compatibility.
> 
> I use C code on my C++ projects all the time, without those issues. Why
> Emacs should be different?

Because Emacs uses some techniques that a rare C program does.  I
mentioned some of them in another thread.  Here's a recap:

  . The "relocatable allocator" which moves memory of allocated
    objects (such as the buffer text) when large chunks of memory are
    allocated or freed.  Also, allocation of memory off the pure
    space, during the build process.  These will probably need a
    custom new/delete implementations, and various C++ techniques such
    as smart pointers may need to be adjusted, or not used.

  . The dump and restart process: it's possible that various C++
    features such as static constructors will ``need some work'' to
    survive these atrocities.  That might need hacking the libraries
    you use, if you have the sources.

And if you are going to use Qt, you will also need to consider the
implication of the above on its objects.

Re: Emacs and Gnome Canvas

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

>> > I meant link-time and run-time compatibility, not syntactic
>> > compatibility.
>> 
>> I use C code on my C++ projects all the time, without those issues. Why
>> Emacs should be different?
>
> Because Emacs uses some techniques that a rare C program does.  I
> mentioned some of them in another thread.  Here's a recap:
>
>   . The "relocatable allocator" which moves memory of allocated
>     objects (such as the buffer text) when large chunks of memory are
>     allocated or freed.  Also, allocation of memory off the pure
>     space, during the build process.  These will probably need a
>     custom new/delete implementations, and various C++ techniques such
>     as smart pointers may need to be adjusted, or not used.

For this I would try to isolate the display manager's memory management
from the rest of Emacs. As far as the display manager doesn't need to
allocate or free objects created by Emacs, and vice-versa, it should
work. Right?

>   . The dump and restart process: it's possible that various C++
>     features such as static constructors will ``need some work'' to
>     survive these atrocities.  That might need hacking the libraries
>     you use, if you have the sources.

Good one. I can go without using static/global constructors, but dunno
about Qt. There are other potential issues with that: vtables, RTTI...

Thanks for the remarks.

A random thought now about something that intrigues me: AFAIK the only
purpose of dumping is to include into Emacs' executable the set of
compiled Elisp code that is required to be usable. I guess that the
approach made sense when distributing Emacs as a single executable could
be useful. But now hardly anyone installs Emacs without the extensive
Elisp library and other auxiliary files, so the "self-contained
functional Emacs executable" has little value. Of course I may be wrong
when guessing this, but if it is right, wouldn't make more sense to dump
all that Elisp bytecode to a single file that is loaded on startup? On
exchange of a startup time just a bit larger, the simplification on
other areas would be considerable.

[snip]

Re: Emacs and Gnome Canvas

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Date: Fri, 16 Jul 2010 18:07:21 +0200
> 
> >   . The "relocatable allocator" which moves memory of allocated
> >     objects (such as the buffer text) when large chunks of memory are
> >     allocated or freed.  Also, allocation of memory off the pure
> >     space, during the build process.  These will probably need a
> >     custom new/delete implementations, and various C++ techniques such
> >     as smart pointers may need to be adjusted, or not used.
> 
> For this I would try to isolate the display manager's memory management
> from the rest of Emacs. As far as the display manager doesn't need to
> allocate or free objects created by Emacs, and vice-versa, it should
> work. Right?

How can a display engine has its memory management isolated, if it
needs to call Lisp primitives to access Lisp objects and operate on
them?  Just a random example: when you bump into a buffer position
that is covered by a text property or overlay, you need to call a
function that returns that property's value, which requires a call
such as

  prop = get_char_property_and_overlay (make_number (position->charpos),
					Qdisplay, object, &overlay);

The call to make_number here creates a Lisp object.
get_char_property_and_overlay is one of the few basic APIs the display
engine calls to find what are the text properties at a specific buffer
or string position.  Rewriting it (and other similar APIs that the
display engine needs to call to do its job) to somehow work around the
need to create Lisp objects and pass them around will lead to a
massive rewrite of most of Emacs, or at the very least to a large body
of code built on top of the current interfaces.

I don't see how you can bypass this issue without getting your job
much larger and harder, for no good reason.

In my experience, C++ shines when you need to maintain software and
want to be able to extend and refactor it without too much pain.  It
doesn't help you much when you start a new project from scratch.
Since you are talking about a throw-away project, I don't really see
any gains in C++; I do see a lot of obstacles that are in no way
directly relevant to your undertaking, so overcoming those obstacles
would be simply waste of time and effort.

> A random thought now about something that intrigues me: AFAIK the only
> purpose of dumping is to include into Emacs' executable the set of
> compiled Elisp code that is required to be usable.

I think it was primarily for faster startup, but that's something we
should ask Richard.

> I guess that the approach made sense when distributing Emacs as a
> single executable could be useful. But now hardly anyone installs
> Emacs without the extensive Elisp library and other auxiliary files,
> so the "self-contained functional Emacs executable" has little
> value. Of course I may be wrong when guessing this, but if it is
> right, wouldn't make more sense to dump all that Elisp bytecode to a
> single file that is loaded on startup? On exchange of a startup time
> just a bit larger, the simplification on other areas would be
> considerable.

Doesn't the XEmacs "portable dumper" works like that?

Anyway, dumping is the murkiest part of Emacs for me, and I try very
hard to stay away of it.  I'm happy enough that it works for me, and
hope it will never break on the platforms that are important for me.
I only know something about its perils because I was once involved in
making a standard C library dump-compatible.

Re: Emacs and Gnome Canvas

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

>> >   . The "relocatable allocator" which moves memory of allocated
>> >     objects (such as the buffer text) when large chunks of memory are
>> >     allocated or freed.  Also, allocation of memory off the pure
>> >     space, during the build process.  These will probably need a
>> >     custom new/delete implementations, and various C++ techniques such
>> >     as smart pointers may need to be adjusted, or not used.
>> 
>> For this I would try to isolate the display manager's memory management
>> from the rest of Emacs. As far as the display manager doesn't need to
>> allocate or free objects created by Emacs, and vice-versa, it should
>> work. Right?
>
> How can a display engine has its memory management isolated, if it
> needs to call Lisp primitives to access Lisp objects and operate on
> them?  Just a random example: when you bump into a buffer position
> that is covered by a text property or overlay, you need to call a
> function that returns that property's value, which requires a call
> such as
>
>   prop = get_char_property_and_overlay (make_number (position->charpos),
> 					Qdisplay, object, &overlay);
>
> The call to make_number here creates a Lisp object.
> get_char_property_and_overlay is one of the few basic APIs the display
> engine calls to find what are the text properties at a specific buffer
> or string position.

For this especific example, I see no problem. The display backend will
obtain `prop' as you say, gather the needed information and dispose
`prop' immediately, following whatever Emacs protocol is required.

On this aspect I don't foresee serious problems (speaking from my
ignorance.) Maybe some data needs to be duplicated on both memory
spaces, but that's just an annoyance.

[snip]

> In my experience, C++ shines when you need to maintain software and
> want to be able to extend and refactor it without too much pain.  It
> doesn't help you much when you start a new project from scratch.
> Since you are talking about a throw-away project, I don't really see
> any gains in C++; I do see a lot of obstacles that are in no way
> directly relevant to your undertaking, so overcoming those obstacles
> would be simply waste of time and effort.

I want to use Qt. The easiest way for that is to use C++. There are Qt
bindings for several languages (Python included) but there are no Emacs
bindings for them (and if you see potential low-level compatibility
problems with C++, what can we expect from Python?) I'm thinking on the
possibility of using a private language of mine, which is very C/C++
friendly and much more productive than C++. This means less work and
more fun for me, but it makes very difficult for anybody else to look
into the project. IMO C++ is the only sensible option. I have 15 years
of experience with it and understand the global implications, although
probably you are right and I'm missing some important details specific
to the Emacs implementation, but can't see how using other language with
available Qt bindings could improve things.

[snip]

Re: Emacs and Gnome Canvas

[Chad Brown]

On Jul 16, 2010, at 2:21 PM, Óscar Fuentes wrote:
> 
> I want to use Qt. The easiest way for that is to use C++. There are Qt
> bindings for several languages (Python included) but there are no Emacs
> bindings for them (and if you see potential low-level compatibility
> problems with C++, what can we expect from Python?) I'm thinking on the
> possibility of using a private language of mine, which is very C/C++
> friendly and much more productive than C++. This means less work and
> more fun for me, but it makes very difficult for anybody else to look
> into the project. IMO C++ is the only sensible option.

I think what Eli is trying to tell you is this:

If you use Python, you can use the existing python<->C bridges.  If you use C++, you can't count on being able to use new /delete or anything that uses them (which will include a huge chunk of C++, and probably a huge chunk of Qt).

If I understand you correctly, you're trying to communicate the idea ``yeah, it'll probably be rough, but I'm comfortable with C++ and am willing to try to make it work''.  Unfortunately, what you're saying is much closer to ``how hard can it be?'' -- which leads many people (especially programmers) to answer the question -- and in this case it can be really quite hard.

I hope this helps. 
*Chad
P.S. ...who really just wants to see if an emacs that can `do' CSS3 is viable, but asked a big question and then left the country for two days...

Re: Emacs and Gnome Canvas

[Óscar Fuentes]

Chad Brown <yandros@MIT.EDU> writes:

> I think what Eli is trying to tell you is this:
>
> If you use Python, you can use the existing python<->C bridges.

I guess those bridges were made when somebody tried to add Python to
Emacs as an extension language. Do they cover the functions and data
structures that a display engine needs for talking with the rest of
Emacs? Are they up to date? Debugged? Documented?

> If you use C++, you can't count on being able to use new /delete or
> anything that uses them (which will include a huge chunk of C++, and
> probably a huge chunk of Qt).

This is plain wrong. First, there is no need to expose objects allocated
with `new' to the rest of Emacs. Second, whatever mechanism Emacs uses
for memory management, it is usable from C++ as well (for dealing with
Emacs objects, of course.)

> If I understand you correctly, you're trying to communicate the idea
> ``yeah, it'll probably be rough, but I'm comfortable with C++ and am
> willing to try to make it work''.  Unfortunately, what you're saying
> is much closer to ``how hard can it be?'' -- which leads many people
> (especially programmers) to answer the question -- and in this case it
> can be really quite hard.

Is it better to not try it, then?

Knowing how hard is it is one of the main motivations of this
project. But what drives me is just thinking that may be fun. Maybe
tomorrow I'll change my mind.

[snip]

Re: Emacs and Gnome Canvas

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Date: Sat, 17 Jul 2010 02:08:43 +0200
> 
> Second, whatever mechanism Emacs uses for memory management, it is
> usable from C++ as well (for dealing with Emacs objects, of course.)

How can you be sure?

Emacs overrides the default `malloc' and `sbrk' functions, at least on
some platforms, and replaces them with its own implementations.  Those
implementations relocate large objects on the heap behind the scenes,
whenever Emacs sees fit.  I'm not sure this is "usable from C++" out
of the box.  C++ objects that hold pointers to arrays might suddenly
find those pointers invalidated by the above-mentioned relocation.

We had quite a few bugs caused by that in Emacs, even though the issue
is well known and there are special protocols in Emacs sources to
follow in order to avoid that.  See, for example these messages
regarding one such bug:

  http://lists.gnu.org/archive/html/emacs-devel/2010-02/msg00666.html
  http://lists.gnu.org/archive/html/emacs-devel/2010-02/msg00702.html
  http://lists.gnu.org/archive/html/emacs-devel/2010-03/msg00088.html

If you want to see the fix, it's revno 99601 on the trunk.

> Is it better to not try it, then?

No.  But you need to be careful when you are choosing your tools of
trade -- they need to allow you to concentrate on the important
issues, instead of wasting energy on obstacles that have nothing to do
with the problems you intend to solve.

Re: Emacs and Gnome Canvas

[Andreas Schwab]

Eli Zaretskii <eliz@gnu.org> writes:

> Emacs overrides the default `malloc' and `sbrk' functions, at least on
> some platforms, and replaces them with its own implementations.  Those
> implementations relocate large objects on the heap behind the scenes,
> whenever Emacs sees fit.  I'm not sure this is "usable from C++" out
> of the box.  C++ objects that hold pointers to arrays might suddenly
> find those pointers invalidated by the above-mentioned relocation.

The relocating allocator can of course only relocate objects it knows
about, so I don't know what should be the issue with C++?  The objects
allocated via new are just part of the normal malloc space that never
gets touched by ralloc.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Emacs and Gnome Canvas

[Eli Zaretskii]

> From: Andreas Schwab <schwab@linux-m68k.org>
> Cc: Óscar Fuentes <ofv@wanadoo.es>,  emacs-devel@gnu.org
> Date: Sat, 17 Jul 2010 10:34:42 +0200
> 
> The relocating allocator can of course only relocate objects it knows
> about, so I don't know what should be the issue with C++?  The objects
> allocated via new are just part of the normal malloc space that never
> gets touched by ralloc.

Can you really avoid having C++ objects that reference Emacs buffers
and strings?  Maybe you can, but not easily, I think, and not by
accident.

And on some platforms (although not on GNU/Linux, I think) malloc is
also replaced, so there's no "normal malloc space" per se.

In any case, I didn't pretend to have researched this issue and to
have firm conclusions.  I just said that it _should_be_ researched
thoroughly, before concluding that using C++, and in conjunction with
Qt on top of that, will not in itself get one in trouble that is
completely unrelated to experimenting with the display engine.

Re: Emacs and Gnome Canvas

[Andreas Schwab]

Eli Zaretskii <eliz@gnu.org> writes:

> Can you really avoid having C++ objects that reference Emacs buffers
> and strings?

Just like you have to be careful not to use direct pointers into string
and buffer space in C.  Nothing new here.

> And on some platforms (although not on GNU/Linux, I think) malloc is
> also replaced, so there's no "normal malloc space" per se.

ralloc always divides the allocated space into malloc areas (handed to
malloc and friends) and relocatable blocks (handed to r_alloc and
friends).

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Emacs and Gnome Canvas

[Eli Zaretskii]

> From: Andreas Schwab <schwab@linux-m68k.org>
> Date: Sat, 17 Jul 2010 11:40:17 +0200
> Cc: ofv@wanadoo.es, emacs-devel@gnu.org
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Can you really avoid having C++ objects that reference Emacs buffers
> > and strings?
> 
> Just like you have to be careful not to use direct pointers into string
> and buffer space in C.  Nothing new here.

"Nothing new" for me and you, perhaps.  But I'm not sure about Óscar.

> > And on some platforms (although not on GNU/Linux, I think) malloc is
> > also replaced, so there's no "normal malloc space" per se.
> 
> ralloc always divides the allocated space into malloc areas (handed to
> malloc and friends) and relocatable blocks (handed to r_alloc and
> friends).

I'm quite sure I've bumped in the past into a bug triggered by a call
to malloc from a library function which had nothing to do with
relocatable blocks.  The bug happened because that malloc call caused
buffer text to be relocated.  Maybe the implementation changed since
then, though.

Re: Emacs and Gnome Canvas

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

>> > Can you really avoid having C++ objects that reference Emacs buffers
>> > and strings?
>> 
>> Just like you have to be careful not to use direct pointers into string
>> and buffer space in C.  Nothing new here.
>
> "Nothing new" for me and you, perhaps.  But I'm not sure about Óscar.

:-)

One of the mantras of every experienced C/C++ programmer is "do not
point to other's stuff unless they invited you to do that."

[snip]

Re: Emacs and Gnome Canvas

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Date: Fri, 16 Jul 2010 23:21:19 +0200
> 
> > How can a display engine has its memory management isolated, if it
> > needs to call Lisp primitives to access Lisp objects and operate on
> > them?  Just a random example: when you bump into a buffer position
> > that is covered by a text property or overlay, you need to call a
> > function that returns that property's value, which requires a call
> > such as
> >
> >   prop = get_char_property_and_overlay (make_number (position->charpos),
> > 					Qdisplay, object, &overlay);
> >
> > The call to make_number here creates a Lisp object.
> > get_char_property_and_overlay is one of the few basic APIs the display
> > engine calls to find what are the text properties at a specific buffer
> > or string position.
> 
> For this especific example, I see no problem. The display backend will
> obtain `prop' as you say, gather the needed information and dispose
> `prop' immediately, following whatever Emacs protocol is required.

`prop' is a Lisp object.  (So are `object' and `overlay'.)  Lisp
objects don't need to be disposed of, they are garbage-collected by
the GC.  But GC, too, might need to be examined for possible
incompatibilities with C++ memory management.

As another example, consider constructing the mode line.  The
mode-line spec is nowadays full of Lisp strings and text properties,
and the code which handles that in the current engine calls
make_string quite a lot.  make_string creates a Lisp string and
triggers all kinds of behind-the-scenes reshuffling of string and
buffer text that a normal C/C++ program does not expect.

Anyway, what I tried to show was that manipulating Lisp objects is an
integral part of any Emacs display engine; you cannot hope to sidestep
it.  Therefore, it is important to have a plan and infrastructure for
dealing with it, because otherwise you will need to change your
implementation each time you bump into an example you didn't think
about.

> I want to use Qt.

What for?

Re: Emacs and Gnome Canvas

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

[snip]

> But GC, too, might need to be examined for possible
> incompatibilities with C++ memory management.

C++ memory management requirements are no special compared against to an
embedded Python interpreter or an image rendering library, for
instance. If Emacs' garbage collector doesn't walk into the space that
does not belong to it, there should be no problem as long as the C++
code does not store Emacs objects.

[snip]

>> I want to use Qt.
>
> What for?

For displaying things ;-)

I could go on describing the qualities of Qt that makes it my preferred
choice, but that makes little sense on this ml.

Re: Emacs and Gnome Canvas

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Date: Sat, 17 Jul 2010 15:42:53 +0200
> 
> >> I want to use Qt.
> >
> > What for?
> 
> For displaying things ;-)

Like what?  I thought you were going to use Canvas for "displaying
things".

> I could go on describing the qualities of Qt that makes it my preferred
> choice, but that makes little sense on this ml.

I know what Qt can do, I'm using it in my daytime job all the time.
What I don't understand is what you need it for in the context of this
discussion.

Re: Emacs and Gnome Canvas

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

>> >> I want to use Qt.
>> >
>> > What for?
>> 
>> For displaying things ;-)
>
> Like what?  I thought you were going to use Canvas for "displaying
> things".

I plan to try Qt's "canvas" (the Graphics View Framework) for rendering
everything. If that turns out to be too slow, then the "text edit area
with embedded objects" approach would be tried.

>> I could go on describing the qualities of Qt that makes it my preferred
>> choice, but that makes little sense on this ml.
>
> I know what Qt can do, I'm using it in my daytime job all the time.
> What I don't understand is what you need it for in the context of this
> discussion.

My intention is to bring to Emacs a powerful and modern display system
(or at least demonstrate that it is possible.) With Qt we have from the
start cross-platform support, a powerful 2D graphics system and a
boatload of widgets.

Hope this answers your question.

Re: Emacs and Gnome Canvas

[Miles Bader]

Eli Zaretskii <eliz@gnu.org> writes:
>> I could go on describing the qualities of Qt that makes it my preferred
>> choice, but that makes little sense on this ml.
>
> I know what Qt can do, I'm using it in my daytime job all the time.
> What I don't understand is what you need it for in the context of this
> discussion.

Especially when Emacs _already_ uses GTK+ (and thus cairo etc), which
has roughly the same capabilities.

[The impression I got was simply that Óscar liked Qt, which is a fine
reason if it's just a personal project -- but of course there's a much
higher bar for stuff to be integrated into Emacs.]

-Miles

-- 
Omochiroi!

Re: Emacs and Gnome Canvas

[Óscar Fuentes]

Miles Bader <miles@gnu.org> writes:

[snip]

> [The impression I got was simply that Óscar liked Qt, which is a fine
> reason if it's just a personal project -- but of course there's a much
> higher bar for stuff to be integrated into Emacs.]

No, I don't like Qt, it is just the GUI framework that sucks less,
IMO. Using GTK is out of the question. So the choice is doing something
with Qt, or nothing at all. As stated before, I know that the chances
for integration are almost nil (although I don't see why it would
refused if the core Emacs src is left untouched and the new display
engine is just a few .cpp files that are ignored unless you turn the
right knob at configure time.) In any case, if it reaches the demo
phase, it would motivate others to do something equivalent based on
requirements acceptable by the Emacs devs.

Re: Emacs and Gnome Canvas

[Chad Brown]

On Jul 17, 2010, at 7:45 PM, Óscar Fuentes wrote:
> No, I don't like Qt, it is just the GUI framework that sucks less,
> IMO. Using GTK is out of the question. 

If you don't mind me asking, what is it about GTK that makes it `out of the question'?

Thanks in advance,
*Chad

Re: Emacs and Gnome Canvas

[Óscar Fuentes]

Chad Brown <yandros@MIT.EDU> writes:

> On Jul 17, 2010, at 7:45 PM, Óscar Fuentes wrote:
>> No, I don't like Qt, it is just the GUI framework that sucks less,
>> IMO. Using GTK is out of the question. 
>
> If you don't mind me asking, what is it about GTK that makes it `out
> of the question'?

I prefer to avoid answering that. Too much risk of starting a useless
flamewar.

Re: Emacs and Gnome Canvas

[Stefan Monnier]

>> But GC, too, might need to be examined for possible
>> incompatibilities with C++ memory management.
> C++ memory management requirements are no special compared against to an
> embedded Python interpreter or an image rendering library, for
> instance. If Emacs' garbage collector doesn't walk into the space that
> does not belong to it, there should be no problem as long as the C++
> code does not store Emacs objects.

Indeed, I do not forsee any particular problem on the malloc side,
personally (especially since when we use SYSTEM_MALLOC).
We could bump into some surprises on the unexec side, but that
shouldn't be a major obstacle either.


        Stefan

Re: Emacs and Gnome Canvas

[Stefan Monnier]

>>> I'm more interested on a simpler approach: here is the data, display
>>> it.
>> This isn't Emacs.  You are describing Gnuplot.  The most important
>> problem a display engine needs to solve is: here's the new data and
>> the old display, now update the display.  And the data is not all
>> given in one place.
> That's implicit in the above. The "data" contains info about what
> changed.

I think this will be the hard part: Emacs doesn't keep track very
precisely of which data it changes.  It might keep track of which
windows/buffers were affected, as well as maybe a containing region, but
that's about it.  It "often" (not that often, but often enough that it
should be handled passably fast) ends up saying "just redisplay it all"
because the changes have too far-reaching consequences to keep track
of them.
If it can be made to work, then it's an interesting direction, because
it basically dumps the responsibility of handling redisplay to some
external library.  I don't think trying to handle all the current
display features makes sense as a starting goal, BTW.  Better start
small and add features one by one as you encounter them.  You'll want to
rewrite the code at some point anyway, so there's no need to spend too
much time designing upfront.


        Stefan

Re: Emacs and Gnome Canvas

[Chong Yidong]

Óscar Fuentes <ofv@wanadoo.es> writes:

> Would that system allow to draw UML diagrams with real graphics, instead
> of ASCII? Would it allow to implement a real graphical view for the DAG
> of a dVCS history? In short, would it a real drawing surface where you
> can draw arbitrary stuff and react to user actions such as the user
> clicking and dragging a line, preferably from Elisp code?

If this is the reason you want to work with Canvas, I don't think it's
necessary to overhaul the Emacs redisplay engine at all.  A better
approach would be to create a system that allows Canvas objects to be
embedded in an Emacs display, in the same way that images can be
embedded.  Thinking of this problem as "replacing" redisplay, or
creating an alternative to redisplay, is unnecessary.

Joakim's patch for embedding gtk widgets is an interesting existing
experiment, somewhat along these lines.

Re: Emacs and Gnome Canvas

[Óscar Fuentes]

Chong Yidong <cyd@stupidchicken.com> writes:

> Óscar Fuentes <ofv@wanadoo.es> writes:
>
>> Would that system allow to draw UML diagrams with real graphics, instead
>> of ASCII? Would it allow to implement a real graphical view for the DAG
>> of a dVCS history? In short, would it a real drawing surface where you
>> can draw arbitrary stuff and react to user actions such as the user
>> clicking and dragging a line, preferably from Elisp code?
>
> If this is the reason you want to work with Canvas, I don't think it's
> necessary to overhaul the Emacs redisplay engine at all.  A better
> approach would be to create a system that allows Canvas objects to be
> embedded in an Emacs display, in the same way that images can be
> embedded.
>
> Thinking of this problem as "replacing" redisplay, or creating an
> alternative to redisplay, is unnecessary.
>
> Joakim's patch for embedding gtk widgets is an interesting existing
> experiment, somewhat along these lines.

I don't think this is poweful enough. There should be no separation
among text areas and drawing areas. Text should be just another kind of
item on the canvas. How do you represent an UML diagram with editable
areas inside the boxes, or editable rotated text along the lines that
connects them? Or even simpler: how about implementing something like a
tree widget on pure Elisp? It seems to me that doing that with the
approach you propose will be very difficult, at best.

My impression (and this is something that remains to be checked) is that
implementing a new general display engine will be faster than enhancing
the current one for adding a subset of the features the new one would
bring on, not mentioning long term benefits like hackability and easy of
maintenance.

Re: Emacs and Gnome Canvas

[Stephen Eilert]

Geez.I've gone away for a day and come back to a mail fest :)

When I first proposed the Cairo idea, it wasn't designed to replace
the current redisplay engine. Rather, to draw everything *except* the
buffer text, precisely because of the redisplay engine. Customize
windows could be "prettified" by drawing buttons and other elements
with Cairo, programatically and apart from the text, as images are
nowadays. The speedbar could benefit from better and dynamic icons and
draw real lines. Not to mention org-mode's spreadsheet (plotting a pie
graph inside Emacs would be huge :) )

I do not know if the current engine is able to draw into an offscreen
buffer, which would then receive Cairo enhancements. But that would be
less of a surgery and allow us to validate the Cairo bindings and
common use cases. UML diagrams, for instance, could also be done in a
whole buffer, or inside defined boundaries.

For comparison, i was thinking along the lines of a 'canvas element',
as implemented by recent browsers.


--Stephen

Sent from my Emacs



On Thu, Jul 15, 2010 at 3:02 PM, Óscar Fuentes <ofv@wanadoo.es> wrote:
> Chong Yidong <cyd@stupidchicken.com> writes:
>
>> Óscar Fuentes <ofv@wanadoo.es> writes:
>>
>>> Would that system allow to draw UML diagrams with real graphics, instead
>>> of ASCII? Would it allow to implement a real graphical view for the DAG
>>> of a dVCS history? In short, would it a real drawing surface where you
>>> can draw arbitrary stuff and react to user actions such as the user
>>> clicking and dragging a line, preferably from Elisp code?
>>
>> If this is the reason you want to work with Canvas, I don't think it's
>> necessary to overhaul the Emacs redisplay engine at all.  A better
>> approach would be to create a system that allows Canvas objects to be
>> embedded in an Emacs display, in the same way that images can be
>> embedded.
>>
>> Thinking of this problem as "replacing" redisplay, or creating an
>> alternative to redisplay, is unnecessary.
>>
>> Joakim's patch for embedding gtk widgets is an interesting existing
>> experiment, somewhat along these lines.
>
> I don't think this is poweful enough. There should be no separation
> among text areas and drawing areas. Text should be just another kind of
> item on the canvas. How do you represent an UML diagram with editable
> areas inside the boxes, or editable rotated text along the lines that
> connects them? Or even simpler: how about implementing something like a
> tree widget on pure Elisp? It seems to me that doing that with the
> approach you propose will be very difficult, at best.
>
> My impression (and this is something that remains to be checked) is that
> implementing a new general display engine will be faster than enhancing
> the current one for adding a subset of the features the new one would
> bring on, not mentioning long term benefits like hackability and easy of
> maintenance.
>
>
>
>

Re: Emacs and Gnome Canvas

[Eli Zaretskii]

> Date: Thu, 15 Jul 2010 19:10:35 -0300
> From: Stephen Eilert <spedrosa@gmail.com>
> Cc: emacs-devel@gnu.org
> 
> I do not know if the current engine is able to draw into an offscreen
> buffer

The current engine is able of calling any C function provided that
some basic precautions are met (see the commentary at the beginning of
xdisp.c for details).  The display engine does not care what the
called function does, if it does not affect the parts of the screen
where Emacs displays its buffers.  Does that answer your question?

Re: Emacs and Gnome Canvas

[YAMAMOTO Mitsuharu]

>>>>> On Thu, 15 Jul 2010 12:00:05 -0400, Chong Yidong <cyd@stupidchicken.com> said:

> A more promising route is the one that Yamamoto Mitsuharu has
> explored, mentioned earlier in this thread, which (IIUC) treats
> Cairo as a graphical terminal to render onto, on the same footing as
> the tty/X/Windows/NS terminals.  Here, I can see a reasonable path
> to real improvement.  For example, it might allow us to use the GTK
> printing infrastructure, which operates on Cairo contexts.  If you
> are interested in redisplay development, that is the direction I'd
> suggest looking into.

My proof-of-concept cairo port was primarily intended for the printing
support, not for screen drawing (though it does both).

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

Screen drawing in the cairo port is not so efficient for several
reasons.  To make it more efficient, one would need some modest
modifications to the current drawing model in Emacs.

  1. Don't draw during redisplay, but mark the updated area dirty so
     the upcoming exposure event can trigger the actual redraw for the
     area to be updated.
  2. Restrict the actual drawings to those in response to exposure
     events.  This is the standard way in GTK+ and Cocoa.  That would
     make double-buffering straightforward in GTK+ builds.
  3. Make expose_window etc. more efficient.  For example, the
     foreground of same row might currently be redrawn three times for
     some cases in order to handle overlaps between rows with minimal
     flickering.  This can be eliminated if double-buffering is
     introduced and whole the background is drawn at once and then
     whole the foreground is drawn afterwards.
  4. Scrolling in redisplay (x_shift_glyphs_for_insert and
     x_scroll_run) might require special treatment because copied area
     might be marked dirty at the time of scrolling.

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

Re: Emacs and Gnome Canvas

[Jan Djärv]

YAMAMOTO Mitsuharu skrev 2010-07-16 04.14:

>
>    1. Don't draw during redisplay, but mark the updated area dirty so
>       the upcoming exposure event can trigger the actual redraw for the
>       area to be updated.

If some characters change attribute for example foreground color, you have to 
draw it, there will be no expose.

>    2. Restrict the actual drawings to those in response to exposure
>       events.  This is the standard way in GTK+ and Cocoa.  That would
>       make double-buffering straightforward in GTK+ builds.

This is good, but can the current redisplay engine really update just a part 
of the display area?  Maybe we can set clipping to the expose area?
But most redrawings are not because of expose events, but of buffer changes, 
so I don't know if this would be such a big improvement.  If you have double 
buffering, then you can just copy over the buffer when expose happens.

>    3. Make expose_window etc. more efficient.  For example, the
>       foreground of same row might currently be redrawn three times for
>       some cases in order to handle overlaps between rows with minimal
>       flickering.  This can be eliminated if double-buffering is
>       introduced and whole the background is drawn at once and then
>       whole the foreground is drawn afterwards.

Are there many of these "reduce flicker" drawings going on?  Double buffer 
would be nice, I think it could help with images also (now images are drawn to 
a pixmap first, then copied to the frame).

>    4. Scrolling in redisplay (x_shift_glyphs_for_insert and
>       x_scroll_run) might require special treatment because copied area
>       might be marked dirty at the time of scrolling.

	Jan D.

Re: Emacs and Gnome Canvas

[Eli Zaretskii]

> Date: Fri, 16 Jul 2010 09:33:16 +0200
> From: Jan Djärv <jan.h.d@swipnet.se>
> Cc: Chong Yidong <cyd@stupidchicken.com>, emacs-devel@gnu.org,
>     Óscar Fuentes <ofv@wanadoo.es>
> 
> >    2. Restrict the actual drawings to those in response to exposure
> >       events.  This is the standard way in GTK+ and Cocoa.  That would
> >       make double-buffering straightforward in GTK+ builds.
> 
> This is good, but can the current redisplay engine really update just a part 
> of the display area?

It depends on what you mean by "redisplay engine" in this context.
The high-level, platform-independent part of the display engine has
its own ideas regarding which parts need to be redrawn, and I won't
recommend modifying that.  But this part of the engine does not draw
anything.  It just produces an interim _representation_ of the desired
screen contents, stored as a "glyph matrix" structure.  It is then the
job of the terminal-specific back-end to actually draw the screen
based on the desired matrix.  What the back-end does is entirely up to
it, provided that it keeps a very simple contract: that after it's
done, the contents of the screen is 100% according to the desired
matrix.

Btw, I don't think I understand what Mitsuharu says in this Item #2.
Surely, we cannot "restrict the actual drawings to those in response
to exposure events"?  A completely exposed window does need to be
redrawn if the buffer text changes, right?  What am I missing?

Re: Emacs and Gnome Canvas

[YAMAMOTO Mitsuharu]

>>>>> On Fri, 16 Jul 2010 12:52:12 +0300, Eli Zaretskii <eliz@gnu.org> said:

> Btw, I don't think I understand what Mitsuharu says in this Item #2.
> Surely, we cannot "restrict the actual drawings to those in response
> to exposure events"?  A completely exposed window does need to be
> redrawn if the buffer text changes, right?  What am I missing?

The current code assumes that drawing is mainly done for updated area
during redisplay, and expose_window is rather subsidiary.  So the
latter is not so optimized for frequent use.  For example, it does not
accept multiple rectangles for exposed area that is necessary for
minimal redrawing.  It also reuses functions primarily designed for
drawing during redisplay and that does not necessarily efficient for
exposure handing.

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

Re: Emacs and Gnome Canvas

[Eli Zaretskii]

> Date: Fri, 16 Jul 2010 19:15:25 +0900
> From: YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp>
> Cc: Jan Djärv <jan.h.d@swipnet.se>,	ofv@wanadoo.es,
> 	cyd@stupidchicken.com,	emacs-devel@gnu.org
> 
> >>>>> On Fri, 16 Jul 2010 12:52:12 +0300, Eli Zaretskii <eliz@gnu.org> said:
> 
> > Btw, I don't think I understand what Mitsuharu says in this Item #2.
> > Surely, we cannot "restrict the actual drawings to those in response
> > to exposure events"?  A completely exposed window does need to be
> > redrawn if the buffer text changes, right?  What am I missing?
> 
> The current code assumes that drawing is mainly done for updated area
> during redisplay, and expose_window is rather subsidiary.  So the
> latter is not so optimized for frequent use.

Is it really worth our while to optimize that?  What would be the
situation where we will get frequent expose events?

> For example, it does not accept multiple rectangles for exposed area
> that is necessary for minimal redrawing.

Don't we get a single expose event for each exposed rectangular area?
If we do, what would be the gain from processing multiple rectangles
at once?

> It also reuses functions primarily designed for drawing during
> redisplay and that does not necessarily efficient for exposure
> handing.

Are you talking about draw_glyphs?  If so, how is it biased in favor
of redisplay, and what would be a more efficient way of drawing glyphs
in a specified area of the display than what draw_glyphs does?

Re: Emacs and Gnome Canvas

[Jan Djärv]

Eli Zaretskii skrev 2010-07-16 12.39:
>> Date: Fri, 16 Jul 2010 19:15:25 +0900
>> From: YAMAMOTO Mitsuharu<mituharu@math.s.chiba-u.ac.jp>
>
>> For example, it does not accept multiple rectangles for exposed area
>> that is necessary for minimal redrawing.
>
> Don't we get a single expose event for each exposed rectangular area?
> If we do, what would be the gain from processing multiple rectangles
> at once?

There is an X extension for that, DAMAGE.  But if that is not used, you would 
get just one rectangle.  Since the extension exist and programs use it, I 
assume people found that it gave and advantage.

>
>> It also reuses functions primarily designed for drawing during
>> redisplay and that does not necessarily efficient for exposure
>> handing.
>
> Are you talking about draw_glyphs?  If so, how is it biased in favor
> of redisplay, and what would be a more efficient way of drawing glyphs
> in a specified area of the display than what draw_glyphs does?

If you for example have double buffer, you can split expose from update 
display.  When an expose comes, you just copy the area from the backing store 
to the window.  But for updating the display, you draw normally, but to the 
backing store.  Then when you are done, you copy it to the window.

But I don't think optimizing for expose is worth it.  Expose iis very rare 
compared to update.

	Jan D.

Re: Emacs and Gnome Canvas

[YAMAMOTO Mitsuharu]

>>>>> On Fri, 16 Jul 2010 14:42:00 +0200, Jan Djärv <jan.h.d@swipnet.se> said:

> If you for example have double buffer, you can split expose from
> update display.  When an expose comes, you just copy the area from
> the backing store to the window.  But for updating the display, you
> draw normally, but to the backing store.  Then when you are done,
> you copy it to the window.

How do you copy the backing store to the window?  The whole area, or
divide the updated area to some collection of rectangles?  The former
is too inefficient for small updates.  For the latter, how do you
determine such rectangles?  Isn't that task no easier than creating
rectangles for dirty areas?

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

Re: Emacs and Gnome Canvas

[Jan Djärv]

YAMAMOTO Mitsuharu skrev 2010-07-17 05.50:
>>>>>> On Fri, 16 Jul 2010 14:42:00 +0200, Jan Djärv<jan.h.d@swipnet.se>  said:
>
>> If you for example have double buffer, you can split expose from
>> update display.  When an expose comes, you just copy the area from
>> the backing store to the window.  But for updating the display, you
>> draw normally, but to the backing store.  Then when you are done,
>> you copy it to the window.
>
> How do you copy the backing store to the window?

If using the double buffer extension, by calling one function.

> The whole area, or
> divide the updated area to some collection of rectangles?  The former
> is too inefficient for small updates.

No it is not, this is how Gtk+ operates all the time, even for small updates.

	Jan D.

Re: Emacs and Gnome Canvas

[YAMAMOTO Mitsuharu]

>>>>> On Sat, 17 Jul 2010 10:33:08 +0200, Jan Djärv <jan.h.d@swipnet.se> said:

>> The whole area, or divide the updated area to some collection of
>> rectangles?  The former is too inefficient for small updates.

> No it is not, this is how Gtk+ operates all the time, even for small
> updates.

Isn't GTK+ using the model I've been saying, i.e., drawing only in
respose to exposure, especially when using cairo?

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

Re: Emacs and Gnome Canvas

[Jan Djärv]

YAMAMOTO Mitsuharu skrev 2010-07-17 10.38:
>>>>>> On Sat, 17 Jul 2010 10:33:08 +0200, Jan Djärv<jan.h.d@swipnet.se>  said:
>
>>> The whole area, or divide the updated area to some collection of
>>> rectangles?  The former is too inefficient for small updates.
>
>> No it is not, this is how Gtk+ operates all the time, even for small
>> updates.
>
> Isn't GTK+ using the model I've been saying, i.e., drawing only in
> respose to exposure, especially when using cairo?

Gtk+ (or rather Gdk) makes a syntetic expose event.  But if you have a small 
change, it will do it just for that small change, the same it does for big 
changes.

	Jan D.

Re: Emacs and Gnome Canvas

[YAMAMOTO Mitsuharu]

>>>>> On Sat, 17 Jul 2010 11:18:56 +0200, Jan Djärv <jan.h.d@swipnet.se> said:

>>>> The whole area, or divide the updated area to some collection of
>>>> rectangles?  The former is too inefficient for small updates.
>> 
>>> No it is not, this is how Gtk+ operates all the time, even for
>>> small updates.
>> 
>> Isn't GTK+ using the model I've been saying, i.e., drawing only in
>> respose to exposure, especially when using cairo?

> Gtk+ (or rather Gdk) makes a syntetic expose event.  But if you have
> a small change, it will do it just for that small change, the same
> it does for big changes.

Sorry, I don't understand.  Does GTK+ or GDK do double-buffering for
drawings outside the handler of (possibly synthetic) expose events?

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

Re: Emacs and Gnome Canvas

[Jan Djärv]

YAMAMOTO Mitsuharu skrev 2010-07-17 11.25:
>>>>>> On Sat, 17 Jul 2010 11:18:56 +0200, Jan Djärv<jan.h.d@swipnet.se>  said:
>
>>>>> The whole area, or divide the updated area to some collection of
>>>>> rectangles?  The former is too inefficient for small updates.
>>>
>>>> No it is not, this is how Gtk+ operates all the time, even for
>>>> small updates.
>>>
>>> Isn't GTK+ using the model I've been saying, i.e., drawing only in
>>> respose to exposure, especially when using cairo?
>
>> Gtk+ (or rather Gdk) makes a syntetic expose event.  But if you have
>> a small change, it will do it just for that small change, the same
>> it does for big changes.
>
> Sorry, I don't understand.  Does GTK+ or GDK do double-buffering for
> drawings outside the handler of (possibly synthetic) expose events?

No, not outside expose events.  But if I insert a character in a text edit 
widget, it invalidates itself. That generates a syntetic expose event.  When 
the event is processed, Gdk arranges for all drawings to go to the backing 
store.  When the event is fully processed, the backing store is copied to the 
window.

Copying the whole window or just a portion should hardly matter w.r.t. 
performance.  This is all done in the X server.

	Jan D.

Re: Emacs and Gnome Canvas

[YAMAMOTO Mitsuharu]

>>>>> On Sat, 17 Jul 2010 12:26:06 +0200, Jan Djärv <jan.h.d@swipnet.se> said:

>> Sorry, I don't understand.  Does GTK+ or GDK do double-buffering
>> for drawings outside the handler of (possibly synthetic) expose
>> events?

> No, not outside expose events.  But if I insert a character in a
> text edit widget, it invalidates itself. That generates a syntetic
> expose event.  When the event is processed, Gdk arranges for all
> drawings to go to the backing store.  When the event is fully
> processed, the backing store is copied to the window.

That's what I've been talking: during redisplay, we invalidate the
area to be updated (i.e., make it dirty) rather than drawing directly.
Instead, all the drawings are done inside the expose handler.  This
way, double-buffering can be introduced straightforwardly.  For
example, the area that should be copied to the window is already
passed to the handler, and we don't have to keep window and backing
store contents in sync (the backing store can be created at the
beginning of global expose handler without copying the current window
contents to the buffer, and also can be freed after copying it to the
window).  It does match better with transparency or overlapping
widgets.

You've rather been talking about an alternative double-buffering that
is for drawing during redisplay (i.e., outside the expose handler),
and said that is how GTK+ operates all the time.

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

Re: Emacs and Gnome Canvas

[Jan Djärv]

YAMAMOTO Mitsuharu skrev 2010-07-18 05.51:

>
> You've rather been talking about an alternative double-buffering that
> is for drawing during redisplay (i.e., outside the expose handler),
> and said that is how GTK+ operates all the time.
>

I think you misunderstood.  You said doing copying of the whole window from 
double buffering for small changes is too slow.  I said it can't be because 
Gtk+ does it.  Thats it.

BTW, you would have to invent syntactic expose events for X, Xt and TTY unless 
you plan to have two display engines.

	Jan D.

Re: Emacs and Gnome Canvas

[YAMAMOTO Mitsuharu]

>>>>> On Sun, 18 Jul 2010 09:10:18 +0200, Jan Djärv <jan.h.d@swipnet.se> said:

>> You've rather been talking about an alternative double-buffering
>> that is for drawing during redisplay (i.e., outside the expose
>> handler), and said that is how GTK+ operates all the time.

> I think you misunderstood.  You said doing copying of the whole
> window from double buffering for small changes is too slow.  I said
> it can't be because Gtk+ does it.  Thats it.

GTK+ can make such copying efficient because it does drawing inside
the expose handler, which is called with the clipping region as
exposed area.  But if double buffering is done outside the expose
handler we don't know which area is updated.  So it has to copy the
whole area, or each drawing operation must take care about which area
is updated.  The latter is no easier than calculating dirty region.

> BTW, you would have to invent syntactic expose events for X, Xt and
> TTY unless you plan to have two display engines.

We don't need to change drawing code for TTY.  It just draws during
redisplay as in the current code.

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

Re: Emacs and Gnome Canvas

[Jan Djärv]

YAMAMOTO Mitsuharu skrev 2010-07-18 09.45:
>>>>>> On Sun, 18 Jul 2010 09:10:18 +0200, Jan Djärv<jan.h.d@swipnet.se>  said:
>
>> BTW, you would have to invent syntactic expose events for X, Xt and
>> TTY unless you plan to have two display engines.
>
> We don't need to change drawing code for TTY.  It just draws during
> redisplay as in the current code.

Then you have to have two redisplay engines.  One that calculates dirty 
regions and updates during expose, and one that updates at once.

The alternative is to force two redisplays, redisplay due to update and then 
the backends just set dirty area, and then once again for the expose where the 
actual drawing takes place.

I don't see how you are going to get around it.

	Jan D.

Re: Emacs and Gnome Canvas

[YAMAMOTO Mitsuharu]

>>>>> On Sun, 18 Jul 2010 11:06:41 +0200, Jan Djärv <jan.h.d@swipnet.se> said:

>>> BTW, you would have to invent syntactic expose events for X, Xt
>>> and TTY unless you plan to have two display engines.
>> 
>> We don't need to change drawing code for TTY.  It just draws during
>> redisplay as in the current code.

> Then you have to have two redisplay engines.  One that calculates
> dirty regions and updates during expose, and one that updates at
> once.

No.  Notice that neither draw_glyphs nor expose_frame is defined if
HAVE_WINDOW_SYSTEM is undefined.  You replace the former so it
invalidates the updated area, and make the latter more efficient
assuming the existence of double-buffer.

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

Re: Emacs and Gnome Canvas

[YAMAMOTO Mitsuharu]

>>>>> On Fri, 16 Jul 2010 13:39:28 +0300, Eli Zaretskii <eliz@gnu.org> said:

>> The current code assumes that drawing is mainly done for updated
>> area during redisplay, and expose_window is rather subsidiary.  So
>> the latter is not so optimized for frequent use.

> Is it really worth our while to optimize that?  What would be the
> situation where we will get frequent expose events?

If we change drawing during redisplay to addition of dirty area, then
expose occurs on every window-system-level event handling or explicit
flush.

>> For example, it does not accept multiple rectangles for exposed
>> area that is necessary for minimal redrawing.

> Don't we get a single expose event for each exposed rectangular
> area?  If we do, what would be the gain from processing multiple
> rectangles at once?

I'm not X11 expert, but Expose event contains the `count' member.

  The count member is set to the number of Expose events that are to
  follow. If count is zero, no more Expose events follow for this
  window. However, if count is nonzero, at least that number of Expose
  events (and possibly more) follow for this window. Simple
  applications that do not want to optimize redisplay by
  distinguishing between subareas of its window can just ignore all
  Expose events with nonzero counts and perform full redisplays on
  events with zero counts.

Cocoa has a special method for that.

We can minimize rows to be drawn compared with a large union rectangle
that overapproximately covers all rectangles, and we can reduce the
overhead of processing the same window for possibly duplicated areas
compared with calling expose_window for each rectangle.

>> It also reuses functions primarily designed for drawing during
>> redisplay and that does not necessarily efficient for exposure
>> handing.

> Are you talking about draw_glyphs?  If so, how is it biased in favor
> of redisplay, and what would be a more efficient way of drawing
> glyphs in a specified area of the display than what draw_glyphs
> does?

As I mentioned, row overlapping is handled in rather an inefficient
way (by calling draw_glyphs for three times if the row is overlapping
and overlapped).  With double-buffering, we can draw whole the
background of the specified area (possibly containing multiple rows)
at once and then draw the whole foreground afterwards.

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

Re: Emacs and Gnome Canvas

[YAMAMOTO Mitsuharu]

>>>>> On Sat, 17 Jul 2010 10:00:40 +0900, YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> said:

>> Is it really worth our while to optimize that?  What would be the
>> situation where we will get frequent expose events?

> If we change drawing during redisplay to addition of dirty area,
> then expose occurs on every window-system-level event handling or
> explicit flush.

... if redisplay had involved some updates, of course.

BTW, one reason several toolkits are adopting this strategy is that it
fits with transparency.  Consider that some transparent widget (such
as canvas where some lines and possibly translucent rectangles are
drawn) is overlaid above the Emacs "widget".  If we drew the Emacs
contents during redisplay, then the canvas would have no way to know
which part needs to be redrawn.  If redisplay marks the area dirty
instead of drawing, this can also be propagated to the canvas widget:
the toolkit sends redraw requests to the widgets intersecting the
dirty area in back-to-front order.

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

Re: Emacs and Gnome Canvas

[Eli Zaretskii]

> Date: Sat, 17 Jul 2010 10:00:40 +0900
> From: YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp>
> Cc: jan.h.d@swipnet.se,
> 	ofv@wanadoo.es,
> 	cyd@stupidchicken.com,
> 	emacs-devel@gnu.org
> 
> >> It also reuses functions primarily designed for drawing during
> >> redisplay and that does not necessarily efficient for exposure
> >> handing.
> 
> > Are you talking about draw_glyphs?  If so, how is it biased in favor
> > of redisplay, and what would be a more efficient way of drawing
> > glyphs in a specified area of the display than what draw_glyphs
> > does?
> 
> As I mentioned, row overlapping is handled in rather an inefficient
> way (by calling draw_glyphs for three times if the row is overlapping
> and overlapped).  With double-buffering, we can draw whole the
> background of the specified area (possibly containing multiple rows)
> at once and then draw the whole foreground afterwards.

Someone should profile the current redisplay and see which part(s) of
it take most of the processing time.  Without such a profile, we are
making the classic mistake of optimizing in a wrong place.

FWIW, Gerd Möllman once told me that the most computationally
intensive place is in face merging and realization, which is not run
at all when expose events are processed.  I don't know if it's true
nowadays, but it's well known that guessing where the hot spots are is
a very bad idea, because the guesses are usually plain wrong, more so
if the guessing parties didn't write the code.

Re: Emacs and Gnome Canvas

[YAMAMOTO Mitsuharu]

>>>>> On Sat, 17 Jul 2010 11:04:31 +0300, Eli Zaretskii <eliz@gnu.org> said:

>> As I mentioned, row overlapping is handled in rather an inefficient
>> way (by calling draw_glyphs for three times if the row is
>> overlapping and overlapped).  With double-buffering, we can draw
>> whole the background of the specified area (possibly containing
>> multiple rows) at once and then draw the whole foreground
>> afterwards.

> Someone should profile the current redisplay and see which part(s)
> of it take most of the processing time.  Without such a profile, we
> are making the classic mistake of optimizing in a wrong place.

I'm not saying that the current code (using Xlib for drawing) is slow.
Even if expose_window is not so optimized, it doesn't matter that much
because it is currently not so frequently called.

If we stick to Xlib, there would be no need to modify the current
drawing model.  But if we switch to cairo, straightforward translation
of Xlib drawing calls to cairo counterparts does not give a
satisfactory result.

I've just remembered another problem.  If we use the current
expose_window code for the printing support, it produces inefficient
PDF.  Notably, multiple drawings of the same text for handling
overlapping rows causes duplicated text in PDF.  That is, if you copy
a text from a PDF viewer, you'll see a repetition of the same text.

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

Re: Emacs and Gnome Canvas

[Jan Djärv]

Eli Zaretskii skrev 2010-07-16 11.52:

>
> Btw, I don't think I understand what Mitsuharu says in this Item #2.
> Surely, we cannot "restrict the actual drawings to those in response
> to exposure events"?  A completely exposed window does need to be
> redrawn if the buffer text changes, right?  What am I missing?

Nothing, you are correct.

	Jan D.

Re: Emacs and Gnome Canvas

[YAMAMOTO Mitsuharu]

>>>>> On Fri, 16 Jul 2010 09:33:16 +0200, Jan Djärv <jan.h.d@swipnet.se> said:

>> 1. Don't draw during redisplay, but mark the updated area dirty so
>> the upcoming exposure event can trigger the actual redraw for the
>> area to be updated.

> If some characters change attribute for example foreground color,
> you have to draw it, there will be no expose.

Whenever you need drawing outside exposure events, it should be
replaced with addition of the dirty area.

>> 2. Restrict the actual drawings to those in response to exposure
>> events.  This is the standard way in GTK+ and Cocoa.  That would
>> make double-buffering straightforward in GTK+ builds.

> This is good, but can the current redisplay engine really update
> just a part of the display area?  Maybe we can set clipping to the
> expose area? 

Cocoa automatically does that.  I'm not sure about others.

> But most redrawings are not because of expose events, but of buffer
> changes, so I don't know if this would be such a big improvement.
> If you have double buffering, then you can just copy over the buffer
> when expose happens.

I've tried some double buffering in the cairo port (not in the posted
patch) by allocating completely transparent image surface with alpha
channel when we switch from Xlib drawing to cairo, and coping it when
we have to switch back.  The performance was not so satisfactory,
maybe because of alpha blending overhead.

Some documents might be useful to see why this model is recommended in
many toolkits.

Cocoa Fundamental Guide - The Core Application Architecture on Mac OS X - How Views Get Drawn
http://developer.apple.com/mac/library/documentation/Cocoa/Conceptual/CocoaFundamentals/CoreAppArchitecture/CoreAppArchitecture.html#//apple_ref/doc/uid/TP40002974-CH8-SW18

The GTK+ Drawing Model
http://library.gnome.org/devel/gtk/stable/chap-drawing-model.html

Some inefficiency specific to the cairo port comes from repeated
acquisition/release of Xlib surface during redisplay.  This can be
simplified if drawing is restricted to exposure.

>> 3. Make expose_window etc. more efficient.  For example, the
>> foreground of same row might currently be redrawn three times for
>> some cases in order to handle overlaps between rows with minimal
>> flickering.  This can be eliminated if double-buffering is
>> introduced and whole the background is drawn at once and then whole
>> the foreground is drawn afterwards.

> Are there many of these "reduce flicker" drawings going on?

It depends on the fonts used.

> Double buffer would be nice, I think it could help with images also
> (now images are drawn to a pixmap first, then copied to the frame).

Yes.  Many of such code can simplified.

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

Re: Emacs and Gnome Canvas

[Jan Djärv]

YAMAMOTO Mitsuharu skrev 2010-07-16 12.01:
>>>>>> On Fri, 16 Jul 2010 09:33:16 +0200, Jan Djärv<jan.h.d@swipnet.se>  said:
>
>>> 1. Don't draw during redisplay, but mark the updated area dirty so
>>> the upcoming exposure event can trigger the actual redraw for the
>>> area to be updated.
>
>> If some characters change attribute for example foreground color,
>> you have to draw it, there will be no expose.
>
> Whenever you need drawing outside exposure events, it should be
> replaced with addition of the dirty area.
>

What does "replaced with addition of the dirty area" mean?  The X server only 
sends expose events when it thinks that a (part of) an X window needs to be 
redrawn, for example when resizing.  Scrolling does not generate expose 
events, nor is there a way to generate one.  The case where the window is 
supposed to change in the visible region does not generate any expose event.

	Jan D.

Re: Emacs and Gnome Canvas

[Davis Herring]

> What does "replaced with addition of the dirty area" mean?  The X
> server only sends expose events when it thinks that a (part of) an X
> window needs to be redrawn, for example when resizing.

I think it means "inform the X server that a region needs to be redrawn,
as if it had just been exposed".  I don't know if X even supports this
idea, but I know it from Java:
<http://java.sun.com/j2se/1.5.0/docs/api/java/awt/Component.html#repaint%28int,%20int,%20int,%20int%29>.
 That method arranges for a repaint to occur, but returns immediately; the
painting happens in response to the artificial expose-like event created. 
(Such events may then be intelligently coalesced by the toolkit to paint
larger areas in one pass.)

Davis

-- 
This product is sold by volume, not by mass.  If it appears too dense or
too sparse, it is because mass-energy conversion has occurred during
shipping.

Re: Emacs and Gnome Canvas

[Jan Djärv]

Davis Herring skrev 2010-07-16 16.05:
>> What does "replaced with addition of the dirty area" mean?  The X
>> server only sends expose events when it thinks that a (part of) an X
>> window needs to be redrawn, for example when resizing.
>
> I think it means "inform the X server that a region needs to be redrawn,
> as if it had just been exposed".  I don't know if X even supports this
> idea, but I know it from Java:
> <http://java.sun.com/j2se/1.5.0/docs/api/java/awt/Component.html#repaint%28int,%20int,%20int,%20int%29>.
>   That method arranges for a repaint to occur, but returns immediately; the
> painting happens in response to the artificial expose-like event created.
> (Such events may then be intelligently coalesced by the toolkit to paint
> larger areas in one pass.)

Gtk+ has something similar, but raw X or Xt for that matter hasn't.
Not that it would be very difficult for Emacs to implement it, but would it be 
worth it?  What should the tty-code do?

	Jan D.

Re: Emacs and Gnome Canvas

[YAMAMOTO Mitsuharu]

>>>>> On Fri, 16 Jul 2010 19:38:43 +0200, Jan Djärv <jan.h.d@swipnet.se> said:

>> I think it means "inform the X server that a region needs to be
>> redrawn, as if it had just been exposed".  I don't know if X even
>> supports this idea, but I know it from Java:
>> <http://java.sun.com/j2se/1.5.0/docs/api/java/awt/Component.html#repaint%28int,%20int,%20int,%20int%29>.
>> That method arranges for a repaint to occur, but returns
>> immediately; the painting happens in response to the artificial
>> expose-like event created.  (Such events may then be intelligently
>> coalesced by the toolkit to paint larger areas in one pass.)

> Gtk+ has something similar, but raw X or Xt for that matter hasn't.
> Not that it would be very difficult for Emacs to implement it, but
> would it be worth it?  What should the tty-code do?

I don't think tty-code is affected.  The question "which part should
be updated" is common, and "how to update" is already under the
control of RIF.

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

Re: Emacs and Gnome Canvas

[Eli Zaretskii]

> Date: Sat, 17 Jul 2010 10:12:16 +0900
> From: YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp>
> Cc: Chong Yidong <cyd@stupidchicken.com>,
> 	Óscar Fuentes <ofv@wanadoo.es>, emacs-devel@gnu.org
> 
> >>>>> On Fri, 16 Jul 2010 19:38:43 +0200, Jan Djärv <jan.h.d@swipnet.se> said:
> 
> > Gtk+ has something similar, but raw X or Xt for that matter hasn't.
> > Not that it would be very difficult for Emacs to implement it, but
> > would it be worth it?  What should the tty-code do?
> 
> I don't think tty-code is affected.  The question "which part should
> be updated" is common, and "how to update" is already under the
> control of RIF.

That's not true, at least not for some value of "how to update".

Perhaps you should describe in more detail what you include in "which
part should be updated" and what in "how to update".  Then we will
have a common language to talk in.

Re: Emacs and Gnome Canvas

[YAMAMOTO Mitsuharu]

>>>>> On Sat, 17 Jul 2010 10:14:08 +0300, Eli Zaretskii <eliz@gnu.org> said:

>> I don't think tty-code is affected.  The question "which part
>> should be updated" is common, and "how to update" is already under
>> the control of RIF.

> That's not true, at least not for some value of "how to update".

> Perhaps you should describe in more detail what you include in
> "which part should be updated" and what in "how to update".  Then we
> will have a common language to talk in.

Glyph matrices comparison belongs to the former, which does not need
to change.  And RIF operations such as write_glyphs belong to the
latter, which would require changes but is already separated between
window-system and tty.

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

Re: Emacs and Gnome Canvas

[Eli Zaretskii]

> Date: Sat, 17 Jul 2010 16:31:10 +0900
> From: YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp>
> Cc: jan.h.d@swipnet.se,
> 	ofv@wanadoo.es,
> 	cyd@stupidchicken.com,
> 	fuente@proofpoint1.lanl.gov,
> 	emacs-devel@gnu.org
> 
> >>>>> On Sat, 17 Jul 2010 10:14:08 +0300, Eli Zaretskii <eliz@gnu.org> said:
> 
> >> I don't think tty-code is affected.  The question "which part
> >> should be updated" is common, and "how to update" is already under
> >> the control of RIF.
> 
> > That's not true, at least not for some value of "how to update".
> 
> > Perhaps you should describe in more detail what you include in
> > "which part should be updated" and what in "how to update".  Then we
> > will have a common language to talk in.
> 
> Glyph matrices comparison belongs to the former, which does not need
> to change.  And RIF operations such as write_glyphs belong to the
> latter, which would require changes but is already separated between
> window-system and tty.

There's a large portion of redisplay that belongs to none of these
two: the try_window method and its work-horse display_line.  These
produce, for each window, the portions of its glyph matrix that do
need to change.  This code is platform independent (although some of
its parts are not run for tty frames), and it runs _before_ the
write_glyphs methods.

Re: Emacs and Gnome Canvas

[YAMAMOTO Mitsuharu]

>>>>> On Sat, 17 Jul 2010 11:12:00 +0300, Eli Zaretskii <eliz@gnu.org> said:

>> Glyph matrices comparison belongs to the former, which does not
>> need to change.  And RIF operations such as write_glyphs belong to
>> the latter, which would require changes but is already separated
>> between window-system and tty.

> There's a large portion of redisplay that belongs to none of these
> two: the try_window method and its work-horse display_line.  These
> produce, for each window, the portions of its glyph matrix that do
> need to change.  This code is platform independent (although some of
> its parts are not run for tty frames), and it runs _before_ the
> write_glyphs methods.

The part runs before write_glyphs does not need to change.

In the extreme case, it could be sufficient to just replace low-level
drawing API calls such as XFillRectangle with some other API calls to
add dirty rectangle.  But this is so low-level and inefficient, and
more high-level drawing function can take care of the addition of the
dirty area in an earlier stage.

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

Re: Emacs and Gnome Canvas

[Jan Djärv]

Eli Zaretskii skrev 2010-07-15 14.27:
>
> Inserting one character moves all the attributes after it by one
> character position, doesn't it?
>

Yes, but that is something the Canvas can do by itself.

>> You wouldn't have to do redisplay all the time just in case
>> something changed (like now)
>
> ?? We don't _do_ redisplay now all the time.  We _enter_ redisplay
> every time Emacs is idle, but if nothing's changed, we exit it almost
> immediately, after testing a bunch of flags.
>

That is the same thing to me.  With the Canvas design, you would not need to 
check, once it is done Canvas does all repainting as needed.

>> if you propagated the change the whole way when it happened.  This
>> is a big difference on how Emacs works now.
>
> The way it looks, parts of the current redisplay code will have to run
> whenever there's a change, any change, to some buffer or some related
> data structure.  If the parts affected by these changes are not
> displayed, or become not displayed before the GTK+ idle handlers run,
> propagating those changes would be a waste of CPU cycles.

No, they need to be done anyway sometime, it is no waste.  If the text isn't 
displayed, the attributes are nvertheless set up correctly for the time when 
the text is to be displayed later (by scrolling for example).  The Canvas just 
have to scroll things in view and the display is up to date.  If they never 
come into view, then there is a waste of CPU cycles.

Now in Emacs you postpone the update until it is in view.  With the canvas you 
would do the update at once, but you then don't have to bother with it 
anymore, for example if it comes in to view later.  It should be about the 
same CPU-cycles, just distributed differently.

>
> So you win some and you lose some.  Not sure about the balance.
> Basically, scrolling should be very fast (assuming it is done entirely
> on the Canvas side), but I'm not sure if everything else won't be
> significantly slower.
>

If done right, I don't think it would be slower.  But someone has to do the 
code before we know.

	Jan D.

Re: Emacs and Gnome Canvas

[Eli Zaretskii]

> Date: Thu, 15 Jul 2010 16:24:27 +0200
> From: Jan Djärv <jan.h.d@swipnet.se>
> Cc: ofv@wanadoo.es, emacs-devel@gnu.org
> 
> > The way it looks, parts of the current redisplay code will have to run
> > whenever there's a change, any change, to some buffer or some related
> > data structure.  If the parts affected by these changes are not
> > displayed, or become not displayed before the GTK+ idle handlers run,
> > propagating those changes would be a waste of CPU cycles.
> 
> No, they need to be done anyway sometime, it is no waste.  If the text isn't 
> displayed, the attributes are nvertheless set up correctly for the time when 
> the text is to be displayed later (by scrolling for example).

By which time those attributes could have recomputed many times, for
just one display!

> If done right, I don't think it would be slower.  But someone has to do the 
> code before we know.

Well, naturally, if "done right"s definition is "to be no slower" ;-)

Re: Emacs and Gnome Canvas

[Jan Djärv]

2010-07-15 16:35, Eli Zaretskii skrev:
>> Date: Thu, 15 Jul 2010 16:24:27 +0200
>> From: Jan Djärv<jan.h.d@swipnet.se>
>> Cc: ofv@wanadoo.es, emacs-devel@gnu.org
>>
>> No, they need to be done anyway sometime, it is no waste.  If the text isn't
>> displayed, the attributes are nvertheless set up correctly for the time when
>> the text is to be displayed later (by scrolling for example).
>
> By which time those attributes could have recomputed many times, for
> just one display!
>

That may be so.  But there is nothing actually displayed, you just do a update 
of the attributes.  I'm sure one could hook in to the scroll bars and just 
update the visible portion if that is needed.

>> If done right, I don't think it would be slower.  But someone has to do the
>> code before we know.
>
> Well, naturally, if "done right"s definition is "to be no slower" ;-)
>

Isn't that always implied by "right"?

	Jan D.

Re: Emacs and Gnome Canvas

[Eli Zaretskii]

> Date: Thu, 15 Jul 2010 17:16:31 +0200
> From: Jan Djärv <jan.h.d@swipnet.se>
> CC: ofv@wanadoo.es, emacs-devel@gnu.org
> 
> 2010-07-15 16:35, Eli Zaretskii skrev:
> >> Date: Thu, 15 Jul 2010 16:24:27 +0200
> >> From: Jan Djärv<jan.h.d@swipnet.se>
> >> Cc: ofv@wanadoo.es, emacs-devel@gnu.org
> >>
> >> No, they need to be done anyway sometime, it is no waste.  If the text isn't
> >> displayed, the attributes are nvertheless set up correctly for the time when
> >> the text is to be displayed later (by scrolling for example).
> >
> > By which time those attributes could have recomputed many times, for
> > just one display!
> >
> 
> That may be so.  But there is nothing actually displayed, you just do a update 
> of the attributes.

This "just" is the hottest bottleneck of the current display engine.
That's why we try so hard to avoid it.

> I'm sure one could hook in to the scroll bars and just update the
> visible portion if that is needed.

I don't think updating the scroll bar is an important CPU user in
today's redisplay.

> >> If done right, I don't think it would be slower.  But someone has to do the
> >> code before we know.
> >
> > Well, naturally, if "done right"s definition is "to be no slower" ;-)
> >
> 
> Isn't that always implied by "right"?

Of course.

Re: Emacs and Gnome Canvas

[Jan Djärv]

2010-07-15 17:20, Eli Zaretskii skrev:
>> Date: Thu, 15 Jul 2010 17:16:31 +0200
>> From: Jan Djärv<jan.h.d@swipnet.se>
>> CC: ofv@wanadoo.es, emacs-devel@gnu.org
>>
>> 2010-07-15 16:35, Eli Zaretskii skrev:
>>>> Date: Thu, 15 Jul 2010 16:24:27 +0200
>>>> From: Jan Djärv<jan.h.d@swipnet.se>
>>>> Cc: ofv@wanadoo.es, emacs-devel@gnu.org
>>>>
>>>> No, they need to be done anyway sometime, it is no waste.  If the text isn't
>>>> displayed, the attributes are nvertheless set up correctly for the time when
>>>> the text is to be displayed later (by scrolling for example).
>>>
>>> By which time those attributes could have recomputed many times, for
>>> just one display!
>>>
>>
>> That may be so.  But there is nothing actually displayed, you just do a update
>> of the attributes.
>
> This "just" is the hottest bottleneck of the current display engine.
> That's why we try so hard to avoid it.

I would have thought that the actual drawing would be the bottleneck.  Not 
that I benchmarked or anything.


>
>> I'm sure one could hook in to the scroll bars and just update the
>> visible portion if that is needed.
>
> I don't think updating the scroll bar is an important CPU user in
> today's redisplay.
>

I meant that you can update the portion that is visible and postpone update of 
the other parts until they become visible.

	Jan D.

Re: Emacs and Gnome Canvas

[Andy Wingo]

On Thu 15 Jul 2010 08:55, Eli Zaretskii <eliz@gnu.org> writes:

>> From: Óscar Fuentes <ofv@wanadoo.es>
>> Date: Wed, 14 Jul 2010 23:24:03 +0200
>> 
>> I'm very interested on this. Which are those requirements that gnome's
>> canvas can not meet?
>
> To answer that, we need someone with good knowledge of both the
> requirements of the Emacs display engine and of the features and
> possibilities of the Gnome Canvas library.

libgnomecanvas is, if not deprecated, at least discouraged;
unfortunately GNOME people do not know what its successor is yet. There
is FooCanvas, and GooCanvas, and HippoCanvas, and ...

Don't look to GNOME for clarity on this point.

Andy
-- 
http://wingolog.org/

Re: Emacs and Gnome Canvas (was: Emacs, QT and Cairo)

[Dirk-Jan C. Binnema]

Hi,

>>>>> On Thu, 15 Jul 2010 09:55:53 +0300, Eli Zaretskii ("EZ") wrote:

  >> From: Óscar Fuentes <ofv@wanadoo.es>
  >> Date: Wed, 14 Jul 2010 23:24:03 +0200
  >> 
  >> I'm very interested on this. Which are those requirements that gnome's
  >> canvas can not meet?

  EZ> To answer that, we need someone with good knowledge of both the
  EZ> requirements of the Emacs display engine and of the features and
  EZ> possibilities of the Gnome Canvas library.  Do we have such an
  EZ> individual?

Note, gnome-canvas is being deprecated;
   http://live.gnome.org/ProjectRidley/CanvasOverview
has an overview of various alternatives.

As far as I know them, all these canvases are primarily designed for graphics,
with object, group/ungroup etc. It remains to be seen how well they would work
for large amounts of text, with maybe here and there an image. Performance
might be an issue.

Maybe something working on top of Cairo (as has been suggested) would work
better. Cairo also has the advantage of being multiplatform and widely used
(e.g., Firefox), which gives some indication of speed/capabilities. However, I
think quite a bit of work would be needed -- the Firefox rendering engine
(Gecko) might provide some insight.

For what emacs needs, I think that the various canvases do not really provide
much added value compared to 'straight' Cairo (or some other lower-level
system).

Best wishes,
Dirk.

-- 
Dirk-Jan C. Binnema                  Helsinki, Finland
e:djcb@djcbsoftware.nl           w:www.djcbsoftware.nl
pgp: D09C E664 897D 7D39 5047 A178 E96A C7A1 017D DA3C

Re: Emacs and Gnome Canvas

[Óscar Fuentes]

Dirk-Jan C. Binnema <djcb.bulk@gmail.com> writes:

> Note, gnome-canvas is being deprecated;
>    http://live.gnome.org/ProjectRidley/CanvasOverview
> has an overview of various alternatives.
>
> As far as I know them, all these canvases are primarily designed for
> graphics, with object, group/ungroup etc. It remains to be seen how
> well they would work for large amounts of text, with maybe here and
> there an image. Performance might be an issue.

IIRC there are some cases of text editors implemented on top of a
canvas. IIRC Tk's text widget, which is the basis for several text
editors, is one of them. I've not observed performance issues when used
those editors, although Emacs' requirements can be more demanding.

> Maybe something working on top of Cairo (as has been suggested) would
> work better.

The problem with Cairo is that AFAIK it doesn't provide any kind of user
interaction features and adding them is far from trivial. Maybe Gecko
provides the necessary for web forms and clickable areas, but that is
not enough. Qt's Graphics Framework seems more appealing as an starting
point.

[snip]

Re: Emacs and Gnome Canvas

[Bruce Stephens]

Óscar Fuentes <ofv@wanadoo.es> writes:

[...]

> IIRC there are some cases of text editors implemented on top of a
> canvas. IIRC Tk's text widget, which is the basis for several text
> editors, is one of them.

I don't think it is.  Tk's text widget is separate from Tk's canvas as
far as I know.  Tk's canvas does have significant scaling issues (or
used to have, anyway).

Not that one shouldn't or couldn't use some canvas for a text editor,
but I don't think there's good evidence that Tk's canvas would be
suitable.

[...]

Re: Emacs, QT and Cairo

[Stefan Monnier]

> It would be interesting to see an analysis of emacs' redisplay needs
> in light of modern cpu/gpu/network usage, or even a list of needs for
> emacs' redisplay priorities.  I recall the 18->19->20 discussions
> vaguely, but I'm willing to wager that there are far fewer people
> using x-terminals over 14.4k modem lines these days.  :-)

I don't know about remote uses (I don't use them very often other than
through terminal emulators), but at least local redisplay is currently
borderline too slow in many of my use cases.  Now I don't have much of
a clue about where the time is spent (maybe it's not really in
redisplay), but at least performance is still an issue.


        Stefan

Re: Emacs, QT and Cairo

[Chad Brown]

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

On Jul 27, 2010, at 2:24 PM, Stefan Monnier wrote:
> 
> I don't know about remote uses (I don't use them very often other than
> through terminal emulators), but at least local redisplay is currently
> borderline too slow in many of my use cases.  Now I don't have much of
> a clue about where the time is spent (maybe it's not really in
> redisplay), but at least performance is still an issue.

I agree entirely, and yet many of the other editors that are doing similar 
things (by which I mean primarily syntax-aware highlighting of various 
stripes) seem to be faster (at that part) than emacs and yet rely more 
heavily on graphical toolkits and provided widgets for such features.   I 
don't think that we could just `switch' to such techniques for emacs, but it
might be interesting to see how much more we could lean on existing gui
efforts.  Basically, I'm guessing that those projects spend a lot of time on 
graphical performance, and wondering (blue-sky, again) if we mightn't be 
able to add some capability and also some performance by trying to make
more use of other people's efforts.  For (very rough) example, the 
conversation between Yamamoto Mitsuharu and Jan Djärv about using 
toolkit exposure/clipping handling rather than trying to add our own.

My feeling is that redisplay's slowness comes from complicated font-lock
operations and the like.   Are there any other known sources of slow local
redisplay?   

*Chad

[-- Attachment #2: Type: text/html, Size: 1967 bytes --]

Re: Emacs, QT and Cairo

[Eli Zaretskii]

> From: Chad Brown <yandros@MIT.EDU>
> Date: Tue, 27 Jul 2010 14:36:00 -0700
> Cc: Emacs development discussions <emacs-devel@gnu.org>
> 
> My feeling is that redisplay's slowness comes from complicated font-lock
> operations and the like.   Are there any other known sources of slow local
> redisplay?   

Why don't you profile it and see?

Re: Emacs, QT and Cairo Was: Re: Efforts to attract more users?

[YAMAMOTO Mitsuharu]

>>>>> On Tue, 13 Jul 2010 16:02:02 -0300, Stephen Eilert <spedrosa@gmail.com> said:

> What about exposing Cairo bindings (GTK already uses it, so it is
> not exactly a new dependency, only the headers) to elisp so that we
> can actually draw a prettier user interface? Things like real lines
> instead of "-" for the modeline (and a better looking modeline
> itself), better looking widgets (the horrendous fake buttons created
> by customize, for example), better fringe layer or even, say, an UML
> mode with good-looking classes. And perhaps a cute speedbar.

An alternative way to do some of them would be generating and
rendering SVG images dynamically.  That is possible even now, and more
standard and less platform specific than cairo bindings.  An
interesting example is given in
http://lists.gnu.org/archive/html/bug-gnu-emacs/2010-05/msg00521.html

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

Re: Emacs, QT and Cairo

[David Engster]

YAMAMOTO Mitsuharu writes:
>>>>>> On Tue, 13 Jul 2010 16:02:02 -0300, Stephen Eilert <spedrosa@gmail.com> said:
>
>> What about exposing Cairo bindings (GTK already uses it, so it is
>> not exactly a new dependency, only the headers) to elisp so that we
>> can actually draw a prettier user interface? Things like real lines
>> instead of "-" for the modeline (and a better looking modeline
>> itself), better looking widgets (the horrendous fake buttons created
>> by customize, for example), better fringe layer or even, say, an UML
>> mode with good-looking classes. And perhaps a cute speedbar.
>
> An alternative way to do some of them would be generating and
> rendering SVG images dynamically.  That is possible even now, and more
> standard and less platform specific than cairo bindings.  An
> interesting example is given in
> http://lists.gnu.org/archive/html/bug-gnu-emacs/2010-05/msg00521.html

Yes, one could probably create buttons and stuff like that with SVG. But
the way images are handled in Emacs make this very limited. I'm not even
talking about eye candy here, but very basic things. For example,
drawing a faint line at column 80, like this:

http://blogs.sun.com/tor/resource/formatting-before.png

I think it is currently not possible to do stuff like this?

-David

Re: Emacs, QT and Cairo

[Jan Djärv]

David Engster skrev 2010-07-14 11.41:

>
> Yes, one could probably create buttons and stuff like that with SVG. But
> the way images are handled in Emacs make this very limited. I'm not even
> talking about eye candy here, but very basic things. For example,
> drawing a faint line at column 80, like this:
>
> http://blogs.sun.com/tor/resource/formatting-before.png
>
> I think it is currently not possible to do stuff like this?

I don't think the display engine is up to the job for that.  AFAIK, it lacks 
the ability to put stuff at absolute coordinates, like your line that always 
should be a column 80.  It is more text oriented and text flows one character 
after another.  Also, unless I'm mistaken, it doesn't handle stacking, i.e. 
shall the line go over or under text?

Making a lisp function that draws lines is not that hard.  Handling redisplay 
of the line when something changes is the hard part.

	Jan D.

RE: Emacs, QT and Cairo

[Drew Adams]

> http://blogs.sun.com/tor/resource/formatting-before.png
> I think it is currently not possible to do stuff like this?

Depends what you mean by "stuff like this".  See vline.el and col-highlight.el

http://www.emacswiki.org/emacs/HighlightCurrentColumn

Re: Emacs, QT and Cairo

[David Engster]

Drew Adams writes:
>> http://blogs.sun.com/tor/resource/formatting-before.png
>> I think it is currently not possible to do stuff like this?
>
> Depends what you mean by "stuff like this".  See vline.el and col-highlight.el
>
> http://www.emacswiki.org/emacs/HighlightCurrentColumn

I mean stuff like "draw a line with a width of 1 pixel transparently at
a certain position in this buffer". For example, instead of a different
background color, I would like to draw a rectangle around code forming
one semantic tag in the Minimap. Another one: I think faint lines
hinting at the indentation level might be useful at times, like Komodo
does it:

http://delimitdesign.com/wp-content/uploads/2009/03/komodo-edit-text-editor.jpg

I know I can use overlays to approximate that, but I'd have to jump
through hoops to get there (just look at the code in vline.el), and in
the end it's often slow and you have to make compromises (vline vanishes
while scrolling, for example). And it would probably even look ugly...

Regards,
David

Re: Emacs, QT and Cairo

[joakim]

David Engster <deng@randomsample.de> writes:

> Drew Adams writes:
>>> http://blogs.sun.com/tor/resource/formatting-before.png>> I think it is currently not possible to do stuff like this?
>>
>> Depends what you mean by "stuff like this".  See vline.el and col-highlight.el
>>
>> http://www.emacswiki.org/emacs/HighlightCurrentColumn
>
> I mean stuff like "draw a line with a width of 1 pixel transparently at
> a certain position in this buffer". For example, instead of a different
> background color, I would like to draw a rectangle around code forming
> one semantic tag in the Minimap. Another one: I think faint lines
> hinting at the indentation level might be useful at times, like Komodo
> does it:
>
> http://delimitdesign.com/wp-content/uploads/2009/03/komodo-edit-text-editor.jpg
>
> I know I can use overlays to approximate that, but I'd have to jump
> through hoops to get there (just look at the code in vline.el), and in
> the end it's often slow and you have to make compromises (vline vanishes
> while scrolling, for example). And it would probably even look ugly...

There are patches around that allows the buffer background to be an
image. That support could perhaps be tweaked to allow an SVG, generated
from elisp.

It would probably be difficult to keep the SVG and the buffer text in
sync though.




> Regards,
> David
-- 
Joakim Verona

Re: Emacs, QT and Cairo Was: Re: Efforts to attract more users?

[Chong Yidong]

YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> writes:

> An alternative way to do some of them would be generating and
> rendering SVG images dynamically.  That is possible even now, and more
> standard and less platform specific than cairo bindings.

I've been told that librsvg is not useable on Windows, which is
unfortunate.  Otherwise, it would be nice to standardize on SVG for
graphical elements in Emacs.

Re: Emacs, QT and Cairo Was: Re: Efforts to attract more users?

[joakim]

Chong Yidong <cyd@stupidchicken.com> writes:

> YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> writes:
>
>> An alternative way to do some of them would be generating and
>> rendering SVG images dynamically.  That is possible even now, and more
>> standard and less platform specific than cairo bindings.
>
> I've been told that librsvg is not useable on Windows, which is
> unfortunate.  Otherwise, it would be nice to standardize on SVG for
> graphical elements in Emacs.

On that note, it seems imagemagick simply links to librsvg for its svg
support.

But is librsvg really not usable on windoze? Gnome seem to provide
binaries anyway:

http://ftp.gnome.org/pub/gnome/binaries/win32/librsvg/2.26/

-- 
Joakim Verona

Re: Emacs, QT and Cairo Was: Re: Efforts to attract more users?

[Jan Djärv]

joakim@verona.se skrev 2010-07-14 18.17:
> Chong Yidong<cyd@stupidchicken.com>  writes:
>
>> YAMAMOTO Mitsuharu<mituharu@math.s.chiba-u.ac.jp>  writes:
>>
>>> An alternative way to do some of them would be generating and
>>> rendering SVG images dynamically.  That is possible even now, and more
>>> standard and less platform specific than cairo bindings.
>>
>> I've been told that librsvg is not useable on Windows, which is
>> unfortunate.  Otherwise, it would be nice to standardize on SVG for
>> graphical elements in Emacs.
>
> On that note, it seems imagemagick simply links to librsvg for its svg
> support.
>
> But is librsvg really not usable on windoze? Gnome seem to provide
> binaries anyway:
>
> http://ftp.gnome.org/pub/gnome/binaries/win32/librsvg/2.26/

AFAIK, it uses cairo for rendering and is dependent on lot of other (Gnome) 
libraries.  They are available at the same place, but I don't know exactly 
which libraries.

	Jan D.

Re: Emacs, QT and Cairo Was: Re: Efforts to attract more users?

[Andrew W. Nosenko]

On Tue, Jul 13, 2010 at 22:02, Stephen Eilert <spedrosa@gmail.com> wrote:
> On Mon, Jul 12, 2010 at 2:25 PM, Bernardo Barros
> <bernardobarros2@gmail.com> wrote:
>> many people in the gnu world are using qt4. are there reasons not to
>> consider it?

From my experience, binding C++ library into C program is not the best
way to spend your free time.  But it is my personal expirience and
opinion. Your mileage may vary.

>>
>
> Does it matter?
>
> You see, it is not like Emacs has stretched GTK's capabilities to the
> limit. Actually there isn't much being used: menu, the window itself,
> scrollbars and a very primitive toolbar (that I always turn off), as
> far as I can tell.
>
> What about exposing Cairo bindings (GTK already uses it, so it is not
> exactly a new dependency, only the headers) to elisp so that we can
> actually draw a prettier user interface? Things like real lines
> instead of "-" for the modeline (and a better looking modeline
> itself), better looking widgets (the horrendous fake buttons created
> by customize, for example), better fringe layer or even, say, an UML
> mode with good-looking classes. And perhaps a cute speedbar.

May be better to start not from Cairo, but from starting using GTK+
itself?  IMHO you don't need Cairo for draw the GTK button widget (may
be GTK itself need cairo for this, but it's GTK's problem, not your,
and buttons were there far before cairo was started at all :-).  May
be you need Cairo for _simulate_ the current button widget look, but
IMO better to just use the real button instead of simulating it.

Yet another example: scrollbars.  I remember discussions where better
to place them by default.  But I don't remember anyone who pointed
that position of scrollbars controlled by and desktop environment and
gtkrc (GTK+ semi-analog of xrdb).  Where scrollbar should be?  --
there where the rest of of desktop places it and controlled from the
place where the rest of desktop controlled.  Of course it may and
should be able to be customized on per-application basis and Emacs
here far ahead of the rest.  But...  But why speaking about scrollbar
on the right vs. scrollbar on the left [by default] no one mentioned
third possibility: the desktop default setting?

Thus, my personal humble opinion: may be instead of introducing the
new tool it would be better just to exploit better/deeper the current
(and, by the way, the very powerful) tool?

>
> Yes, looks do matter. Most Emacs screenshots look kinda dated and
> primitive - and this carries over to the overall perception. I've
> added hundreds of lines to my .emacs for looks alone, but I can't draw
> something better programatically.
>
>
> --Stephen
>
> Sent from my Emacs
>
>

-- 
Andrew W. Nosenko <andrew.w.nosenko@gmail.com>

Re: Emacs, QT and Cairo Was: Re: Efforts to attract more users?

[Jan Djärv]

Andrew W. Nosenko skrev 2010-07-16 01.15:
> Yet another example: scrollbars.  I remember discussions where better
> to place them by default.  But I don't remember anyone who pointed
> that position of scrollbars controlled by and desktop environment and
> gtkrc (GTK+ semi-analog of xrdb).  Where scrollbar should be?  --
> there where the rest of of desktop places it and controlled from the
> place where the rest of desktop controlled.  Of course it may and
> should be able to be customized on per-application basis and Emacs
> here far ahead of the rest.  But...  But why speaking about scrollbar
> on the right vs. scrollbar on the left [by default] no one mentioned
> third possibility: the desktop default setting?

AFAIK, there is no desktop setting for scroll bar placements in GNOME, or by 
theme.

	Jan D.

Re: Emacs, QT and Cairo Was: Re: Efforts to attract more users?

[Andrew W. Nosenko]

On Fri, Jul 16, 2010 at 10:41, Jan Djärv <jan.h.d@swipnet.se> wrote:
>
>
> Andrew W. Nosenko skrev 2010-07-16 01.15:
>>
>> Yet another example: scrollbars.  I remember discussions where better
>> to place them by default.  But I don't remember anyone who pointed
>> that position of scrollbars controlled by and desktop environment and
>> gtkrc (GTK+ semi-analog of xrdb).  Where scrollbar should be?  --
>> there where the rest of of desktop places it and controlled from the
>> place where the rest of desktop controlled.  Of course it may and
>> should be able to be customized on per-application basis and Emacs
>> here far ahead of the rest.  But...  But why speaking about scrollbar
>> on the right vs. scrollbar on the left [by default] no one mentioned
>> third possibility: the desktop default setting?
>
> AFAIK, there is no desktop setting for scroll bar placements in GNOME, or by
> theme.

Exists since GTK+ 2.10

    http://library.gnome.org/devel/gtk/unstable/GtkSettings.html#GtkSettings--gtk-scrolled-window-placement

For set it by hand, for example, for place vertical scrollbar to the
left by default you may add following line to your ~/.gtkrc-2.0

    gtk-scrolled-window-placement = top-right

-- 
Andrew W. Nosenko <andrew.w.nosenko@gmail.com>

Re: Emacs, QT and Cairo Was: Re: Efforts to attract more users?

[Jan Djärv]

Andrew W. Nosenko skrev 2010-07-16 12.24:
> On Fri, Jul 16, 2010 at 10:41, Jan Djärv<jan.h.d@swipnet.se>  wrote:
>>
>>
>> Andrew W. Nosenko skrev 2010-07-16 01.15:
>>>
>>> Yet another example: scrollbars.  I remember discussions where better
>>> to place them by default.  But I don't remember anyone who pointed
>>> that position of scrollbars controlled by and desktop environment and
>>> gtkrc (GTK+ semi-analog of xrdb).  Where scrollbar should be?  --
>>> there where the rest of of desktop places it and controlled from the
>>> place where the rest of desktop controlled.  Of course it may and
>>> should be able to be customized on per-application basis and Emacs
>>> here far ahead of the rest.  But...  But why speaking about scrollbar
>>> on the right vs. scrollbar on the left [by default] no one mentioned
>>> third possibility: the desktop default setting?
>>
>> AFAIK, there is no desktop setting for scroll bar placements in GNOME, or by
>> theme.
>
> Exists since GTK+ 2.10
>
>      http://library.gnome.org/devel/gtk/unstable/GtkSettings.html#GtkSettings--gtk-scrolled-window-placement
>
> For set it by hand, for example, for place vertical scrollbar to the
> left by default you may add following line to your ~/.gtkrc-2.0
>
>      gtk-scrolled-window-placement = top-right
>

This only applies to GtkScrolledWindow according to the documentation:

"Specifies which corner a child widget should be placed in when packed into a 
GtkScrolledWindow.".

And there is no Gnome preference panel way to set it.  But we could use it I 
guess.

	Jan D.