emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Pixel-based display functions


From: Stefan Monnier
Subject: Re: Pixel-based display functions
Date: Mon, 02 Feb 2015 18:16:27 -0500
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux)

> Not necessarily, since an HTML browser doesn't need to implement all
> the gazillion display features that redisplay needs to handle.  Not
> even close.  It just needs to render text with faces and sometimes
> with images.

Right, it only needs to faithfully model the parts that it uses.
That's still a lot of needless and hard work.

> I agree, and it does.  font-get-glyphs, window-text-pixel-size,
> vertical-motion, etc. all reuse the display engine code.

Right.  So we should do our best to make sure this same approach can be
used here.

>> > Second, there's a subtlety in move_it_* functions that was never
>> > explicitly raised in this discussion, but which becomes rather
>> > important if you want to consider reusing the move_it_* functions for
>> > this use case: they produce glyphs in the _visual_ order.  So if the
>> > text to be rendered includes R2L characters, you might break text
>> > between screen lines incorrectly.  (If this isn't clear enough, I can
>> > elaborate.)  Also, you will have to deal with the situation where
>> > (position-of-pixel-in-text FROM TO) is _less_ than
>> > (position-of-pixel-in-text FROM (1- TO)).  That is a complication that
>> > Lars would surely like to avoid, I presume.  By contrast,
>> > font-get-glyphs works in the logical order.
>> I think solving this problem is *hard*.
> I explicitly suggested a way that avoids the need to solve it.

Hmm.. maybe you're right that doing it in the logical order will work.

>> PS: who still would prefer refilling single-column text in the redisplay
>> itself, since it makes it lazy, and makes it work right even when the
>> buffer is displayed in different windows/frames with different fonts.
> I agree that this feature would be useful.  However, how to use it in
> this case is not clear to me: recall that there's no buffer to render
> here,

Hmm... I don't follow.  In the single-column case, SHR can generate the
buffer text directly without worrying about line-wrapping (just setting
up the redisplay line-wrapping according to the expected dimansions of
the column).


        Stefan



reply via email to

[Prev in Thread] Current Thread [Next in Thread]