Make sure you have Skia enabled, and software rendering disabled, ie. the About box shows: "UI render: Skia/Vulkan" Open attachment 172691 [details] from bug 142709, and play it as slide show. => The Tiles slide transition is only shown before the first slide, and not before the second slide. Both transitions are shown with Skia software rendering. There's also a flicker when the transition ends, that's reported in bug 137666. Encountered this when testing bug 142709. Observed using: Version: 7.5.0.0.alpha0+ (x64) / LibreOffice Community Build ID: dc92a4d973086ce8a6a5f75ba0f4d4c9ca05537a CPU threads: 16; OS: Windows 10.0 Build 19044; UI render: Skia/Vulkan; VCL: win Locale: hu-HU (hu_HU); UI: en-US Calc: CL threaded Already in 7.0.0.3.
Hi Aron... I know this is not the renderer you're testing, but on my system the Tiles transition simply doesn't work. So opening this file and playing it will result in no transitions at all. Version: 7.3.6.2 / LibreOffice Community Build ID: 30(Build:2) CPU threads: 16; OS: Linux 5.15; UI render: default; VCL: kf5 (cairo+xcb) Locale: pt-BR (pt_BR.UTF-8); UI: en-US Ubuntu package version: 1:7.3.6~rc2-0ubuntu0.22.04.1~lo1 Calc: threaded Disabling hardware acceleration has no effect. The transition also does not work in LO 7.5+. Using the Fade transition does work (I guess it uses opengl).
Hi Rafael, Timur had the same experience in bug 142709 comment 10. I would prefer keeping these issues separate until we know for sure they are related, but would be good to report your/Timur's case as well, in that case please add this to See Also.
This got fixed by the following commit in 25.2: https://cgit.freedesktop.org/libreoffice/core/commit/?id=d239ac793f89c95cac95e5601a7d7a06c76dfd3c author Tibor Nagy <tibor.nagy.extern@allotropia.de> 2024-10-27 23:44:00 +0100 committer Nagy Tibor <tibor.nagy.extern@allotropia.de> 2024-10-28 09:48:30 +0100 "tdf#76981 sd: Hide the document opening process when opening linked" In particular, the following "sneaky" change in vcl/win/window/salframe.cxx (since it doesn't seem to be relevant to the what's described in the commit message): - nScreenDX = aRect.GetWidth(); - nScreenDY = aRect.GetHeight(); + nScreenDX = aRect.GetWidth() + 1; + nScreenDY = aRect.GetHeight() + 1; Mike, is this a step back compared to bug 98896's fix, and should this bug and bug 137666 be fixed in a different way?
(In reply to Aron Budea from comment #3) > Mike, is this a step back compared to bug 98896's fix, and should this bug > and bug 137666 be fixed in a different way? No, it is not a step back (at least in this context). Commit dd199ccb46c036713c704a23e137d04623936e47 didn't decrease the dimensions of the rectangle - it has kept the first part of code functionally unchanged (because aRect.getWidth()+1 is the same as aRect.GetWidth()), and increased dimensions in the second part (for the same reason). The change that you quote must be a hack. There is no way this could be "the correct thing"; it is not even "inclusive" rectangle concept, this is "inclusive plus one". I anticipate some problems with multi-monitor setup - like partially protruding to the other monitor with this ... but it is not harmful in the frame of this bug. Of course, having the change documented in commit message (or in a comment in the code) would be ideal...