Created attachment 138008 [details] Screenshot of slideshow Enable OpenGL in LO. Open attachment 118390 [details] from bug 34803, which contains a simple (static) WMV video. Play it. => The UI remains on screen. See screenshot. The rendering is somewhat jaggy as well, but that isn't video-playback-specific. If the video isn't on the first slide, then it appears fine. Observed using LO 6.0beta1 & 5.2.0.4 / Windows 7. Doesn't occur with 5.1.0.3, though there the OpenGL + video playback combination isn't very stable. => regression
Hi Aron, is this issue still reproducible on master ?
Hi Xisco, yes, it's the same. Version: 6.1.0.0.alpha0+ (x64) Build ID: 3deac9691011711a3b9e50d19499c588af074d7f CPU threads: 16; OS: Windows 6.1; UI render: GL; TinderBox: Win-x86_64@42, Branch:master, Time: 2018-01-30_03:11:54 Locale: hu-HU (hu_HU); Calc: CL
*** Bug 118082 has been marked as a duplicate of this bug. ***
Created attachment 142634 [details] Bibisect log Bisected to author Michael Meeks <michael.meeks@collabora.com> 2016-01-12 21:02:01 +0000 committer Tor Lillqvist <tml@collabora.com> 2016-01-12 22:02:00 +0000 commit 8d6c1b6981f01bbc0057234f53fd139e87a5f010 (patch) tree 13aaeb573ecf06214a8c7a9bc76d2a93d518089f parent ab95fb7a19d7847dd1cbfad0059cc175a809a50f (diff) tdf#96385 - opengl: dynamically adjust priority of swap buffers. Initially we start with a very low priority, so that the lame bits of code that do eg. focus, and cursor rendering before the document is visible do not cause a swap, flash. Then after we've processed a REPAINT priority idle (hopefully our first paint) we adjust the swap priority to highest. Essentially a fusion of Tor's approach and mine. https://cgit.freedesktop.org/libreoffice/core/commit/?id=8d6c1b6981f01bbc0057234f53fd139e87a5f010
Adding CC to Michael Meeks
Adding Cc: to Michael Meeks
Is this still valid with the current LO version? I cannot reproduce this.
(In reply to Luboš Luňák from comment #7) > Is this still valid with the current LO version? I cannot reproduce this. I think so (at least if I interpret Play as F5) 1. Open attachment 118390 [details] 2. Press F5 Version: 6.3.0.0.alpha0+ Build ID: 3083fe569f96bf0289da1e9d0ef7da15ab22e2f6 CPU threads: 4; OS: Windows 6.3; UI render: GL; VCL: win; TinderBox: Win-x86@42, Branch:master, Time: 2019-04-16_01:39:55 Locale: nl-NL (nl_NL); UI-Language: en-US Calc: threaded
(In reply to Luboš Luňák from comment #7) > Is this still valid with the current LO version? I cannot reproduce this. Actually, the behavior changed for me as well. I can still reproduce with 6.3.0.0.alpha0+ (26e85974a0287ab5869e7ff0145a66b853d66a02) / Windows 7, which is the current latest 6.3 Windows bibisect build. However, in 6.3.0.0.alpha0+ (951282a27a9dd4c64fc206fcbdd805b4cb602816), there is now a white background, except the (still) video only blinks up for a split second, and is painted over with white as well, which I wouldn't call correct.
(In reply to Aron Budea from comment #9) > However, in 6.3.0.0.alpha0+ (951282a27a9dd4c64fc206fcbdd805b4cb602816), > there is now a white background, except the (still) video only blinks up for > a split second, and is painted over with white as well, which I wouldn't > call correct. The change happened with the following commit: https://cgit.freedesktop.org/libreoffice/core/commit/?id=d7f4f5650dd2c7fe1ccec50efd806e695b8bc18a author Miklos Vajna <vmiklos@collabora.com> 2019-04-17 11:38:47 +0200 committer Miklos Vajna <vmiklos@collabora.com> 2019-04-17 15:43:48 +0200 tdf#124756 slideshow: avoid mbPaintDisabled for media windows
As Skia with Vulkan will replace OpenGL UI rendering on all platforms, it does not make sense to keep OpenGL UI reports open. Details about Skia: https://www.collaboraoffice.com/success-story/implementing-vulkan-capable-libreoffice-user-interface-using-the-skia-library/
It seems OK with SKIA (Skia and OpenGL share code); so not everything is solved Version: 7.1.0.0.alpha0+ (x64) Build ID: 6640d7f405d2970ba2825a9455926cc803284d01 CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: Skia/Raster; VCL: win Locale: nl-NL (nl_NL); UI: en-US Calc: CL
(In reply to Telesto from comment #12) > It seems OK with SKIA (Skia and OpenGL share code); so not everything is > solved > Version: 7.1.0.0.alpha0+ (x64) > Build ID: 6640d7f405d2970ba2825a9455926cc803284d01 > CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: Skia/Raster; VCL: win > Locale: nl-NL (nl_NL); UI: en-US > Calc: CL Test Skia/Vulkan to check your GPU's behaviour
(In reply to Buovjaga from comment #13) > (In reply to Telesto from comment #12) > > It seems OK with SKIA (Skia and OpenGL share code); so not everything is > > solved > > Version: 7.1.0.0.alpha0+ (x64) > > Build ID: 6640d7f405d2970ba2825a9455926cc803284d01 > > CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: Skia/Raster; VCL: win > > Locale: nl-NL (nl_NL); UI: en-US > > Calc: CL > > Test Skia/Vulkan to check your GPU's behaviour That's equivalent of testing they crashing behavior; Vulkan is not to stable for me; but that's a driver related issue. FWIW: the code paths for Skia Vulkan/Raster are pretty the same. I have seen problem which occurred with OpenGL also in Raster. Anyhow this document is problem free, also with Vulkan