emacs-devel
[Top][All Lists]
Advanced

[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/



reply via email to

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