Description: The slide is flickering once when after the fade animation ends Steps to Reproduce: 1. open attachment 148255 [details] 2. F5 Actual Results: Screen flickering after the animation ends Expected Results: Smooth transition Reproducible: Always User Profile Reset: No Additional Info: Version: 6.3.0.0.alpha0+ Build ID: 61778fd20395794d2de3b52d60dcc65083aecd93 CPU threads: 4; OS: Windows 6.3; UI render: default; VCL: win; Locale: nl-NL (nl_NL); UI-Language: en-US Calc: CL
I have the same problem on 6.2.0.3 release. It is really annoying and renders Impress unusable for me. I have two displays if this information would help: 1280x1024 and 1680x1050.
I can't reproduce it in Version: 6.3.0.0.alpha0+ Build ID: 7c7a4675ad5d61add70dd073f680ea37012962ce CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk3; Locale: ca-ES (ca_ES.UTF-8); UI-Language: en-US Calc: threaded nor in Versión: 6.2.2.1 Id. de compilación: fcd633fb1bf21b0a99c9acb3ad6e526437947b01 Subprocs. CPU: 1; SO: Windows 6.1; Repres. IU: predet.; VCL: win; Configuración regional: es-ES (es_ES); Idioma de IU: es-ES Calc: threaded @Telesto, Could you please try to reproduce it with a master build from http://dev-builds.libreoffice.org/daily/master/ ? You can install it alongside the standard version. I have set the bug's status to 'NEEDINFO'. Please change it back to 'UNCONFIRMED' if the bug is still present in the master build
Confirmed, and bibisected to the same commit as bug 124709 (the cause of the problem is likely somewhere else). Only occurs with OpenGL enabled. Also seems similar to bug 99685 (but I couldn't repro that in Windows). https://cgit.freedesktop.org/libreoffice/core/commit/?id=dd199ccb46c036713c704a23e137d04623936e47 author Mike Kaganski <mike.kaganski@collabora.com> 2019-02-17 16:30:55 +0300 committer Mike Kaganski <mike.kaganski@collabora.com> 2019-02-18 09:28:19 +0100 tdf#98896: GetWidth/GetHeight vs getWidth/getHeight strikes back!
(In reply to Aron Budea from comment #3) > Only occurs with OpenGL enabled. seems to contradict with (from comment #0) > Additional Info: > UI render: default
(In reply to Mike Kaganski from comment #4) > (In reply to Aron Budea from comment #3) > > Only occurs with OpenGL enabled. > > seems to contradict with I made two mistakes... 1. It does occur with default rendering (the transitions are drawn using OpenGL regardless). 2. The offending commit is from after the report. :) Anyway, now the bug is 100% there.
*** Bug 137285 has been marked as a duplicate of this bug. ***
Interesting, if 398ceced15ee4fdd24b1f8db5e09096c3afa4804 would be a code pointer to also chase this one.
The flash happens in OGLTransitionerImpl::disposing, during the call to impl_dispose; namely, inside OpenGLContext::dispose and the reset that it calls. AFAICT it happens in all OpenGL effects. And it doesn't happen when running the slide show in windowed mode. My theory would be that commit dd199ccb46c036713c704a23e137d04623936e47 made the slide show truly full-screen, which was *its intended effect*; but that exposed some pre-existing bug that causes the flash when the full-screen OpenGL rendering ends. Possibly the OpenGL expert could see the problem immediately? Quikee, could you please take a look if you have an idea?
So inside SlideShowImpl::update, a call to maActivitiesQueue.processDequeued ends the OpenGL transition, causing OpenGL context destroyed, eventually calling wglDeleteContext inside WinOpenGLContext::destroyCurrentContext - and that call clears the window (making it transparent maybe?), showing whatever is underneath - desktop, Impress window, etc. And only when SlideShowImpl::update calls its next maScreenUpdater.commitUpdates, and it in turn calls pView->updateScreen, the screen is filled with the next frame. I don't know why this is different in windowed case; and also if it's possible to postpone the destruction of the OpenGL context to after the maScreenUpdater.commitUpdates.
Mike Kaganski committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/ca6888484e643e0c55918d9c882241e6dd6b734f Related: tdf#122737 A hack to keep backing window opaque on context destruction It will be available in 7.5.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.
Had the same problem in LibO on Windows 11 in version 7.5.1. I made a query on the LibO Telegram channel about this issue and they mentioned that the problem was known, but there would be patches for version 7.5.2. Now when testing 3D transitions they only look good when previewing them, but when viewing them in full screen they just don't play. The slides go through without showing any transition. I couldn't manage with any screencast software to record when starting the presentation in full screen, so I made a video with my cell phone. Version: 7.5.2.2 (X86_64) / LibreOffice Community Build ID: 53bb9681a964705cf672590721dbc85eb4d0c3a2 CPU threads: 8; OS: Windows 10.0 Build 22621; UI render: Skia/Vulkan; VCL: win Locale: es-CL (es_CL); UI: es-ES Calc: CL threaded Laptop: ThinkPad T495 AMD Ryzen 5 Pro 3500U, Vega 8 Graphics, 24 Gb RAM. This behavior only occurs using the LibreOffice defaults, since by disabling Skia/Vulkan and only using OpenGL, the transitions work, but showing the strange flash described in this bug report.
Created attachment 186454 [details] skia/vulkan impress transitions
Created attachment 186455 [details] openGL Impress transitions
Still present on NEWEST WIN11 with NVIDIA-graphics Any workarounds? Disabling OpenGL gets rid of it but also stops many animations from working. Version: 24.8.4.2 (X86_64) / LibreOffice Community Build ID: bb3cfa12c7b1bf994ecc5649a80400d06cd71002 CPU threads: 16; OS: Windows 11 X86_64 (10.0 build 22631); UI render: Skia/Raster; VCL: win Locale: en-GB (en_GB); UI: en-GB Calc: CL threaded