Bug Hunting Session
Bug 118649 - Impress Slideshow "Fade Smoothly" Starts Aggressively
Summary: Impress Slideshow "Fade Smoothly" Starts Aggressively
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Impress (show other bugs)
Version:
(earliest affected)
5.4.7.2 release
Hardware: Other All
: medium minor
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: Slide-Transitions
  Show dependency treegraph
 
Reported: 2018-07-09 19:34 UTC by Steve White
Modified: 2019-01-08 19:22 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Attachments
Impress Presentation to Illustrate Aggressive Fade Smoothly (4.03 MB, application/vnd.oasis.opendocument.presentation)
2018-07-10 21:53 UTC, Steve White
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Steve White 2018-07-09 19:34:58 UTC
Description:
Fade Smoothly to a new slide begins at maybe 25% +/-, NOT at 0%. With sufficient Memory assigned, the rest of the Fade is, in fact, quite Smooth. The result is the new image leaps into view, then begins to Fade Smoothly until fully faded. 

Steps to Reproduce:
1.In Slideshow, slide Transition, use Fade Smoothly.
2.Select 3 or 4 second Fade duration.
3.Run slideshow.
4.The slower you want the Fade, the more abrupt the jump start will appear.

Actual Results:
The new image (#2) appears instantly at let's say 25% (not 0%) before fading IN.  So, the transition begins with a "jump start" at 100%/25% for image1/image2 and slowly progresses to 0%/100%.  The fade duration is reduced by the actual value of the jump.

Expected Results:
Imagine using a broadcast video switcher and fading slowly from one image to another.  You expect the transition to begin at 100%/0% and slowly progress to 0%/100% for the two images. This is not what happens.


Reproducible: Always


User Profile Reset: No



Additional Info:
Thank you,
Steve
Comment 1 Steve White 2018-07-10 18:02:23 UTC
Correction:
The fade duration may be reduced by the actual value of the jump.
Comment 2 Susan Gessing 2018-07-10 20:24:29 UTC
I tested this with the following builds using a 4-slide presentation (let me know if you want a copy of the file). The following happened:

I ran the slide show. The first slide came up and there was a flash to the LO interface and back again. It was a second long. When I went through the next 3 slides, there was a flash each time on each of the slides. Sometimes during a flash, you can see the title actually move. I don't know if this is what you mean and/or if this is related, but this is what I found. The flashing happens both before and after the transition.

Version: 6.0.5.2 (x64)
Build ID: 54c8cbb85f300ac59db32fe8a675ff7683cd5a16
CPU threads: 4; OS: Windows 6.3; UI render: GL; 
Locale: en-US (en_US); Calc: CL

and

Version: 6.2.0.0.alpha0+
Build ID: b1740fba0d1e6e3d69c3781734509317f42a0e4f
CPU threads: 4; OS: Windows 6.3; UI render: GL; 
TinderBox: Win-x86@42, Branch:master, Time: 2018-06-15_08:49:04
Locale: en-US (en_US); Calc: CL
Comment 3 Steve White 2018-07-10 21:53:11 UTC
Created attachment 143437 [details]
Impress Presentation to Illustrate Aggressive Fade Smoothly

Susan, thank you for your comment.

I have not seen that phenomenon.  It may be unique to 6.2 alpha.

Attached is an Impress presentation of 17 slides that I hope illustrates what I see.  I believe what the brain perceives is very much dependent upon content of Slides 1 and 2 during each transition.  In other words, the jump start is easier to see in some transitions.

I welcome all comments.  Sure would like to see this resolved.

Steve
Comment 4 Buovjaga 2018-07-17 14:28:16 UTC
(In reply to Steve White from comment #0)
> Actual Results:
> The new image (#2) appears instantly at let's say 25% (not 0%) before fading
> IN.  So, the transition begins with a "jump start" at 100%/25% for
> image1/image2 and slowly progresses to 0%/100%.  The fade duration is
> reduced by the actual value of the jump.

I see what you mean. There are other reports about glitches and I even confirmed one (bug 111874), but now I only see this "25% jump start effect".

Arch Linux 64-bit
Version: 6.0.5.2
Build ID: 6.0.5-1
CPU threads: 8; OS: Linux 4.17; UI render: default; VCL: kde4; 
Locale: fi-FI (fi_FI.UTF-8); Calc: group

Arch Linux 64-bit
Version: 6.2.0.0.alpha0+
Build ID: 860a9daf2b45942a4b10ff22d36aa3fe29be19f4
CPU threads: 8; OS: Linux 4.17; UI render: default; VCL: gtk3; 
Locale: fi-FI (fi_FI.UTF-8); Calc: group threaded
Built on July 14th 2018
Comment 5 Steve White 2018-07-25 17:34:09 UTC
Buovjaga,

I meant to comment earlier.
Thank you for looking into this.

I agree, I see it EVERY time now.

Here's another one for your investigation:
https://bugs.documentfoundation.org/show_bug.cgi?id=118643

Steve
Comment 6 Steve White 2018-08-24 17:28:52 UTC
With Respect,

It's been quite sometime since I submitted this Bug Report.  It has been confirmed by at least one contributor, yet the status remains NEW.

What happens next, when?

Regards,
Steve
Comment 7 Buovjaga 2018-08-24 17:32:28 UTC
(In reply to Steve White from comment #6)
> With Respect,
> 
> It's been quite sometime since I submitted this Bug Report.  It has been
> confirmed by at least one contributor, yet the status remains NEW.
> 
> What happens next, when?

If you want to speed up bug fixing, the only way is paying a development consultancy: https://www.documentfoundation.org/gethelp/developers/
Comment 8 Steve White 2018-08-24 20:45:59 UTC
Buovjaga,

Thank you for your quick comment.  I infer from your response that my question was poorly worded or that you were somehow displeased by it.

IF either is the case
THEN I apologize and will endeavor to be clearer in the future.

I did not ask why this bug has not been fixed.
I did not ask when it would be fixed.
I asked about the process.

Specifically, since you have confirmed it is a bug, even see it often,
- When might the status be updated to reflect your observation?
- Is the next status ASSIGNED?
- When might that occur?

IF this bug has been resolved in a later version,
THEN is that version considered ready and recommended for wide utilization?
AND which version is it?

Thanks, again,
Steve
Comment 9 Buovjaga 2018-08-25 07:27:06 UTC
I was not displeased. I just wanted to quickly explain the process from the perspective of an individual or a company wanting to see a bug fixed.

The next status would indeed be ASSIGNED, either when some volunteer developer takes interest in it or a paying customer wants the bug gone. https://wiki.documentfoundation.org/QA/Bugzilla/Fields/Status/ASSIGNED

Then the developer marks it as RESOLVED FIXED https://wiki.documentfoundation.org/QA/Bugzilla/Fields/Status/RESOLVED#FIXED

Then the original reporter or quality assurance marks it either as VERIFIED FIXED or REOPENED (more rare) https://wiki.documentfoundation.org/QA/Bugzilla/Fields/Status/REOPENED

Surprisingly often reports are closed as RESOLVED WORKSFORME due to them either being duplicates of some other (unknown) report or fixed without a developer having been aware of the report.
Comment 10 Steve White 2018-08-25 13:51:21 UTC
Thank you, sir

I appreciate your detailed reply.

After sending my last comment, I searched for what appeared to be the next release ready for wider adoption and installed v. 6.1.0.3 (x64) to my windows 10 computer.

Both this "aggressive fade" bug and the "hourglass" bug (118643) are present in this newer release, as well.

Regards,
Steve