Re: Can we go GTK-only?

[Eli Zaretskii <eliz@gnu.org>]

> Date: Mon, 31 Oct 2016 13:54:38 -0400
> From: "Perry E. Metzger" <perry@piermont.com>
> Cc: Daniel Colascione <dancol@dancol.org>, raeburn@raeburn.org,
>  monnier@iro.umontreal.ca, emacs-devel@gnu.org
> 
> > That's exactly the part that needs to be carefully designed.  It is
> > nowhere near what we have now, because the current expression of
> > "the idea of what the desired layout should be" is the glyph
> > matrices, which in their present shape cannot be shared by several
> > processes.
> > 
> > I'm not even sure we could come up with a useful scheme that would
> > allow such a division in a way that will let the communications
> > between the two work efficiently.  It remains to be shown that this
> > is feasible.
> 
> So there would seem to be two obvious ways to keep the two
> matrices in sync. One would be to record all the changes made on the
> one side as they are made and serialize that. The other way would be
> to use a dynamic programming algorithm to find the minimum set of
> differences and transmit them. Given that redisplay is likely nearly
> continuous, I'd say the former makes more sense.

I think you are missing the point.  The hard part is to figure out how
to convey the information across the divide, without forcing the
receiving side to repeat a large part of the layout calculations and
face resolution that the sending side already did.

The rest is much easier, either way.

I suggest to look at the implementation of the write_glyphs method
that is invoked when a screen line or its part needs to be delivered
to the glass.  Specifically, look at 'struct glyph_string', which is
the object used to describe a series of glyphs the terminal-specific
back-end needs to draw.  You will see there what information is being
communicated to the back-end; dividing Emacs in two would need to find
a way to communicate the equivalent of that, without relying on common
memory.