After bf3cd8e50f886084500e3a8ff72ff4ffab05ddd7 CairoSDPR: Make using SDPR dependent of ExperimentalMode the initial template selection dialog bleeds its grid content over the button section when using qt-based UIs. Arch Linux 64-bit Version: 25.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 4787fd4fc86230893a6da309f45964116b3a67df CPU threads: 8; OS: Linux 6.10; UI render: default; VCL: kf6 (cairo+wayland) Locale: fi-FI (fi_FI.UTF-8); UI: en-US Calc: CL threaded Built on 24 September 2024
I do not see it - pls add a screenshot
Created attachment 196656 [details] Screenshot of glitch
The problem is not seen when launched with DISABLE_SYSTEM_DEPENDENT_PRIMITIVE_RENDERER=1
@Buovjaga: Ah good - that's exactly the flag to use, happy that you already got that, forgot to add here :-)
Tried SAL_USE_VCLPLUGIN=kf5, kf6, qt5, gtk3, gtk3_kde5 and gen, but could not reproduce. I use Version: 25.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: dad5b34d011da41d536eb0db9635ac84e51bfcd5 CPU threads: 16; OS: Linux 6.8; UI render: default; VCL: gtk3 Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded on Ubuntu 24.04.1 LTS... How do you reproduce it?
(In reply to Armin Le Grand from comment #5) > Tried SAL_USE_VCLPLUGIN=kf5, kf6, qt5, gtk3, gtk3_kde5 and gen, but could > not reproduce. I use > > Version: 25.2.0.0.alpha0+ (X86_64) / LibreOffice Community > Build ID: dad5b34d011da41d536eb0db9635ac84e51bfcd5 > CPU threads: 16; OS: Linux 6.8; UI render: default; VCL: gtk3 > Locale: en-US (en_US.UTF-8); UI: en-US > Calc: threaded > > on Ubuntu 24.04.1 LTS... > How do you reproduce it? Are you running a Wayland session?
I do not know what you mean, so probably -> no. Maybe using SAL_USE_VCLPLUGIN is not up to date? What to use nowadays...?
Anyways, the screenshot (thanks) looks like VCL is not clipping to the Window sub-content (despite all other combinations), so might even be an error in the kf5/kf6 impl - which gets now triggered...?
(In reply to Armin Le Grand from comment #7) > I do not know what you mean, so probably -> no. > Maybe using SAL_USE_VCLPLUGIN is not up to date? What to use nowadays...? What does this output: env | grep -i wayland For me: XDG_SESSION_TYPE=wayland WAYLAND_DISPLAY=wayland-0 QT_WAYLAND_RECONNECT=1
For me it's (hopefully no secret info included) XDG_SESSION_TYPE=wayland XAUTHORITY=/run/user/1000/.mutter-Xwaylandauth.VZL2U2 MEMORY_PRESSURE_WATCH=/sys/fs/cgroup/user.slice/user-1000.slice/user@1000.service/session.slice/org.gnome.Shell@wayland.service/memory.pressure WAYLAND_DISPLAY=wayland-0 I was somehow blocked -> ah yes, wayland :-) Nearly forgot and NOT using by purpose :-/
Michael: do you repro this?
(In reply to Buovjaga from comment #11) > Michael: do you repro this? Yes, I can reproduce with both, LO running as a native client and on XWayland (via QT_QPA_PLATFORM=xcb). (In reply to Armin Le Grand from comment #7) > I do not know what you mean, so probably -> no. > Maybe using SAL_USE_VCLPLUGIN is not up to date? What to use nowadays...? That's still the way to select the VCL plugin. Does "VCL: kf5" actually show up for you in "Help" -> "About LibreOffice"? (It's not built by default, autogen option `--enable-kf5` can be used to enable it, or alternatively `--enable-qt5`, `--enable-qt6`, `--enable-kf6` for the other Qt-based VCL plugins.) Version: 25.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: eacc3489392bf4006acdd10bcd191afe2a5c92e2 CPU threads: 32; OS: Linux 6.10; UI render: default; VCL: qt6 (cairo+xcb) Locale: en-GB (en_GB.UTF-8); UI: en-US Calc: CL threaded Version: 25.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: eacc3489392bf4006acdd10bcd191afe2a5c92e2 CPU threads: 32; OS: Linux 6.10; UI render: default; VCL: qt6 (cairo+wayland) Locale: en-GB (en_GB.UTF-8); UI: en-US Calc: CL threaded
Thanks, adding '--enable-kf5' and combining with SAL_USE_VCLPLUGIN=kf5 did the trick, can repro it now. On it...
@Caolan: If I start an Impress (not yet deactivated TemplateView) and break at sfx2/source/control/thumbnailview.cxx:912 and set nItemCount to 0 all is good. Thus it seems that ThumbnailView::Paint (only called once) is called somehow in the setup and paints over everything..? Size of rRenderContext is 800x480, no ClipRegion set. Same size & no Clip on repaint. Dlg can be called again using file/templates/ManageTemplates (Ctrl+Shift+N). That repeats that wrong paint. Now not only on the 1st paint. The (800x480) is the size of the inner panel. If the OutDev would have that size it would not be possible to paint over it. Are there mechanisms to have bigger target panes and somewhere a clip missing, but VCL *somehow* limits paint to set OutDev size...?
Ah: At the OutDev mnOutOffX/Y is set to (9,46), thus seems to be a virtual (window) one...? When I use cairo_image_surface_get_width(pSurface) cairo_image_surface_get_height(pSurface) I indeed get (832,620) for the cairo_surface_t. Seems as if I would need to detect some clipping being set somewhere...?
Okay, problem reproducible & understood, thinking about an elegant solution that will not be in the way in the future...
Armin Le Grand (Collabora) committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/59fc2b5ca9678855feb30345761dad739b546edc tdf#163125: CairoSDPR: Take virtual OutDevs into account It will be available in 25.2.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.
Looks fixed now with kf6
(In reply to Buovjaga from comment #18) > Looks fixed now with kf6 Indeed, thanks for the fix, Armin! Version: 25.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 178430733b0687a0f9334dda9a66e9b58ec8e7b0 CPU threads: 32; OS: Linux 6.10; UI render: default; VCL: qt6 (cairo+wayland) Locale: en-GB (en_GB.UTF-8); UI: en-US Calc: threaded