[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Pixel-based display functions
From: |
Lars Ingebrigtsen |
Subject: |
Re: Pixel-based display functions |
Date: |
Sat, 07 Feb 2015 02:22:26 +1100 |
User-agent: |
Gnus/5.130012 (Ma Gnus v0.12) Emacs/25.0.50 (gnu/linux) |
Eli Zaretskii <address@hidden> writes:
> When you "repeat", do you start from the part of the line that's left,
> without the part that is before the just-inserted newline, or from the
> original long one? The time it takes vertical-motion to do its job
> will be smaller if the line is shorter.
I start from the part of the line that's left.
> Also, try invoking vertical-motion from a position that is not
> immediately after a newline, I think this might speed it up a little
> more.
Ah, right.
> Why do you need to know what width you ended up with? Or maybe I
> don't understand "ended up with" when -- before or after
> vertical-motion did its job? IOW, do you need window-text-pixel-size
> for measuring the long unfilled line, or the lines after filling?
I need to measure the lines after filling so that I know how wide the
column ended up being. (This is to better use the available horizontal
space when rendering tables, which is quite important.)
>> It would be equivalent to a `window-text-pixel-size' that advances one
>> character at a time (since we'd avoid the entire `font-at' problem), and
>> returns an vector of pixel points (instead of calling move_it_to just
>> once).
>
> You are describing an implementation. Please describe the API and the
> contract instead.
Well, it depends on what's realistic to implement, really. If calling
`font-at' had been fast enough, I would have been happy sticking with
that, but it turned out not to be.
So the API kinda depends on what's feasible...
I think the ideal interface for this would be a function that returns
a vector of glyph widths in the region, possibly with one vector per
line.
So (glyph-pixel-widths FROM TO) =>
([4 5 10 12] [4 14 1] ...)
That would allow caching the computations so that they would only be
called once per (unfilled) buffer.
> Also, as long as you use these functions, there's still a problem with
> visual vs logical order that needs to be solved.
Yes.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog http://lars.ingebrigtsen.no/
- Re: Pixel-based display functions, (continued)
- Re: Pixel-based display functions, Stefan Monnier, 2015/02/05
- Re: Pixel-based display functions, Lars Ingebrigtsen, 2015/02/05
- Re: Pixel-based display functions, martin rudalics, 2015/02/06
- Re: Pixel-based display functions, Lars Ingebrigtsen, 2015/02/06
- Re: Pixel-based display functions, Eli Zaretskii, 2015/02/06
- Re: Pixel-based display functions, Lars Ingebrigtsen, 2015/02/06
- Re: Pixel-based display functions, Eli Zaretskii, 2015/02/06
- Re: Pixel-based display functions, Eli Zaretskii, 2015/02/06
- Re: Pixel-based display functions, Lars Ingebrigtsen, 2015/02/06
- Re: Pixel-based display functions, Eli Zaretskii, 2015/02/06
- Re: Pixel-based display functions,
Lars Ingebrigtsen <=
- Re: Pixel-based display functions, Eli Zaretskii, 2015/02/06
- Re: Pixel-based display functions, Lars Ingebrigtsen, 2015/02/06
- Re: Pixel-based display functions, Lars Ingebrigtsen, 2015/02/06
- Re: Pixel-based display functions, Lars Ingebrigtsen, 2015/02/07
- Re: Pixel-based display functions, Eli Zaretskii, 2015/02/07
- Re: Pixel-based display functions, Lars Ingebrigtsen, 2015/02/07
- Re: Pixel-based display functions, Eli Zaretskii, 2015/02/07
- Re: Pixel-based display functions, Lars Ingebrigtsen, 2015/02/07
- Re: Pixel-based display functions, Eli Zaretskii, 2015/02/07
- Re: Pixel-based display functions, Lars Ingebrigtsen, 2015/02/07