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
Correction: The fade duration may be reduced by the actual value of the jump.
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
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
(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
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
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
(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/
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
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.
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
Still reproducible under Ubuntu 20.04. A screen capture can be found in the following attachment of another bug: https://bugs.documentfoundation.org/attachment.cgi?id=164028 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