Re: emacs rendering comparisson between emacs23 and emacs26.3

[martin rudalics]

>> To avoid confusion - what is 'time-it'?
>
>      (defmacro time-it (&rest forms)
>        "Time the running of a sequence of forms using `float-time'.
>      Call like this: \"M-: (time-it (foo ...) (bar ...) ...)\"."
>        `(let ((start (float-time)))
>          ,@forms
>          (- (float-time) start)))

Thanks.  But for 'mwheel-scroll' I would have to construct an EVENT
first.  I'm not yet sure how to that.

>> And please note that I did not say that I ran 'scroll-up'.  I did a
>> mouse wheel scroll as the OP of that bug requested ....
>
> Sorry.  I thought you were using poetic language when you wrote "one turn
> of the wheel".  I didn't have the context of the bug in my head.

Please have a look at Bug#40278 which is about mouse wheel scrolling, a
child frame, Windows 10 and dispextern.h.  People in that thread mainly
concentrated on the child frame but here on Debian all I needed to clog
my machine was to display dispextern.h and spin the mouse wheel.

> Just for comparison, would you please time (scroll-up) (sit-for 0) in
> xdisp.c on your machine, to give us a better sense of the relative
> speeds.

With your 'time-it' it gives me 0.32201647758483887 here (seconds?).  I
have not managed yet to put scroll-up's into a loop and redisplay after
each call so I could simulate/time the effect of mouse wheel rolling.

> For what it's worth, I've just tried a fast mouse-wheel scroll in xdisp.c
> in X Windows on my machine.  There was no noticeable lag.

"fast" is probably not sufficient.  Here a few rolls suffice to freeze
the Emacs frame for about 10 secs.  Maybe on your machine you need more
rolls.  Try to roll fast until you reach the end of the buffer.

I meanwhile suspect that one culprit might be the progressive squaring
in 'mwheel-scroll'.  But I don't understand that yet and do not see it
documented well.  Also, setting 'mouse-wheel-scroll-amount' to '(1) does
not seem to make any difference either.

martin