[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
- Re: Pixel-based display functions, martin rudalics, 2015/02/01
- Re: Pixel-based display functions, Lars Ingebrigtsen, 2015/02/01
- Re: Pixel-based display functions, martin rudalics, 2015/02/01
- Re: Pixel-based display functions, Eli Zaretskii, 2015/02/01
- Re: Pixel-based display functions, martin rudalics, 2015/02/01
- Re: Pixel-based display functions, Eli Zaretskii, 2015/02/01
- Re: Pixel-based display functions, martin rudalics, 2015/02/01
- Re: Pixel-based display functions, Eli Zaretskii, 2015/02/01
- Re: Pixel-based display functions, Eli Zaretskii, 2015/02/01
- Re: Pixel-based display functions, Lars Ingebrigtsen, 2015/02/04