Download it now!
Bug 91456 - "Fade smoothly" slide transition is broken
Summary: "Fade smoothly" slide transition is broken
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Impress (show other bugs)
Version:
(earliest affected)
4.4.0.3 release
Hardware: x86-64 (AMD64) Windows (All)
: medium major
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: bibisected, bisected, regression
: 112920 112960 132400 (view as bug list)
Depends on:
Blocks: Slide-Transitions
  Show dependency treegraph
 
Reported: 2015-05-22 09:17 UTC by Kumāra
Modified: 2020-10-06 08:37 UTC (History)
11 users (show)

See Also:
Crash report or crash signature:


Attachments
Second slide with "Fade smoothly" (16.17 KB, application/vnd.oasis.opendocument.presentation)
2015-05-22 09:17 UTC, Kumāra
Details
Ubuntu 20.04 Impress Fade smoothly demonstration (6.14 MB, video/mp4)
2020-08-07 08:47 UTC, dldld
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Kumāra 2015-05-22 09:17:41 UTC
Created attachment 115808 [details]
Second slide with "Fade smoothly"

The "fade smoothly" slide transition is ok on 4.1.6.2, but broken on 4.4.3.2. See attached. (Sorry I can't be sure when it started. I've reverted to 4.1.6.2 a few times due to regression bugs.)
Comment 1 Arnaud LE CAM 2015-05-22 10:39:38 UTC
I can't reproduce on Linux with the attachment, neither on :

Version: 4.3.7.2
Build ID: 430m0(Build:2)

or on :

Version: 5.0.0.0.beta1
Build ID: 0a16c3dda4150008d9be6f24cbd15ac198d116d3
Locale : fr-FR (fr_FR.UTF-8)

In those 2 cases :
Linux 3.16.0-38-generic (x86_64)
Xubuntu 14.10
Comment 2 tommy27 2015-05-24 11:41:28 UTC
tested under Win8

fade smoothly works fine in 4.1.5 and 4.3.5
fade smoothly broken in 4.4.0.3

so it's a 4.4.x branch regression
needs bibisecting
Comment 3 tommy27 2015-05-24 12:10:15 UTC
interestingly the fade transition seems to work again in LibO 5.1.0.0.alpha1+
Build ID: 83eb114394879cbfd073322a51c47d02553c1fcf
TinderBox: Win-x86@39, Branch:master, Time: 2015-05-22_06:33:51
Locale: en-US (it_IT)

the fade is shown, however I see a blink when the image finally appears.

@Arnaud
is this consistent with your findings using 5.0 beta1?
Comment 4 László Németh 2015-06-09 08:38:15 UTC
It seems, missing image results the missing fading.  Clicking on the second slide, it shows only a missing image icon instead of the image in the bad builds.

Bibisected with bibisect-44max:

aeb0840ff404a857f6f9e8ea59e1918e6b46b043 is the first bad commit
commit aeb0840ff404a857f6f9e8ea59e1918e6b46b043
Author: Matthew Francis <mjay.francis@gmail.com>
Date:   Sun Mar 15 05:55:29 2015 +0800

    source-hash-286e2f5c6ec829bc0987b1be7016699f7ef03e5e
    
    commit 286e2f5c6ec829bc0987b1be7016699f7ef03e5e
    Author:     Zolnai Tamás <tamas.zolnai@collabora.com>
    AuthorDate: Sun Nov 16 15:12:54 2014 +0100
    Commit:     Zolnai Tamás <tamas.zolnai@collabora.com>
    CommitDate: Sun Nov 16 20:30:57 2014 +0100
    
        Related fdo#82953: Forget package URL of image after it is loaded
    
        It causes problems if we handle those imported images differently which
        are identified by a package URL, so after the first load remove
        this URL and handle images on the same way as inserted images.
    
        Some related bugs:
        * #i44367#
        * #i124946#
        * #i114361#
        * fdo#73270
    
        The image in the test document has a special ID which is different
        from that one which is generated by LO internally so after ODF export
        the new generated image URL is different from the imported one.
    
        Change-Id: I4e7d3490674c5f86bec5c7c6e1c975dcafd7c265
Comment 5 László Németh 2015-06-09 11:39:57 UTC
It seems, it is fixed in the recent libreoffice-4-4, too.
Comment 6 Kumāra 2015-07-30 05:45:54 UTC Comment hidden (obsolete)
Comment 7 tommy27 2015-07-30 06:53:32 UTC Comment hidden (obsolete)
Comment 8 Kumāra 2015-07-30 11:16:27 UTC
(In reply to tommy27 from comment #7)
> works fine in LibO 4.4.5.1 under Win7x64

Thanks. The the image blink there?

On 4.4.4.3 (Win7x64), it's as before. Instead of fading in smoothly, the slide just appears after a while.

László Németh, can you be specific on the version?
Comment 9 tommy27 2015-07-30 12:30:52 UTC
sorry I made a mistake...
the fade smoothly works in the 4.4.5.1 just in the presenter console preview window but not in the actual display window.

I retested with LibO 5.1.0.0 alpha and the fade smoothly works fine in both presenter console and presentation screen but there I still see the final blink at the end of the transition
Comment 10 Kumāra 2015-07-31 03:01:01 UTC
Thanks for reporting that.

I'm reopening this because it was wrongly marked as resolved. The blink means the transition is not working as it's supposed to. So, it's still "broken".
Comment 11 aflux 2015-09-12 14:58:58 UTC
I noticed a strange behaviour with "Fade smoothly" transition and I ignore if related to the present this bug or a new one.

On Impress 5.0.1.2 if "Fade smoothly" transition is chosen as first choice (from Impress fresh start, before was no transition, then Fade smoothly is selected) everything works ok. (with the final blink, as reported in Comment 10).

If, however some among other transitions are tried before (eg. Fall), "Fade smoothly" gets broken, and Impress restart is needed to fix it.

Interestingly when "Fade smoothly" breaks, it is broken through the entire slideshow. Other transitions get broken as well, like "Fade though black", "Static" and "Fine Dissolve".
Comment 12 roumanet 2015-10-12 14:28:52 UTC
I agree with other comments : fading seems to have a step with all inverted colors (if text is Orange, fading transition show it in blue).
Transitions aren't smoothly.
Many transitions types are impacted !
See example : http://david.roumanet.free.fr/bug_transition.avi
Comment 13 roumanet 2015-11-18 20:38:57 UTC Comment hidden (me-too)
Comment 14 roumanet 2015-11-24 22:35:49 UTC
tested with 5.1 alpha (from 24th november) : bug still there...
Comment 15 roumanet 2015-12-04 22:44:30 UTC
Colors problem corrected in LO 5.2 alpha0+
No more inverted Red/Blue colors while transitions

Version: 5.2.0.0.alpha0+
Build ID: 1ed6d1423c7cffa5403dad69a9946ec790a374f2
Threads 2; Ver: Windows 6.19; Render: GL; 

TinderBox: Win-x86@42, Branch:master, Time: 2015-11-29_01:57:00
Locale: fr-FR (fr_FR)
Comment 16 tommy27 2015-12-05 02:15:37 UTC
is this finally working as expected in 5.2.x or there's still some issues left?
Comment 17 roumanet 2015-12-05 09:10:33 UTC
It still a bug as described in bug id 78703 : 
while transition occurs we can see

[SlideA] -- SlideA mixed with SlideB -- [SlideB] [SlideA a very short time] [SlideB]

But colors are right now, on many transitions concerned (I've not tested because some transitions were working right before).
Comment 18 Robinson Tryon (qubit) 2015-12-13 11:13:20 UTC Comment hidden (obsolete)
Comment 19 jebsolutions 2016-09-12 04:18:24 UTC
I see the same problem as roumanet.  If you are transitioning from slide A to Slide B you see slide A again for a fraction of a second after the fade transition.  

I tested this with several versions and see the same problem on Windows and Linux:
Libreoffice 5.2.1 64 Bit version under windows 10 Pro 64 bit (with and without opengl enabled).  
Libreoffice 5.2.1 64 Bit version under Lubuntu 16.04.1 64 bit (with and wihtout opengl enabled).

This problem affects multiple slide transitions.  Some transitions never show the problem, and some show the problem about 50 percent of the time:

wipe = ok
wheel = ok
uncover = ok
random bars = ok
Checkers = ok
shape = ok
box = ok
wedge = ok
Venetian = ok
fade (smoothly) = problem
cut = ?
cover = ok
dissolve = ok
comb = ok
push = ok
split = ok
diagonal = ok
tiles = problem
cube = problem
circles = problem
helix = problem
fall = problem
turn around = problem
iris = problem
turn down = problem
rochade = problem
3d Venetian = problem
static = problem
fine dissolve = problem
vortex = ? not working?
ripple = problem
glitter = problem
honeycomb = ? not working? looks same as wipe right?
newsflash = problem
Comment 20 Xisco Faulí 2016-09-26 15:40:33 UTC
Adding Cc: to Zolnai Tamás
Comment 21 Xisco Faulí 2017-10-06 21:30:58 UTC
*** Bug 112920 has been marked as a duplicate of this bug. ***
Comment 22 Xisco Faulí 2017-10-07 08:09:36 UTC
*** Bug 112960 has been marked as a duplicate of this bug. ***
Comment 23 fax.k.root 2018-10-31 18:23:09 UTC
Version: 6.0.6.2: Bug is still present
Comment 24 Kumāra 2018-11-02 07:47:58 UTC
(In reply to fax.k.root from comment #23)
> Version: 6.0.6.2: Bug is still present

Hmmm... It's as if LO's Impress is doomed to be the poor relative among presentation programs.
Comment 25 gtxe 2019-01-20 12:28:31 UTC
Version 6.1.4.2: Bug still present.

After lots of trying, for me the bug dos not appear with Intel onboard Graphic.
(Core2Duo, Core i7, Core i5).

But always appears with ATI/AMD and nVidia Graphic Cards (open source and proprietary driver) and in VirtualBox too.

Dosn't matter OpenGL on/off, desktop compositing on/off.
Comment 26 gtxe 2019-01-25 17:07:41 UTC
Hello,
I want to correct my last state, because I found
an AMD PC where the fade transition is working
and an Intel PC where it is not working

here the output from "uname -a" and "lspci | grep VGA"

Linux linuxmintxfcepc 4.15.0-43-generic #46~16.04.1-Ubuntu SMP Fri Dec 7 13:31:08 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
09:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Device 15dd (rev c6)
LibreOffice 6.1.4.2   working


Linux manjaroxfcetestlaptop 4.19.16-1-MANJARO #1 SMP PREEMPT Fri Jan 18 17:03:05 UTC 2019 x86_64 GNU/Linux
00:02.0 VGA compatible controller: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (primary) (rev 03)
LibreOffice 6.0.7.3.0+   not working
LibreOffice 6.1.4.2      working


Linux manjarokdepc 4.19.16-1-MANJARO #1 SMP PREEMPT Fri Jan 18 17:03:05 UTC 2019 x86_64 GNU/Linux
00:02.0 VGA compatible controller: Intel Corporation Xeon E3-1200 v3/4th Gen Core Processor Integrated Graphics Controller (rev 06)
LibreOffice 6.1.4.2      not working


More informations needed?
Comment 27 TheBoss_9001 2019-06-17 09:25:28 UTC
Issue remains present in version 6.1.5.2 (build id: 1:6.1.5-3)

However it is interesting to note that the fade effect still works as an object animation but not as a slide transition.

uname -a
4.19.0-5-amd64 #1 SMP Debian 4.19.37-3 (2019-05-15) x86_64 GNU/Linux

lspci | grep VGA
00:02.0 VGA compatible controller: Intel Corporation UHD Graphics 620 (rev 07)
Comment 28 Kumāra 2019-07-02 03:13:34 UTC
(In reply to TheBoss_9001 from comment #27)
> However it is interesting to note that the fade effect still works as an
> object animation but not as a slide transition.

Yes, very odd indeed. As a non-coder, I do have trouble understanding why.

Maybe I should just use 4.1.6.2 for Impress alone. Can I use multiple versions on the same computer (and same login)?
Comment 29 tim 2020-01-24 21:08:20 UTC
I see in Debian Buster the same behaviour as explained in the bug description, but it materializes as an entirely black display for the duration of the transition. Other transitions such as Cube, 3D Venetian and Ripple also fail in the same way.

Version: 6.1.5.2
Build ID: 1:6.1.5-3+deb10u5
CPU threads: 4; OS: Linux 4.19; UI render: default; VCL: gtk3; 
Locale: en-US (en_US.UTF-8); Calc: group threaded

# uname -a
Linux *** 4.19.0-6-amd64 #1 SMP Debian 4.19.67-2+deb10u2 (2019-11-11) x86_64 GNU/Linux

# sudo lspci -v -s 00:02.0
00:02.0 VGA compatible controller: Intel Corporation 3rd Gen Core processor Graphics Controller (rev 09) (prog-if 00 [VGA controller])
	Subsystem: Lenovo 3rd Gen Core processor Graphics Controller
	Flags: bus master, fast devsel, latency 0, IRQ 29
	Memory at f0000000 (64-bit, non-prefetchable) [size=4M]
	Memory at e0000000 (64-bit, prefetchable) [size=256M]
	I/O ports at 6000 [size=64]
	[virtual] Expansion ROM at 000c0000 [disabled] [size=128K]
	Capabilities: [90] MSI: Enable+ Count=1/1 Maskable- 64bit-
	Capabilities: [d0] Power Management version 2
	Capabilities: [a4] PCI Advanced Features
	Kernel driver in use: i915
	Kernel modules: i915
Comment 30 Julien Nabet 2020-04-05 18:50:03 UTC
On pc Debian x86-64 testing with master sources updated today with gtk3 or gen rendering, I don't reproduce this.

I may be wrong but perhaps OpenGL may have some impact (I don't use it).
Could someone give it a try on a recent LO version (6.3.5 or brand new 6.4.2) after having disabled OpenGL (see https://wiki.documentfoundation.org/QA/FirstSteps#Graphics-related_issues_.28OpenGL.29)?

Have in mind that 6.1 and 6.2 branches are EOL so there won't be any fix (at least from TDF) on them. So no need to give a try with these old versions.
Comment 31 Timur 2020-04-05 21:17:23 UTC
It's ok to set Needinfo if one cannot reproduce, but not if just tested Linux and bug is marked Windows.
Comment 32 Pierre C 2020-04-06 09:54:01 UTC
Bug is still present with or With out OpenGL enabled
LO 6.4.3.1

LO 7 dev with Skia enabled

Blinking at the beginning and at the end of fading. unusable

I've suppressed all transitions in all my files since this bug (hundreds of files)
Comment 33 Timur 2020-04-25 18:19:54 UTC
*** Bug 132400 has been marked as a duplicate of this bug. ***
Comment 34 roumanet 2020-08-05 16:52:23 UTC
Seems to be solved on Windows 10 with Skia engine.
Comment 35 dldld 2020-08-07 08:47:53 UTC
Created attachment 164028 [details]
Ubuntu 20.04 Impress Fade smoothly demonstration
Comment 36 dldld 2020-08-07 08:52:54 UTC
With Ubuntu 20.04 it seems to work better, but still not perfect. 

Version: 7.0.0.3
Build ID: 8061b3e9204bef6b321a21033174034a5e2ea88e
CPU threads: 12; OS: Linux 5.4; UI render: default; VCL: gtk3
Locale: en-US (en_US.UTF-8); UI: en-US
Calc: threaded


Sometimes a wrong frame is shown in the transition. I added a little screen capture which shows the problems.

Furthermore, I found that when jumping to a specific slide with the keyboard always short a black screen blinks. 

Moreover, when using the keyboard to go back one slide the animation is not used and when using the button on the presenter console screen the animation is played.
Comment 37 Timur 2020-10-06 08:37:38 UTC
*** Bug 137285 has been marked as a duplicate of this bug. ***