Created attachment 199439 [details] Screenshot of glitch Run with SAL_RTL_ENABLED=1 SAL_USE_VCLPLUGIN=kf5 (or kf6) 1. Open attachment 197394 [details] 2. Expand the input field by clicking the black triangle 3. Select all in the input field The selection continues to be painted outside of the field. Bibisected with linux-64-25.2 to 9ea9cd14ffc69e6597996da09943e1ce11a50d6f tdf#163457 CairoSDPR: Need to apply 'damage' to gtk
Hi Buovjaga, happens as described, thanks for digging that out - taking a look...
Does also happen with qt5, but not with gtk3. Can be avoided using DISABLE_SYSTEM_DEPENDENT_PRIMITIVE_RENDERER=1, so has to do with CairoSDPR. NOTE: using 'gen' moves the text in the expanded EditEngine to a single line?!?
NOTE: Step (2) is not needed, also shows problems with unexpanded & moving up/down plus select using keyboard
Has nothing to do with OverlayManager (my 1st thought) but uses ScTextWnd::Paint directly and WeldEditView::DoPaint. Interestingly in OutDev used IsRTLEnabled() is false, it's an OUTDEV_WINDOW and has offsets mnOutOffX(278) and mnOutOffY(84). WeldEditView::DoPaint directly creates a sdr::overlay::OverlaySelection and paints the primitives from it using aCursorOverlay.getOverlayObjectPrimitive2DSequence() - not what EditEngine & normal Overlay does... simply forcing nOffsetPixelX/nOffsetPixelY to zero in CairoPixelProcessor2D::CairoPixelProcessor2D does not help, it gets painted further top-left, so these are correct. Looks like *somehow* that offset from the right from the panel right of it seems seems to be missing (?)
@Buovjaga: Has nothing to do with resulto of: Bibisected with linux-64-25.2 to 9ea9cd14ffc69e6597996da09943e1ce11a50d6f tdf#163457 CairoSDPR: Need to apply 'damage' to gtk To check I disabled the call to mpGraphics->ApplyFullDamage() in OutputDevice::GetSystemGfxData() (in vcl/source/outdev/outdev.cxx lines 232/233). Result is also wrong coordinates in the selection, but *not* overlapping with virtual window bounds. @Caolan: in the given combination the coordinates for the overlay for that calc TextEdit are *wrong* -> too far right, looks like offset from the control block right of it are added to the left as if RTL is not taken into account (?). Please have a look...
@Caolan: Or in other words - in kf5 compared to gtk3 in RTL mode the positions seem to be wrong calculated when there are multiple virtual windows arranged horizontally. It works with gtk3, so there it seems to be done. Q is where is stuff like that for kf5 - I have no idea here
Offset is also wrong in other cases, e.g. directly in EditView when OUTDEV_WINDOW is used, e.g. when using that popup-CellInfo objects (that are not on the Overlay but directly painted) -> definitely an error in kf5 compared to gtk3
Can be watched extremely using Calc cell info popups when sidebar is activated -> huge error in offsets, but was the same error in offsets before claimed change in description
Have to re-check: It still does not happen when using DISABLE_SYSTEM_DEPENDENT_PRIMITIVE_RENDERER, so has to be triggered by something that did happen before. Best guess is that kf5 *does* update the needed offsets/geometry when using OutputDevice for painting, kind of on-demand update that is limited to the paint path using OutputDevice...?
Debugged into it, looking @ the diff that *must* exist when WeldEditView::DoPaint does paint the selection (line 250 in svx/source/dialog/weldeditview.cxx). What does VCLPrimitiveRenderer/OutputDevice do different compared to CairoSDPR? And - surprise - in SalGraphics::DrawPolyPolygon it *does* handle the PolyPolygon as *mirrored* despite false == IsRTLEnabled() (!!!). The condition there is if( (m_nLayout & SalLayoutFlags::BiDiRtl) || i_rOutDev.IsRTLEnabled() ) while IsRTLEnabled() just bool IsRTLEnabled() const { return mbEnableRTL; } thus that Window *is* using mirroring but RTL is *false*. Thus the fix for tdf#165061 in createPixelProcessor2DFromOutputDevice does not work. It seems that our 'mirroring' and 'RTL' UI stuff is in some unorder, at least... Will now have to check how I can ask at OutputDevice for 'real' mirroring, including m_nLayout & SalLayoutFlags::BiDiRtl...
Fit at https://gerrit.libreoffice.org/c/core/+/182481, indeed had to check more to cover all cases of mirroring. I found HasMirroredGraphics which checks mpGraphics->GetLayout() & SalLayoutFlags::BiDiRtl as needed.
Took the time to see what happens with gtk3 -> it is *not* mirrored in createPixelProcessor2DFromOutputDevice (!)
Armin Le Grand (Collabora) committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/dedaef9565dba5856ef68a49c634b614cb3ef24d tdf#165437: regression: CairoSDPR: Exclude SDPR when mirrored 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.
Armin Le Grand (Collabora) committed a patch related to this issue. It has been pushed to "libreoffice-25-2": https://git.libreoffice.org/core/commit/af4d7eb9fdb1921a2bac78b51c17e1975ae908c5 tdf#165437: regression: CairoSDPR: Exclude SDPR when mirrored It will be available in 25.2.2. 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.
Thanks, now the main glitch is gone. I do notice that after selecting all, a ghost copied slice of the Sidebar appears below the text. With fainter colours. Do you see it? Arch Linux 64-bit Version: 25.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: ffd552926b381591972d2db55c16e57569cde98a CPU threads: 8; OS: Linux 6.13; UI render: default; VCL: kf6 (cairo+wayland) Locale: fi-FI (fi_FI.UTF-8); UI: en-US Calc: CL threaded Built on 5 March 2025
@Buovjaga: Yes I also saw that briefly, it also happens with gtk3 and without SDPR, maybe even without RTL - have not checked deeper. It *seems* to copy the content from the 'virtual' win further left somehow...