Description: I often misaim due to this Wish it changed instantly https://drive.google.com/file/d/1_q6S8sDYgfnJ06P9pnPf8qwxQFjoDB1_/view?usp=sharing Steps to Reproduce: 1.. 2. 3. Actual Results: . Expected Results: . Reproducible: Always User Profile Reset: No Additional Info: .
You mean to block the next click/hold event until the value field is updated? Don't think this is a good idea. It's rather typical for all applications and slow computers.
(In reply to Heiko Tietze from comment #1) > You mean to block the next click/hold event until the value field is > updated? Don't think this is a good idea. It's rather typical for all > applications and slow computers. My PC has 32GB RAM, i7, Intel Iris XE Isn't too slow, and can handle that That's the way the app is coded and not hardware limitations. It does not refresh instantly
Tested on Windows 11, LibreOffice 25.8.2.2 on a desktop system (Intel Core i9-14900K, 96GB RAM). Repeated clicking on the zoom “+” and “–” buttons. It shows a small delay before the zoom percentage refreshes, especially when clicking quickly. From what I was able to understand, the UI needs to re-render the page after each step, so the slight lag is almost expected behavior. Zoom with Ctrl + Mousewheel updates smoothly.
(In reply to GJord from comment #3) > Zoom with Ctrl + Mousewheel updates smoothly. Seems to be faster than "+" ad "-" buttons, but not very smooth still. Perhaps it too needs improvemnet. And please do not tell me it's due to slowness of my PC. My PC is strong enough for that, I don't use a potato PC
Removing needsDevEval keyword as it is used to propose new easy hacks and I believe this was not the purpose here: https://wiki.documentfoundation.org/QA/Bugzilla/Fields/Keywords#needsDevEval Removing perf keyword as well because there is no performance issue here. I guess the delay is intentional like many other so called "debouncing" delays in elements with heavy interaction, but in this case it indeed seems problematic as it harms the aiming to a specific percentage.
(In reply to Buovjaga from comment #5) > in this case it indeed seems > problematic as it harms the aiming to a specific percentage. For sure. It harms aiming
(In reply to Buovjaga from comment #5) > Removing perf keyword as well because there is no performance issue here. After discussing in the dev chat, I will add it back to help finding these types of reports :)
Tested zoom on both stable (25.8.3.2) and beta (26.2.0.0.alpha1+) on my system: DESKTOP-2BUVN79, Pentium N4200 1.1GHz, 8GB RAM, Windows 11 64-bit. Clicked the “+” / “–” zoom buttons repeatedly and used Ctrl + mousewheel. Everything updated instantly, no lag at all. Zoom percentage follows input perfectly. On my setup, this works smoothly. Could not reproduce the delay reported by the original user. Seems like an environment-specific issue on their side.
(In reply to Volodymyr from comment #8) > Tested zoom on both stable (25.8.3.2) and beta (26.2.0.0.alpha1+) on my > system: DESKTOP-2BUVN79, Pentium N4200 1.1GHz, 8GB RAM, Windows 11 64-bit. > > Clicked the “+” / “–” zoom buttons repeatedly and used Ctrl + mousewheel. > Everything updated instantly, no lag at all. Zoom percentage follows input > perfectly. > > On my setup, this works smoothly. Could not reproduce the delay reported by > the original user. Seems like an environment-specific issue on their side. The PC you tested in is quite dated and weak compared to newer setups, right? Yet it seems to be slower on stronger PCs. Strange
(In reply to Danat from comment #9) > (In reply to Volodymyr from comment #8) > > Tested zoom on both stable (25.8.3.2) and beta (26.2.0.0.alpha1+) on my > > system: DESKTOP-2BUVN79, Pentium N4200 1.1GHz, 8GB RAM, Windows 11 64-bit. > > > > Clicked the “+” / “–” zoom buttons repeatedly and used Ctrl + mousewheel. > > Everything updated instantly, no lag at all. Zoom percentage follows input > > perfectly. > > > > On my setup, this works smoothly. Could not reproduce the delay reported by > > the original user. Seems like an environment-specific issue on their side. > > The PC you tested in is quite dated and weak compared to newer setups, > right? Yet it seems to be slower on stronger PCs. Strange thats right.
It's better now, it does not lag the way it did. I'll give it a "fixed" status, but you may change it if you wish
(In reply to Danat from comment #11) > It's better now, it does not lag the way it did. I'll give it a "fixed" > status, but you may change it if you wish No, it's not better.
(In reply to Buovjaga from comment #12) > (In reply to Danat from comment #11) > > It's better now, it does not lag the way it did. I'll give it a "fixed" > > status, but you may change it if you wish > > No, it's not better. It seemed faster to me, but it's still not perfect. Fast clicking won't refresh it quickly https://drive.google.com/file/d/1TO0nGfnkkwGELA8HGjYIcWq4M_fx_Ax9/view?usp=sharing
(In reply to Buovjaga from comment #12) > (In reply to Danat from comment #11) > > It's better now, it does not lag the way it did. I'll give it a "fixed" > > status, but you may change it if you wish > > No, it's not better. This is Edge browser, and it does it perfectly https://drive.google.com/file/d/1gsnmTDD_e4Jm7VmAG3K7HwyC0SvNQXMC/view?usp=sharing
(In reply to Heiko Tietze from comment #1) > You mean to block the next click/hold event until the value field is > updated? Don't think this is a good idea. It's rather typical for all > applications and slow computers. The goal is to teach the app to refresh quicker than the user clicks. Web browsers have it on potato PCs, it can be done. The last video shows that