Download it now!
Bug 114081 - Playing slideshow with video on 1st slide shows artifacts (with OpenGL)
Summary: Playing slideshow with video on 1st slide shows artifacts (with OpenGL)
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: graphics stack (show other bugs)
Version:
(earliest affected)
5.2.0.4 release
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: bibisected, bisected, regression
: 118082 (view as bug list)
Depends on:
Blocks: VCL-OpenGL Media-Playback
  Show dependency treegraph
 
Reported: 2017-11-27 02:57 UTC by Aron Budea
Modified: 2019-04-30 19:49 UTC (History)
5 users (show)

See Also:
Crash report or crash signature:


Attachments
Screenshot of slideshow (120.21 KB, image/png)
2017-11-27 02:57 UTC, Aron Budea
Details
Bibisect log (2.91 KB, text/plain)
2018-06-10 10:58 UTC, Telesto
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Aron Budea 2017-11-27 02:57:34 UTC
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
Comment 1 Xisco Faulí 2018-02-01 09:39:34 UTC
Hi Aron, is this issue still reproducible on master ?
Comment 2 Aron Budea 2018-02-02 01:25:17 UTC
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
Comment 3 Telesto 2018-06-09 19:44:24 UTC
*** Bug 118082 has been marked as a duplicate of this bug. ***
Comment 4 Telesto 2018-06-10 10:58:02 UTC
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
Comment 5 Telesto 2018-06-10 10:58:58 UTC Comment hidden (obsolete)
Comment 6 Xisco Faulí 2018-06-11 09:06:18 UTC
Adding Cc: to Michael Meeks
Comment 7 Luboš Luňák 2019-04-29 14:16:32 UTC
Is this still valid with the current LO version? I cannot reproduce this.
Comment 8 Telesto 2019-04-29 14:51:54 UTC
(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
Comment 9 Aron Budea 2019-04-29 20:53:34 UTC
(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.
Comment 10 Aron Budea 2019-04-30 19:49:39 UTC
(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