Reproduction instructions: 1. Switch to the Notebookbar-Tabbed UI mode 2. Switch to the Home tab of the NB bar. 3. Open the sidebar on the Styles deck. 4. Create a new writer document. 5. Type in some text on one paragraph. 6. Type in some text on a second paragraph. 7. Set a different style for the second paragraph, e.g. Heading 1. Now, use the mouse to click somewhere in the text of the first paragraph, then the second, then back etc., while observing the UI, especially the cursor position, style gallery on the NB bar, and sidebar. Expected results: UI switches nearly-instantneously to reflect the position change to the new paragraph. Actual results: Even on a decently powerful, and moderately loaded, machine - long delays are observed, on the order of magnitude of a full second. Attachments to follow. This bug is based on the original report here: https://www.reddit.com/r/libreoffice/comments/1kcq3ke/why_paragraph_styles_in_writer_change_so_slow_in/
Created attachment 200636 [details] Trivial document for testing paragraph switch performance A trivial document, created as per the instructions above.
Created attachment 200637 [details] Screencast of UI behavior while switching between paragraphs - LO 25.8, NB Tabbed Screencast exemplifying the weak performance - with Notebookbar Tabbed UI.
Created attachment 200638 [details] Timings and notes based on screencast attachment 200637 [details] A timing table based on frame-by-frame inspection of the screencast. I note several distinct problems: * Overall time before the UI "settles" is slow * The overall process of selection switch in the NB style gallery is slow, as it involves some extra v-scrolling after the selection has changed. * Significant variations in response delays for different UI elements: Cursor, NB tab buttons, NB style gallery, SB style gallery.
Created attachment 200639 [details] Screencast of UI behavior while switching between paragraphs - LO 25.8, menus+toolbars Same screencast, but with menus+toolbar rather than NB tabbed. Haven't timed this one exactly, but delays are also significant - some toolbar buttons take nearly a second, and the SB style gallery selection switch is also above a full second, probably similar to the NB-Tabbed case.
Reproduce in both linux and windows The style inspector changes instantly I don't see any particular cpu spike Version: 25.2.3.2 (X86_64) / LibreOffice Community Build ID: bbb074479178df812d175f709636b368952c2ce3 CPU threads: 8; OS: Linux 6.11; UI render: default; VCL: gtk3 Locale: en-US (en_US.UTF-8); UI: en-US Flatpak Calc: threaded Version: 25.2.3.2 (X86_64) / LibreOffice Community Build ID: bbb074479178df812d175f709636b368952c2ce3 CPU threads: 2; OS: Windows 11 X86_64 (10.0 build 22621); UI render: Skia/Raster; VCL: win Locale: en-US (en_US); UI: en-US Calc: threaded
(In reply to Mateusz Wlazłowski from comment #5) > The style inspector changes instantly > > I don't see any particular cpu spike That's actually encouraging news, because it probably means there's some sort of artificial delay somewhere, not an excessive amount of computational work :-)
Not observing a *substantial* or *unacceptable* delay. Even in the attached screen casts, or extracted table of delays. I don't believe there is an implementation issue, always correct results--just observed slowness of updating the buffered views of the UI. And that can certainly be made worse by incorrectly configured GPU or graphics drivers as noted in the reddit thread. IMHO UI behavior is consistent between the 4 LO rendering modes (though at decreasing rendering speeds): skia/Vulkan, skia/Raster, CPU controlled Hardware Acceleration, or CPU only. On the Notebook Bar Tabbed UI Paragraph selected and changes between "supported" styles are immediate in the NB Tabbed UI Styles preview only for styles with defined style previews as provided to the Notebookbar UI, provided via svx StylesPreviewWindow(). On the NB the Style preview updates equally fast, but those styles with no defined preview seem to show the last matched "supported" style, or the Default para style preview--the Sidebar Style picker (text and preview) update to correct style immediately. Likewise UI updates to tb list box of paragraph/font or SB styles (with or without its 'Show previews' checkbox) are equally performant to those on the Notebook Bar assemblages. Perceptual delay, stuttering, or asymmetrical timings within a UI can make for unpleasant UX--but I don't think we have any of those here. =-testing-= Win11 24H2 (OS Build 26100.33775) on Intel(R) Core(TM) i7-14700, 2100 Mhz, 20 Core(s), 28 Logical Processor(s) Version: 25.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: e4fb32ffef1630ceaf5a0a77307e02ae93c9f8f4 CPU threads: 28; OS: Windows 11 X86_64 (build 26100); UI render: Skia/Vulkan; VCL: win Locale: en-US (en_US); UI: en-US Calc: CL threaded And UI render: UI render: default; VCL: win (HA and CPU only) UI render: Skia/Raster; VCL: win UI render: Skia/Vulkan; VCL: win vulkaninfo Device Properties and Extensions: ================================= GPU0: VkPhysicalDeviceProperties: --------------------------- apiVersion = 1.4.303 (4210991) driverVersion = 572.60.0.0 (2400124928) vendorID = 0x10de deviceID = 0x2803 deviceType = PHYSICAL_DEVICE_TYPE_DISCRETE_GPU deviceName = NVIDIA GeForce RTX 4060 Ti pipelineCacheUUID = a552de6d-1faf-8ad5-3314-6af41289f0a5
(In reply to V Stuart Foote from comment #7) > asymmetrical timings within a UI Well, there kind of is an asymmetrical timing if you compare the speed of change in "Style" and "Style inspector" menu Make a doc with the first line a "Default paragraph style" and the second line a "Heading". When you move from one line to another with the cursor, the menu updates with the speed of the cursor movement. Whereas in the "Style" menu, there is an additional second after the cursor has moved
Inclined to => NAB this, but lets let the perf tag and the devs decide if there is an issue?
(In reply to Mateusz Wlazłowski from comment #8) > (In reply to V Stuart Foote from comment #7) > > asymmetrical timings within a UI > > Well, there kind of is an asymmetrical timing if you compare the speed of > change in "Style" and "Style inspector" menu > > Make a doc with the first line a "Default paragraph style" and the second > line a "Heading". When you move from one line to another with the cursor, > the menu updates with the speed of the cursor movement. Whereas in the > "Style" menu, there is an additional second after the cursor has moved The Standard toolbar 'Set Paragraph Style' listbox vs. the 'Style inspector' SB deck? Completely different instrumentation of the UI, I wouldn't expect them in sync--but IMHO they are not so far out that it is a UX issue.
Created attachment 200644 [details] style menus speed change comparison > The Standard toolbar 'Set Paragraph Style' listbox vs. the >'Style inspector' SB deck? Completely different > instrumentation of the UI, I wouldn't expect them in > sync--but IMHO they are not so far out that it is a UX issue. I am talking about those two menus Styles (Alt + 2) and Styles inspector (Alt + 6) I agree that they both serve a different purposes, nonetheless, I would personally expect both menus to update at the speed of the cursor
By cursor I mean the position where text will be added if we press a key on the keyboard
There is actually a flaw with the current implementation of update of the style inspector. I made a doc with alternating "Default paragraph style" and "Heading". Leaving the down arrow key pressed, the menu updates hold it back for some time. Too much change wouldn't look good So my suggestion is to leave it that way, decrease the waiting time between the moment we release the key and the time the menu is updated, and bring the same behavior to style inspector
(In reply to Mateusz Wlazłowski from comment #11) > > I am talking about those two menus Styles (Alt + 2) and Styles inspector > (Alt + 6) > > I agree that they both serve a different purposes, nonetheless, I would > personally expect both menus to update at the speed of the cursor OK thanks. But let's use the correct project terminology, those are top level titled Sidebar "Decks", each with distinct "Content Panel" (that may have a title for the panel) holding control widgets. https://wiki.documentfoundation.org/File:LO-HIG_SideeBar-Terminology.png The 'Styles' deck (<Alt>+2 or <F11>, for.uno:SidebarDeck.StyleListDeck) as compared to the 'Style Inspector' deck (<Alt>+6, for uno:SidebarDeck.InspectorDeck). The <alt>+[1-9] accelerators are assigned to each deck. And each deck will "handle" its cursor focus as appropriate to the control enabled. Giving us two text modes to consider UX of cursor handling and UI update: 1.) Toggling between <Alt>+2 and <Alt>+6, with edit cursor focus already into a document a paragraph, the UI changes content panel equally fast. 2.) Making a mouse pointer change of the edit cursor focus (between paragraphs of different styles) *is a tic slower*. Movement cursor <U/D> fire a focus event, so they are consistent with a pointer change and mouse click. With reasonable system HW configured appropriately [1], IMHO neither is objectionably slow to the point of affecting UX, even on older less capable hw. (In reply to Mateusz Wlazłowski from comment #13) > There is actually a flaw with the current implementation of update of the > style inspector. Sorry, don't see an implementation issue with keyboard cursor movements, or mouse pointer clicks, for the Style Inspector deck moving between Paragraph objects. It toggles as soon as focus event fires and the content panel can be loaded. =-ref-= [1] So the skia rendering paths set to Raster rendering, with device/os approriate drivers. Skia lib Vulkan rendering is os and Hardware dependent, unfortunately our defaults are to enable Vulkan rendering which should fall back to skia raster framing for unsupported hw (improved at 25.8). But some hw driver combos sneak by and LO ends up choking on newer LO builds against old hw, or completely unsupportable hw like a VMSVGA device.
(In reply to V Stuart Foote from comment #7) > Not observing a *substantial* or *unacceptable* delay. Even in the attached > screen casts, or extracted table of delays. A delay of one second is very long and quite unacceptable. > And that can certainly be made worse by incorrectly configured GPU or > graphics drivers as noted in the reddit thread. That sounds like a red herring :-( Plus, my GPU is configured fine (and I assume so is Mateusz Wlazłowski's). > Perceptual delay, stuttering, or asymmetrical timings within a UI can make > for unpleasant UX--but I don't think we have any of those here. Isn't a "perceptual delay" simply a delay that is perceived? Plus, the process-of-change in itself in the NB has these weird v-scroll "reverberations", regardless of the point of time of its start, which are a bug. But perhaps I should file this separately. (In reply to V Stuart Foote from comment #9) > Inclined to => NAB this, but lets let the perf tag and the devs decide if > there is an issue? The existence of the issue has been established by users. You can mark this as needUXEval if you want a second opinion of course.
(In reply to V Stuart Foote from comment #14) > But let's use the correct project terminology, those are top level titled > Sidebar "Decks", each with distinct "Content Panel" (that may have a title > for the panel) holding control widgets. Alright > > The <alt>+[1-9] accelerators are assigned to each deck. And each deck will > "handle" its cursor focus as appropriate to the control enabled. > > Giving us two text modes to consider UX of cursor handling and UI update: > > 1.) Toggling between <Alt>+2 and <Alt>+6, with edit cursor focus already > into a document a paragraph, the UI changes content panel equally fast. I agree > 2.) Making a mouse pointer change of the edit cursor focus (between > paragraphs of different styles) *is a tic slower*. Movement cursor <U/D> > fire a focus event, so they are consistent with a pointer change and mouse > click. Alright > Sorry, don't see an implementation issue with keyboard cursor movements, or > mouse pointer clicks, for the Style Inspector deck moving between Paragraph > objects. It toggles as soon as focus event fires and the content panel can > be loaded. Sorry for not being clear enough So, after your message saying it's fast, I checked my power mode and it was on "power saver", changed it to "balanced". The thing I was trying to say was that the updates of the "Styles inspector" deck slows down the speed of the cursor. I made alternating paragraph styles ("default paragraph style" and "Heading"). I pressed the down arrow key for like 2-3 seconds with the "Styles inspector" deck open and release ("power saver" mode). The result is the cursor moving for 1 second more after I released the arrow key ==> the updates of the Style Inspector deck slows down the movement of the cursor We can say it's not an issue per say on "modern hardware" I'm on ubuntu btw However, I would label an issue, inconvenience the flickering of the Style Inspector deck when alternating rapidly. This is why I was suggesting : 1- To bring the update behavior from the style deck (the deck is only updated when the cursor hasn't moved for some time) 2- To reduce the waiting period after the last movement of the cursor because the update of the Style deck feels slow
There is a lag regardless of Standard Toolbar or Tabbed UI in Master, in my perception. Version: 25.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 9f308ba42f44e7d8e2f73a92923b0374e39083aa CPU threads: 8; OS: macOS 14.7.4; UI render: Skia/Metal; VCL: osx Locale: nl-NL (nl_NL.UTF-8); UI: en-US Calc: threaded same in Version: 7.2.0.4 / LibreOffice Community Build ID: 9a9c6381e3f7a62afc1329bd359cc48accb6435b CPU threads: 8; OS: Mac OS X 10.16; UI render: default; VCL: osx Locale: nl-NL (nl_NL.UTF-8); UI: en-US Calc: threaded I do notice a slight difference between Standard Toolbar and Tabbed UI with Version: 7.0.0.3 Build ID: 8061b3e9204bef6b321a21033174034a5e2ea88e CPU threads: 8; OS: Mac OS X 10.16; UI render: default; VCL: osx Locale: nl-NL (nl_NL.UTF-8); UI: en-US Calc: threaded The responds of the sidebar styles deck appears to be snappier with Standard toolbar. 0,5 second instead of 1
Comment from the original reporter on Reddit about the filing of this bug: "Thank you! I hope it will be fixed eventually, because for now that's the only reason why I can't be comfortable using LO. Actually, I noticed this problem immediately, but I decided to post only after it started interfering with my work in the app. Specifically, if you switch between different paragraphs too quickly, the UI skips updates completely. You can test this by creating two paragraphs with different alignments, making one bold or applying other formatting, and then quickly switching between them using the up and down arrow keys. As a result, you can't quickly preview the styles of each paragraph. I had to wait for over a second for the UI to update so I could view the styles. Additionally, attempting to change styles, such as making text bold, won't take effect if the UI hasn't updated yet (you can verify this yourself). So for me, it's not just about sidebar being too slow to update, but some of the other things too. The sidebar is just the slowest one. I don't believe my reaction time is unusually fast; I'm just an average user. There are no such issues with Word; its UI changes so quickly that even after repeatedly using the rapid up and down keys trick between paragraphs, I don't notice any delays, let alone problems with changing styles. Both apps use C++, so achieving the same performance in LibreOffice should be possible."