bug#72830: Big rectangular selections are slow

["Mattias Engdegård" <mattias.engdegard@gmail.com>]

22 sep. 2024 kl. 16.12 skrev Stefan Monnier <monnier@iro.umontreal.ca>:

> IIRC from the last time I looked at that code, I got the impression that
> the design was made [pun ahead!] primarily for the CLIPBOARD selection
> and *should* work something like this:
> - when we make a new selection, we tell X11 that we own the CLIPBOARD.
>  This should be an O(1) operation.
> - when the selection changes because we move point or mark, we don't
>  need to do anything.
> - we get the content of that selection (an O(N) operation) only if/when
>  X11 asks for it.
> - in order to still be able to send the CLIPBOARD's content after the
>  selection has disappeared, we pay the O(N) cost when the region is
>  deactivated and "squirrelled away" (like you say) that content.

I don't think an X11 client should ever claim CLIPBOARD ownership merely for marking a selection, as opposed to issuing a 'Copy[ to clipboard]' operation, but seem to recall that it did happen with some broken clients. PRIMARY is indeed different and that's probably what confused programmers back in the day, especially since old clients like Xterm emphasised the use of PRIMARY.

> So the big rectangular selections should slow down only steps 3 and
> 4 but not step 1 or 2.  And as you point out, maybe step 4 could/should
> be skipped for PRIMARY, tho I'm not sure in which cases it would
> be beneficial (beside those cases where the region is so large that the
> O(N) cost is a problem).

The O(N) cost in time and space is a problem. X11 convention is that PRIMARY is available for as long as the selection is visibly marked in the client.
[ What happens if another client claims PRIMARY? The first (losing) client typically has two choices: either remove the selection so that the user sees that the selection is no more (the classic Xterm way), or repaint it in a 'local-only' colour to show that it can still be used for other purposes. ]

> Of course, if needed, maybe the step 4 could be made faster by
> squirreling away not the exact rectangular region, but something that
> can be computed more quickly and from which we can later still extract
> the exact rectangular region if/when needed.

Yes, we'd need some sort of current-selection-extent object. The question is, what should its lifetime be?

A. For as long as the selection is active
B. Until buffer is modified
C. Indefinitely, using absolute buffer offsets
D. Indefinitely, using markers

I'd suggest A because that's closest to X11 practice. B would be doable. C and D are taking it too far and recovering a rectangle would be a mess.