This bug is relevant to Draw and Impress, and perhaps other apps. Suppose you make a selection of a bunch of objects whose rendering takes a noticeable amount of time. If you repeat the following: 1. Press an arrow key 2. Immediately release the key 3. Wait until the selection has rendered in its new position you'll notice the selection rendered a bit to the right, then rendered again a bit more to the right etc. Now suppose you: 1. Press an arrow key 2. Keep the key pressed 3. Release after ~3 to 5 seconds what you'll probably see is no repeated rendering at small offsets like in the previous procedure, but instead of immediately seeing the selection rendered at its final position, you wait a lot of time before that actually happens - seemingly, the time it would take to render the selection at each of the intermediate positions had you performed the first procedure. I assume the selection is somehow rendered off-screen, or on-screen but not fast enough to register etc. This should not happen - only the single, final rendering should happen (and possibly another when we still don't know if the button will get released).
(In reply to Eyal Rozenberg from comment #0) > Suppose you make a selection of a bunch of objects whose rendering takes a > noticeable amount of time. It seems this is the hardest part for me, so would be cool if you attached an example file.
Created attachment 141578 [details] A complex drawing A drawing complex enough so that its rendering, when moved, requires a while (over a second on my PC). There's nothing particularly special about it - just lots of shapes, transparency, intersections, line transparency, gradient fill. The details are not really important - the point is just the complexity.
Thanks for the file. I see what you mean. (In reply to Eyal Rozenberg from comment #0) > This should not happen - only the single, final rendering should happen (and > possibly another when we still don't know if the button will get released). So in essence, you would favour a solution, where only the selection handles are seen moving and no processing power is wasted on rendering the drawing itself? I guess another (more complex to implement) way would be to replace the drawing with a low-quality proxy rendering on the fly. Let's consult design team.
(In reply to Buovjaga from comment #3) > So in essence, you would favour a solution, where only the selection handles > are seen moving and no processing power is wasted on rendering the drawing > itself? > > I guess another (more complex to implement) way would be to replace the > drawing with a low-quality proxy rendering on the fly. > > > Let's consult design team. If we're getting into it, I'd differentiate at least three cases: 1. Movement key combination held down (that's a hardware abstraction layer thing - not something LO should detect; I think) 2. Second move key (or another key combination?) pressed very closely after first movement key (or another combination?) 3. Nothing pressed very closely after first movement (or other key combination) The differentiation between the second and third case isn't clear, but it could perhaps be based on whether the effect of the keypress can be comfortably rendered before the next key/key combination registers. So, for case 1 I would indeed like something like the effect of the moving selection rectangle rather than the selection itself. A simplified rendering (e.g. less lines/no area/no transparency/etc. could work too, but like you said - implementing that is a big deal. Now, I do mean animation - along a continuous path, not at intervals (Not 100% sure about this though). For case 2 - Act similarly to case 1, but don't make it an animation; or rather, a "stop-motion" animation - only render at the positions the move keys would have placed the object. For case 3 - Just render the whole thing like LO does now.
My suggestion is to interrupt the drawing thread when an arrow key is being pressed and restart with the new position. That means you press right a couple of times and don't have to wait for every single paint event but only the last one. If there is no objection I'd adjust the summary. Though nut for devs, I guess.
(In reply to Heiko Tietze from comment #5) About your suggestion: That would still load the CPU a lot when repeat-moving. But it seems to be a quick and easy fix for now. About the summary: I think it's fine, since it describes the problem; it doesn't need to describe the solution.