Bug 169644 - Toolbar formatting icon indicators performs slowly
Summary: Toolbar formatting icon indicators performs slowly
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
24.8.4.2 release
Hardware: All Linux (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: perf
Depends on:
Blocks: Writer-Toolbars Performance
  Show dependency treegraph
 
Reported: 2025-11-23 22:53 UTC by questions2000
Modified: 2026-01-24 20:58 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description questions2000 2025-11-23 22:53:33 UTC
Description:
When formatting such as bold or italic is applied to text, the toolbar icons for these formatting buttons will show a background color visual indicator to let user know when currently focused line is using that formatting.

I noticed that if navigate cursor from non bold cell/line into cell/line that contains formatting,
that the toolbar icons background indicator seems to take a little while before it shows.
If possible should apply instantly.

Steps to Reproduce:
1. Open Writer or Calc
2. Create two lines of text 
3. Make the second lines text bold
4. Move caret/cursor to the first line
5. While keeping eyes on the "bold" icon in your toolbar
6. Move caret/cursor down into the line that contains bold text

Actual Results:
You might notice that the background color visually indicator that shows up behind the "B" icon takes a little while to become visible.

Expected Results:
If possible seems like the visual indicator should show instantly when caret/cursor enters that line with the bold formatting.


Reproducible: Always


User Profile Reset: No

Additional Info:
-This happens in Calc and Writer (have not tested others applications)
-This happens with formatting toolbar buttons such as bold and italic (have not tested any others)
Comment 1 rram 2025-11-28 04:51:51 UTC
Hello questions2000@proton.me,

Thank you for reporting this behavior. I can confirm that it is present in both the master and alpha versions. The delay is quite short on my system, nearly half a second, but it is perceivable and may be more noticeable on slower systems.

Version: 25.8.3.2 (X86_64)
Build ID: 8ca8d55c161d602844f5428fa4b58097424e324e
CPU threads: 8; OS: Windows 10 X86_64 (build 19045); UI render: Skia/Vulkan; VCL: win
Locale: en-US (en_US); UI: en-US
Calc: CL threaded

Version: 26.2.0.0.alpha1+ (X86_64) / LibreOffice Community
Build ID: 620(Build:0)
CPU threads: 8; OS: Windows 10 X86_64 (build 19045); UI render: Skia/Vulkan; VCL: win
Locale: en-US (en_US); UI: en-US
Calc: CL threaded
Comment 2 Buovjaga 2025-11-29 19:35:32 UTC
I believe this could be intentional performance-preserving behaviour. It's the same as you see in many search filter fields (on websites etc.), where it will not react to your typing immediately. This is sometimes called "debouncing". When some area gets heavy interaction, it does not make sense to spend CPU time in real-time monitoring. But maybe the behaviour can be tweaked without harming performance.
Comment 3 Buovjaga 2025-12-01 12:35:44 UTC
Adding perf keyword per discussion in dev chat (we don't need such aggressive debouncing tactics anymore).