[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: |
Fri, 06 Feb 2015 20:47:40 +1100 |
User-agent: |
Gnus/5.130012 (Ma Gnus v0.12) Emacs/25.0.50 (gnu/linux) |
Eli Zaretskii <address@hidden> writes:
>> So, basically, folding 1500 lines takes 1.24s, of which 1.17s is spent
>> in `vertical-motion' (plus function call overhead). (It's called a lot
>> of times because the lines are very long and need to be filled more than
>> once.)
>
> Can you explain why you need to call vertical-motion so many times?
shr inserts text as long lines into the buffer, and I then use
`vertical-motion' to go to the desired width, and then backtracking
finding a fill point using the kinsuko algorithm. Then a newline is
inserted, and we repeat until the line is completely filled.
>> But it's all kinda moot since `window-text-pixel-size' doesn't work on
>> non-displayed buffers (yet).
>
> window-text-pixel-size is equivalent to vertical-motion, so I don't
> understand why you need both. Can you explain?
`window-text-pixel-size' tells me what width I ended up with, while
`vertical-motion' goes to an approximate fill point.
>> I wonder whether a faster interface would be to have a version of
>> `window-text-pixel-size' that returns a vector of glyph sizes.
>
> ??? Isn't that font-get-glyphs that you already tried? If not, why
> not? What API would you like to have for that hypothetical function?
I though we established pretty thoroughly that for `font-get-glyphs' to
be a solution, we'd have to reimplement too much of the redisplay
algorithm in Emacs Lisp (what with segmenting on scripts and faces, and
then having to see whether a script uses multiple fonts, etc). And it
was too slow during my testing.
>> Of course, computing the vector may be unreasonably slow.
>
> It is again equivalent to vertical-motion and font-get-glyphs, so it's
> not slow. But I don't yet see the issue clearly enough to tell what
> could be done for you, so please post more information about what you
> are trying to do.
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). I haven't played with `window-text-pixel-size' at that level,
since Martin seems to feel that it's not possible to get it to work on
undisplayed buffers? But I may be misunderstanding what Martin was
saying...
--
(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, Eli Zaretskii, 2015/02/01
- Re: Pixel-based display functions, Lars Ingebrigtsen, 2015/02/04
- 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 <=
- 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, 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