Description: . Steps to Reproduce: open attachment https://bugs.documentfoundation.org/attachment.cgi?id=197768 Tools - Macros - Organize dialogs edit Dialog1 click on CommandButton1 Actual Results: control properties in left sidebar not visible Expected Results: control properties in left sidebar visible Reproducible: Always User Profile Reset: No Additional Info: .
This seems to have begun at the below commit in bibisect repository/OS linux-64-25.2. Adding Cc: to Armin Le Grand ; Could you possibly take a look at this one? Thanks 7813d2b047401f6212870e4ea557fa2a059f342e is the first bad commit commit 7813d2b047401f6212870e4ea557fa2a059f342e Author: Jenkins Build User <tdf@maggie.tdf> Date: Tue Aug 27 13:21:18 2024 +0200 source bf3cd8e50f886084500e3a8ff72ff4ffab05ddd7 172394: CairoSDPR: Make using SDPR dependent of ExperimentalMode | https://gerrit.libreoffice.org/c/core/+/172394
Created attachment 198283 [details] properties missing
confirm with Version: 25.2.0.1.0+ (X86_64) / LibreOffice Community Build ID: 468d47bdf44a772e989a0adbeb5bb097e3cb4f31 CPU threads: 16; OS: Linux 6.8; UI render: default; VCL: gtk3 Locale: ro-RO (ro_RO.UTF-8); UI: en-US Calc: threaded
On pc Debian x86-64 with master sources updated today, I could reproduce this. I noticed that if I change the window (with alt-tab for example) and go back to the dialog, the properties are displayed.
First had to struggle to 'find' Dialog1, but got it now. Indeed when using DISABLE_SYSTEM_DEPENDENT_PRIMITIVE_RENDERER=1 the control bar 'shows' that control properties (using lots of controls itself). Very strange - using CairoSDPR just means another paint. It *could* be that creation/activation of those controls is somehow 'bound' to them being painted by VCLPixelRenderer. That would be a hack, but is possible. Have to dig into it...
Indeed I get the same effect without CairoSDPR when changing in VclPixelProcessor2D::processControlPrimitive2D (in drawinglayer/source/processor2d/vclpixelprocessor2d.cxx) if (xNewGraphics.is()) to if (false)//xNewGraphics.is()) and thus just painting the control with the later call there to process(rControlPrimitive); That means that those commands inside the try-scope do as a side effect *create* the needed sub-windows in some way - what is a hack. The controls should be created as child windows somewhere where the window containing them is created. Hard to say how that should work, digging...
It clearly is some stuff in VclPixelProcessor2D::processControlPrimitive2D inside try..catch that makes those controls appear, tried to find out what exactly, but hard to debug. Thinking about if and how it is possible to better support that (in a more similar way) in CairoPixelProcessor2D::processControlPrimitive2D. Difficulty is we have no OutputDevice there, and that *by purpose* due to no longer be dependent of that in new rendering technologies. Digging and experimenting...
Experimenting using UNO API and awt::XGraphics, looks like I can keep the direct paint of controls. That would also enhance the render quality. Experimenting...
I was successful doing this, there is now https://gerrit.libreoffice.org/c/core/+/180967 which should fix this bug.
Armin Le Grand (Collabora) committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/7c0d5fab2b62a9cb79e228e372bb85d38fe73bcc tdf#164476 CiaroSDPR: improve ControlPrimitive2D rendering 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.