GNU bug report logs -
#72830
Big rectangular selections are slow
Previous Next
Full log
Message #14 received at submit <at> debbugs.gnu.org (full text, mbox):
27 aug. 2024 kl. 15.48 skrev Eli Zaretskii <eliz <at> gnu.org>:
> Does turning off auto-composition-mode help in any way?
I don't think so. Were you able to reproduce the problem?
> Also, since highlighting is AFAIR implemented as overlays, it slows
> down check_display_width, which I think would otherwise have moved
> very fast if you say there are no properties and no overlays.
Yes, overlays indeed seem to be at the heart of the problem.
27 aug. 2024 kl. 16.04 skrev Stefan Monnier <monnier <at> iro.umontreal.ca>:
>> - Slow `region-beginning` and `region-end`.
>> Fixed on master (3a8222e7).
>
> Seems unlikely.
It did show up on the profile, something had to be done. Before that change, (region-beginning) with the active region as in the example took 0.96 s on this machine. Now, maybe 30 µs.
>> - `select-active-regions` makes each selection change very expensive.
>> Can be set to nil by the user, but I really suggest that we change the
>> default to nil, at least for non-X11 since the default assumes old-school
>> X11 PRIMARY selection which is alien on most other platforms.
>
> Didn't think of that. Do we re-set the PRIMARY every time the (active)
> rectangular region is changed (i.e. after each key press)? That would
> make it non-scalable to large rectangular regions, indeed.
It's pretty bonkers, yes. There is even a noticeable slow-down with a single contiguous selection.
Fortunately the cure is easy.
> I thought the extraction of the region's content to put it into PRIMARY
> and friends happened more lazily (e.g. when another application
> requests the PRIMARY/CLIPBOARD, or when we deactivate the region).
That would indeed have made some kind of sense. If confined to X11, that is. And opt-in, even then.
> I don't think we want to try and optimize the operations here because
> that will only push the limit of what is "too large" a bit further.
Yes, but it is educational to see what the costs are
> More promising to me would be to try and skip any part of the buffer
> that's not displayed.
Yes, I see no reason for having the highlight overlay on something that can't be seen.
But how do we know what the viewport will be in `rectangle--highlight-for-redisplay`? Since it is redisplay that determines window-start and window-end, and it hasn't run yet, this puts us in some kind of chicken-egg situation. Maybe it has to be done inside redisplay.
This bug report was last modified 267 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.