[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Can we go GTK-only?
From: |
Eli Zaretskii |
Subject: |
Re: Can we go GTK-only? |
Date: |
Mon, 31 Oct 2016 22:50:21 +0200 |
> Date: Mon, 31 Oct 2016 13:54:38 -0400
> From: "Perry E. Metzger" <address@hidden>
> Cc: Daniel Colascione <address@hidden>, address@hidden,
> address@hidden, address@hidden
>
> > 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.
- Re: Can we go GTK-only?, (continued)
- Re: Can we go GTK-only?, Eli Zaretskii, 2016/10/30
- Re: Can we go GTK-only?, Perry E. Metzger, 2016/10/31
- Re: Can we go GTK-only?, Eli Zaretskii, 2016/10/31
- Re: Can we go GTK-only?, Daniel Colascione, 2016/10/31
- Re: Can we go GTK-only?, Eli Zaretskii, 2016/10/31
- Re: Can we go GTK-only?, Perry E. Metzger, 2016/10/31
- Re: Can we go GTK-only?,
Eli Zaretskii <=
- Re: Can we go GTK-only?, Eli Zaretskii, 2016/10/31
- Re: Can we go GTK-only?, Eli Zaretskii, 2016/10/31
- Re: Can we go GTK-only?, Ken Raeburn, 2016/10/31
- Re: Can we go GTK-only?, Eli Zaretskii, 2016/10/31
- Re: Can we go GTK-only?, Daniel Colascione, 2016/10/31