Re: Pixel-based display functions

[Lars Ingebrigtsen]

Stefan Monnier <address@hidden> writes:

> Coding it in C can make it faster, but you still have the problem of
> laziness (which is a general problem for shr, by the way): how to only
> render the displayed part of the HTML document, which is crucial to get
> reasonable speed on non-small documents.

Well, large pages with simple layouts (i.e., single columns) render with
linear speed and aren't generally a major problem.

> That's the only I really care about, and I think there's much more of
> a chance that we can actually make it work reliably with good speed.
>
> If we do it using the "general" approach in Elisp, I'm afraid we won't
> make it work well enough within the foreseeable future (e.g. remember:
> one of the features of current info-mode is that it's very quick, so
> a replacement that introduces a 1s rendering delay whenever we switch to
> another page won't be good enough).

I see no reason why rendering a typical info node should take anything
approaching one second.  I mean, Emacs can display text fast, and shr
can lay out stuff fast.  If we had access to the pixel widths in advance
of redisplay.

(eww uses 0.04 seconds to display a typical Emacs manual node with a
fixed-width layout on this laptop, according to `benchmark-run'.)

I know nothing about how redisplay works, but would (conceptually)
saying to Emacs "hey, render this line" (generally very fast) "but don't
display it" (should be instantaneous) "and tell me how long that was"
(ditto) make sense?

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/