In bug 158320, the live preview of the font in calc has been fixed. In bugs 144151 and 161898 it is shown that this function can generate a problem with a systematic repetition of an unnecessary process when we simply move the focus from one cell to another, which causes unnecessary delays and takes time. Unnecessary processing is visible even with a small file under windows (i5). Some users don't see the problem because the delay is short. Maybe we can conclude that some users like to be blinked by the interface, and other users don't like. Since there are two points of view for this "live preview" function, it means that we need a parameter to satisfy both points of view. This parameter would have two states: ENABLED: The live preview works as currently DISABLED: The live preview is disabled (and maybe bug 144151 will not be generated) Thank you in advance for your comments or work on the subject.
Hello [user's name], Thank you for reporting the bug. Unfortunately without clear steps to reproduce it, we cannot track down the origin of the problem. Please provide a clearer set of step-by-step instructions on how to reproduce the problem. I have set the bug's status to 'NEEDINFO'. Please change it back to 'UNCONFIRMED' once the steps are provided
STR should be clear from the duplicate reports: expand the font name drop down and hover over names (or cursor up/down). The suggested option might be a solution but I could imagine to just not stop the font update mechanism if it takes longer than 100ms or so. Caolan, what do you think? Ultimately this ticket is one possible solution to bug 144151 and we should make it a duplicate.
(In reply to Nicole A. from comment #1) > Hello [user's name], > > Thank you for reporting the bug. > Unfortunately without clear steps to reproduce it, we cannot track down the > origin of the problem. > Please provide a clearer set of step-by-step instructions on how to > reproduce the problem. > I have set the bug's status to 'NEEDINFO'. Please change it back to > 'UNCONFIRMED' once the steps are provided Hello Nicole, thank you for your interest. I have reported the bug 161898 The first comment (Manu 2024-07-04 21:58:30 UTC) tries to explain how to create the anomaly and what is the perimeter/context necessary. I have again tested today, and I confirm the anomaly when using the procedure described in the bug_font_lineheight.ods Version: 24.8.2.1 (X86_64) / LibreOffice Community Build ID: 0f794b6e29741098670a3b95d60478a65d05ef13 CPU threads: 8; OS: Windows 10 X86_64 (10.0 build 19045); UI render: Skia/Raster; VCL: win Locale: fr-FR (fr_FR); UI: fr-FR Calc: threaded I would like to complete the comment made by Heiko because there are 2 side effects with live preview: - when we expand the font name drop down list, and hover over names (or cursor up/down), the live preview updates the selected cells (and consequently all the screen), and if the sheet is "complicated", then we can feel a delay when we change from one line to another line of font, and if I want to select the 20th font in the list (or farther), all these delays accumulate (using the keyboard). - after the exit of the font list (with click, enter or escape), the second side effect is visible (if the conditions are respected): the status bar blinks each time we move to another cell. This blinking is quick, but slow when the sheet is too complicated, I have seen one second delay for a 3mb file and the only formula is an equal to a cell with multiline text and each cell has a different font. Fortunately, I know how to disactivate this anomaly. But the normal user who discovers this anomaly for the first time, you imagine the hell: a big file with important and complicated data, each move is incredibly slow without explanation, mandatory to close and reopen the file, very bad experience. About the 100ms limit, it could be a good idea. Maybe we could propose different exits: 1- stop the font update mechanism (no user intervention, nor message box) 2- message box: dear user, the live preview is maybe too long for you, we can disable it for you. Select your answer: a (disable live preview for the current session), b (permanently, if you don't need it), c (you are ok to wait, we disable this warning for the current session), d (we stop the update after 100ms and disable this warning for the current session). I wonder if we could have a third exit case: the message box could explain how to disactivate the bug manually (focus on one cell only, click inside the text of the font list, type enter), or if the program can try to emulate these actions for the user. I hope it helps. Have a nice day all!
Updating this back to "New" due to reporter providing more information in the comments.
(In reply to Manu from comment #3) > 2- message box: dear user, the live preview is maybe too long for you... Your really accept a message box interrupting the workflow and requiring interaction rather than a slight delay or flicker? I doubt so ;-). The only feasible solution is an option, which requires user to understand and configure, perhaps depending on the document, or some internal solution that silently circumvents all trouble by running in the background or not running at all. And 100ms can be quite long.
(In reply to Heiko Tietze from comment #5) > (In reply to Manu from comment #3) > > 2- message box: dear user, the live preview is maybe too long for you... > Your really accept a message box interrupting the workflow and requiring > interaction rather than a slight delay or flicker? I doubt so ;-). I understand your viewpoint, but when I was trying to understand why the moving of the focus from one cell to another was so long (1s), why I had to close and reload the file, I would have appreciated a explanation with a message box. And in the differents answers, it is clear the interruption occurs only one time per session or definitively (the parameter for enable/disable live preview). > > The only feasible solution is an option, which requires user to understand > and configure, perhaps depending on the document, or some internal solution > that silently circumvents all trouble by running in the background or not > running at all. And 100ms can be quite long. it's ok for me.
It's not a sustainable approach to introduce new features, options, to work around known bugs. Would be better to solve bug 144151 in an optimal way.