Bug 122737 - The slide flashes once when after the fade animation ends
Summary: The slide flashes once when after the fade animation ends
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Impress (show other bugs)
(earliest affected)
Hardware: All All
: medium normal
Assignee: Not Assigned
Keywords: bibisected, bisected, regression
: 137285 (view as bug list)
Depends on:
Blocks: Impress-OpenGL Slide-Transitions
  Show dependency treegraph
Reported: 2019-01-15 16:08 UTC by Telesto
Modified: 2020-10-12 19:29 UTC (History)
5 users (show)

See Also:
Crash report or crash signature:
Regression By:


Note You need to log in before you can comment on or make changes to this bug.
Description Telesto 2019-01-15 16:08:51 UTC
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:
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
Comment 1 Semion Nadezhdin 2019-02-17 08:43:46 UTC
I have the same problem on release. It is really annoying and renders Impress unusable for me.
I have two displays if this information would help: 1280x1024 and 1680x1050.
Comment 2 Xisco Faulí 2019-03-21 11:56:32 UTC
I can't reproduce it in

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

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

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
Comment 3 Aron Budea 2019-05-27 02:26:13 UTC
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).

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!
Comment 4 Mike Kaganski 2019-05-27 07:22:08 UTC
(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
Comment 5 Aron Budea 2019-05-28 03:37:03 UTC
(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.
Comment 6 Telesto 2020-10-12 19:29:41 UTC
*** Bug 137285 has been marked as a duplicate of this bug. ***