Description: Editing a formula, the results are displayed at the same time. Steps to Reproduce: 1. Open new Calc. 2. Insert formula "=1" in Cell [ A1 ]. 3. Edit cell formula by [F2] key. Actual Results: 4. The formula and the results are displayed at the same time. Expected Results: 4. No results will be displayed in the cell. Reproducible: Always User Profile Reset: No Additional Info: It may be useful for short formulas and short results, but they overlap and become difficult to see in general formulas. Not reproduced with (2025-04-26) Version: 25.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: e4fb32ffef1630ceaf5a0a77307e02ae93c9f8f4 CPU threads: 4; OS: Windows 10 X86_64 (build 19045); UI render: Skia/Vulkan; VCL: win Locale: en-US (ja_JP); UI: en-US Calc: CL threaded Reproducible with [2025-05-09] Version: 25.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 9bc5b89c149497a83117edfadc3fb0b96d2f9899 CPU threads: 4; OS: Windows 10 X86_64 (build 19045); UI render: Skia/Vulkan; VCL: win Locale: en-US (ja_JP); UI: en-US Calc: CL threaded
Please attach a screenshot on how do you see it.
Created attachment 200760 [details] sample png I don't understand the meaning of the question. However, I'll attach a sample that I think is unnecessary. Attach the image when editing cell [A2].
Created attachment 200761 [details] sample file
Created attachment 200764 [details] Screenshot Please test modifying, even disabling Skia options. Menu>Tools>Options>LibreOffice>View
Created attachment 200766 [details] Screenshot with 25.8 Ok the previous screenshot was with 25.2.3 In other test I can see it with Version: 25.8.0.0.alpha1+ (X86_64) / LibreOffice Community Build ID: 19f3b72f34c487dc97d582712d21734a7e055fd5 CPU threads: 16; OS: Windows 11 X86_64 (build 26100); UI render: Skia/Raster; VCL: win Locale: es-ES (es_ES); UI: en-GB Calc: CL threaded
BTW changing Skia options or disabling doesn't solve the issue.
(In reply to m_a_riosv from comment #6) > BTW changing Skia options or disabling doesn't solve the issue. Yes.
For the most obvious explanation, I have explained it in formulas and results, but there is a similar problem with text and numbers. This problem must be more important. And it may have been created with the same commit as the bug below. https://bugs.documentfoundation.org/show_bug.cgi?id=166520 https://bugs.documentfoundation.org/show_bug.cgi?id=166559
(In reply to nobu from comment #8) > For the most obvious explanation, I have explained it in formulas and > results, but there is a similar problem with text and numbers. > This problem must be more important. > And it may have been created with the same commit as the bug below. > > https://bugs.documentfoundation.org/show_bug.cgi?id=166520 > https://bugs.documentfoundation.org/show_bug.cgi?id=166559 right. bibisected with linux-64-25.8 author Armin Le Grand (Collabora) commit f678ec9a65c4d7ae2d4dda4599a06fc4b66a27d8 CEOO: CellEditOnOverlay Instead of using EditView's Paint directly to Window I changed this now to using the Overlay that is available in all applications. This allows to have less repaints of the Calc View since the Overlay has a copy of the area it is working overlayed. It also allows to get away from one of the last areas where XOR selection was used since EditView/EditEngine have no better way to do this. Selection is now visualized using the OS'es choosen SelectionColor, as in all other apps. I could also get rid of the flush() of the OverlayManager that was needed before and caused some problems (see tdf#165621 and associated tasks). A failing UnitTest showed that OverlayManagerBuffered needs to be aware when no CompleteRedraw was done yet and thus no background data exists and refresh makes no sense. This may happen when there is no redraw/UI e.g. UnitTests, but still an OverlayManager is used and together with a Reschedule (many possible reasons) that refresh might be triggered. Made access to EditView in OverlayObject no longer dependent on ActiveView, that is not always the one with the EditView. Now using a combination of ScTabView and ScSplitPos for accesses. Asserting now if no EditView -> is mandatory. Continuing going through CppunitTest_sc_tiledrendering UTs, one more identified. Have to re-activate EditViewInvalidate rect forwarding since the Invalidate is needed for sc tiled rendering tests, but not for sd tiled rendering tests. Added that to the impl of EditViewCallbacks using LibreOfficeKit::isActive(). Change-Id: I41f5448bfbabfaae4858c7617478771053c2cd77 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/184830
Taking a look...
Well.. when doing CEOO new possibilities came up: Instead of just painting the cell and the TextEdit over it all the time we can/could now do stuff like appear/fadeOut or transparency. So I took some transparency (where 50% might be too much, more like 10% maybe...?). Usually only visible when cell gets expanded by e.g. CTRL+RETURN, with transparency you could still see the cell below then slightly - more visible info is always better. Before with all getting painted (again and again at each key press and even more often) the BG (the call) was always painted but overpainted and was never visible. What I had *not* on the radar (and thus thanks for this task) is that the *result* is shown in the cell while editing. This was hidden before the change due to always being overpainted - so in principle useless. With short formulas it's even not that bad: result is right, formula is left. But does not work when formula overlays result, of course. Thus, the alternatives are: (a) Do as before: No transparency, all overpainted, result not visible. Note that still the result gets calculated and cell painted (as I learned). Not sure if that can be avoided, this is unnecessary in that scenario (b) Since the result gets calculated, maybe find a clever way to show both, maybe result explicitly one line below e.g. in another color or a frame that makes clear that this is the result - only when editing formula. That would require more development work. My best guess is to do (a) as a fix for now to get this out of the way. Both have drawbacks with still doing too many redraws of the cell, but for (a) would be hidden - as before. Maybe later as a feature do (b)...? Thus will do (a) for now, but comments welcome... NOTE: The https://bugs.documentfoundation.org/show_bug.cgi?id=166559 fat outer brackets seem to be a place where additionally to the overlay the formula gets still painted somewhere 'directly' -> you can see that when in that mode and moving the cursor -> CEOO gets painted with correct brackets...
Added https://gerrit.libreoffice.org/c/core/+/185971, should do it. This is solution (a). I checked for still existing repaints, found none.
(In reply to Armin Le Grand (allotropia) from comment #11) > .... > > (b) Since the result gets calculated, maybe find a clever way to show both, > maybe result explicitly one line below e.g. in another color or a frame that > makes clear that this is the result - only when editing formula. That would > require more development work. Really nice. > > My best guess is to do (a) as a fix for now to get this out of the way. Both > have drawbacks with still doing too many redraws of the cell, but for (a) > would be hidden - as before. Maybe later as a feature do (b)...? > > Thus will do (a) for now, but comments welcome... > > ...
Armin Le Grand (Collabora) committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/a07a0f429c3a1a6709ec42907d00b29b84c75447 tdf#166525 CEOO: Back to overpaint everything It will be available in 25.8.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Verified Version: 25.8.0.0.alpha1+ (X86_64) / LibreOffice Community Build ID: b852ed9fc8b43cdc335c14aeb71c581daa7d98a7 CPU threads: 16; OS: Windows 11 X86_64 (build 26100); UI render: Skia/Raster; VCL: win Locale: en-US (es_ES); UI: en-US Calc: CL threaded