Created attachment 50788 [details] Screenshot of screen tearing in impress dual screen mode While running a full screen presentation on a dual screen setup the main slide view shows a tearing slide, as if it was cut in several verticals stripes. This happens on both displays, with or without the presentation previewer showing on the "secondary" monitor. I am on a Windows 7 64bit machine, Intel Core i7 2600K GTX 580 and dual 2560x1600 Dell Displays, and this seems has been happening since at least version 3.3, on both power point PPS files or LibreOffice created presentations. Screenshot attached, (the task bar is showing because impress would not let me print screen while it had focus, had to click somewhere else to be able to print-screen)
Created attachment 50789 [details] Another screenshot of the symptoms from a presentation being created inside Impress
[This is an automated message.] This bug was filed before the changes to Bugzilla on 2011-10-16. Thus it started right out as NEW without ever being explicitly confirmed. The bug is changed to state NEEDINFO for this reason. To move this bug from NEEDINFO back to NEW please check if the bug still persists with the 3.5.0 beta1 or beta2 prereleases. Details on how to test the 3.5.0 beta1 can be found at: http://wiki.documentfoundation.org/QA/BugHunting_Session_3.5.0.-1 more detail on this bulk operation: http://nabble.documentfoundation.org/RFC-Operation-Spamzilla-tp3607474p3607474.html
This bug seems to be solved in LibreOffice 3.5.0 Tested with LibreOffice Portable 3.5.0 with several PPS and PPT files and seems to be working correctly.
This is an Impress issue, therefore changed the 'Component' field appropriately; this allows us to abbreviate the Summary.
Seems like it was not correctly fixed, if fixed at all. Maybe the problem went away by chance because of some other code changes? Anyway, screen tearing in Impress was back at least in version 3.6.2, and is still present in 3.6.4.3 Tested in Windows 7 64Bits with dual 2560x1600 resolution monitors
*** Bug 74730 has been marked as a duplicate of this bug. ***
Hi Duarte.. I know it's a different problem, but perhaps you could try disabling h/w acceleration as suggested in Bug 72389.
Hello ign_christian thanks for the suggestion, would have never thought of that. I can confirm that disabling hardware acceleration works around the bug, making the screen tearing artifacts go away. It works for the same hardwate configuration as originally reported: Windows 7 64bits nVidia GTX580 dual 2560 x 1600 displays Hopefully this narrowed down the origin of the problem for the devs, maybe we will see a definite fix soon :)
(In reply to comment #8) So it's a good news that we know what is the trigger :) I change summary a bit to better reflect the problem. Set status UNCONFIRMED since this report never confirmed by another user.
@Duarte, you could also help Olav by testing Bug 72389 and mark NEW if you can confirm. And vice versa :) Sorry..not many people here using dual screen. I also very rarely using that since I don't have it.
I DO confirm this bug. But it's not only on dual screens with both screens ACTIVE but appears to be triggered if more than one screen is present in the system and the BIG one is to be presented on. I added further details in Bug 72389.
Sure, I'll be glad to help. I am not currently at home but I can test it later tonight when I am back from work then I'll report my findings. In the meantime at work I also have a dualscreen setup but this time with different older specs: Windows XP 64bits nVidia GeForce 9600 GT One 1920 x 1200 display One 1680 1050 display The reported screen tearing and display errors don't happen in this setup even with hardware acceleration enabled, so as Olav Seyfarth as mentioned it seems to be triggered by large resolution (apparently over 1920 x 1200)displays. Let me know if I can help with any other bug or testing
Hm..after reread looks like same problem with Bug 72389: it's happen only with external/secondary large screen/monitor: - 2560 x 1600 px (this bug) - 2560 x 1440 px (Bug 72389) Not happen with 1920 x 1200 px screen (comment 12) Is it right Olav? Please correct if I miss something. And if you agree (both bugs are the same) please set your bug as duplicate to this one since this' been reported for the first time. Let set this bug to NEW per comment 11
*** Bug 72389 has been marked as a duplicate of this bug. ***
Note that this also happens in a NON-dual-screen setup. a LARGE screen seems to be sufficient to trigger the bug. Thus, the subject should probably be adjusted. For tests results with different (old and new) LO versions see bug 72389 (which is now marked as duplicate of this bug due to comment 13).
*** Bug 82121 has been marked as a duplicate of this bug. ***
*** Bug 66567 has been marked as a duplicate of this bug. ***
please guys, retest with latest LibO 4.4.3.2 and tell if situation has changed or not. please also take a look at Bug 91651 and it's duplicates and tell if you think we are dealing with the same issue
Created attachment 116341 [details] Screen Tearing in Impress 4.4.3.2 presentation mode
(In reply to tommy27 from comment #18) > please guys, retest with latest LibO 4.4.3.2 and tell if situation has > changed or not. > > please also take a look at Bug 91651 and it's duplicates and tell if you > think we are dealing with the same issue There doesn't seem to be any significant change in Impress Version: 4.4.3.2 Build ID: 88805f81e9fe61362df02b9941de8e38a9b5fd16 Portable, new screenshot attached. Bug 91651 seems to be the same issue, only in single screen mode. This seems to happen to people using screen resolutions larger than 1920x1080 while hardware acceleration is enabled. Disabling it makes the display artifacts go away.
thanks for feedback. Bug 91651 is probably a duplicate. however there's one user reporting the issue even at 1024x768 resolution https://bugs.documentfoundation.org/show_bug.cgi?id=91651#c3 first release the bug has been reported is 3.6.4 I wonder if it affected older releasese too and the OOo/AOO as well. affected users could give a try to old LibO releases that you can download as portable versions from here: http://sourceforge.net/projects/winpenpack/files/X-LibreOffice/releases/ and portable X-AOO from here ( http://www.winpenpack.com/en/download.php?view.1341 we should understand if the issue is inherited from OOo or if it's a regression of LibO development.
*** Bug 68579 has been marked as a duplicate of this bug. ***
I've made many tests. The problem occurs Onlny with my new lmonitor
I've made many tests. The problem occurs Only with my new large screen, and the same graphic card. I've test it on a VMware witch graphic layer is independent of my specific hardware. The problem starts at higher resolutions than 1920 x 1200 and is always solved with graphic acceleration disabled. I can make test any version of LO for Devs if it can help. just ask IMHO, this bug should be investigate. of course, there is an easy worked around, but with a slightly performance loss. And we need performance with large screen. On the other hand, it's a mess to work on OpenGL integration and disable HW acceleration
> first release the bug has been reported is 3.6.4 > I wonder if it affected older releases too and the OOo/AOO as well. Tested with the earliest and the latest available X-LibreOffice 3.3.4 and 4.3.7 and both showed the clipping artifacts. OpenOffice Portable 4.1.1 also show the exact same symptoms, and disabling Hardware Acceleration also solves the tearing problem. OpenOffice 2.3.1 didn't show the bug however, back then there was no hardware acceleration option though, only "Use OpenGL" and "Optimized output" which were both disabled by default. Turning them on still didn't reveal any display artifacts, though there was no "next slide preview" in the secondary monitor, not sure if that's what's causing the problems.
Tested once more with Apache OpenOffice Portable 3.0.0 (OOO300m9 Build9358) and the glitch is already there, with exact same symptoms (screen tearing with hardware acceleration enabled, solvable by turning it off). Seems to be something quite old, still from the days of Apache, if anyone else cares to dig through other older versions, there seems to be quite an extensive archive of them here http://sourceforge.net/projects/portableapps/files/OpenOffice.org%20Portable/
*** Bug 73650 has been marked as a duplicate of this bug. ***
LibO 4.4.4.3 is out. please give an update of the bug status using that version.
The problem is still on 5.0.0.2
(In reply to tommy27 from comment #28) > LibO 4.4.4.3 is out. please give an update of the bug status using that > version. Not availabe in portable flavor yet (still stuck at 4.4.3 apparently), will give it a try as soon as it is. Anyway has anything been done about about it in the meantime? I mean the bug is not gonna fix itself miraculously
@Duarte since the bug has been confirmed in 5.0.0 RC2 (see comment 29) I assume it's still present in 4.4.4.3 too so you don't need to retest I know bugs do not heal miraculously but sometimes a fix for a bug can cause good side effects on another (or bad side effects) so I think it's always better to use the latest version of the LibO branch you are still using, so I always recommend to upgrade once a new one comes out.
(In reply to tommy27 from comment #31) > @Duarte > > since the bug has been confirmed in 5.0.0 RC2 (see comment 29) I assume it's > still present in 4.4.4.3 too so you don't need to retest > > I know bugs do not heal miraculously but sometimes a fix for a bug can cause > good side effects on another (or bad side effects) so I think it's always > better to use the latest version of the LibO branch you are still using, so > I always recommend to upgrade once a new one comes out. Fair enough, actually something like that seems to have happened in LibreOffice 3.5 which I commented about in https://bugs.documentfoundation.org/show_bug.cgi?id=40534#c3, but whatever fixed it was short lived, because it was broken again a few versions later.
(In reply to tommy27 from comment #28) > LibO 4.4.4.3 is out. please give an update of the bug status using that > version. Just to make sure tested with 4.4.4.3 portable and it is still there
*** Bug 92874 has been marked as a duplicate of this bug. ***
an user reported the same issue at Bug 92874 with this configuration Graphics card: Nvidia GeForce GTX 780 Monitor: Dell U3014 Resolution: 2560x1600
I raise the priority to high since there are already 7 duplicates and we will see more in the future once large screens become more popular
*** Bug 92973 has been marked as a duplicate of this bug. ***
(In reply to tommy27 from comment #37) > *** Bug 92973 has been marked as a duplicate of this bug. *** Tested on Yoga 2 Pro Windows 8.1, all latest patches Intel HD 4400, GOP = 5.0.10343 CPU i5-4210U 1700GHz Resolution 3200 x 1800 Windows 8.1 has option to "Enlarge or make smaller text and other items", it shows to some applications resolution of 1600 x 900. Not sure what resolution does LO sees.
*** Bug 91651 has been marked as a duplicate of this bug. ***
(In reply to tommy27 from comment #36) > I raise the priority to high since there are already 7 duplicates and we > will see more in the future once large screens become more popular Good to know, hope it helps get this finally dealt with. It would be nice to have this fixed for LibreOffice 5.0, though with the eminent release in a few days it's unlikely it will find it's way to the final build.
*** Bug 92362 has been marked as a duplicate of this bug. ***
after seeing 10 duplicates I think it's time to set priority to highest.
*** Bug 89225 has been marked as a duplicate of this bug. ***
In presentation, the screen is disturbed - probably, like others mentioned here. The left side contains a white stripe, which shows the right part of the first folie, followed by a small black stripe, followed by a big white rectangle, which is about 70% of the screen, but it shows the same right part of the first folie, but only that small part - so the main white area in the middle is just white/blank. I do not see, if I can upload an image; Will try. Version: 4.4.0.3 Build ID: de093506bcdc5fafd9023ee680b8c60e3e0645d7 Locale: de_DE Hope, this helps. I am unable to use impress, because I cannot make any presentation. BR, Manfred
Created attachment 121214 [details] Screenshot of destroyed/splitted screen in res. 2560x1900 The original and used resolution of monitor/graka is 2560x1600 px, Monitor Dell U3011, GraKa: NVIdia GT 610 Windows Server 2008 R2, en (used as developer workstation), The uploaded image is proportionally resized to 1200x750 px. No other software has any problems - so, it does not look as a driver problem.
Sorry, typo: Upload title should contain "2560x1600", like in comment ... BTW, when does someone make reports/bugs/etc editable ???!!
As much as I know, there are two possible silly work-arounds for this: 1. Turn off hardware acceleration. Tools -> Options -> Libre Office -> View -> Graphic Output -> Enable Hardware Acceleration (or something like this, I use a non-English localisation so menu names may slightly differ) 2. Decrease the screen resolution to 1920x1080 or even lower before you start the slideshow. At least one of these solutions should work but of course, none of them is an acceptable solution in the long run.
I found that disabling hardware acceleration often makes presentations almost unusable, performance becomes too slow to use. It's been more than 4 years since original report, it would be really nice to finally have this fixed. High resolution displays are becoming more common, 4k is becoming mainstream and LO can't seem to handle anything above 1080, this problem is bound to become more and more frequent.
Hi, It seems that with latest LO 5.1.0.1, the problem is solved with OpenGL enabled, but not with hardware acceleration enabled. As graphite fonts still have problems with OpenGL enabled, this just the beginning of the end of the problem.
*** Bug 61892 has been marked as a duplicate of this bug. ***
Comment on attachment 121214 [details] Screenshot of destroyed/splitted screen in res. 2560x1900 Same issue on a Surface 3 with Windows 10 If I downgrade the screen resolution, I still get the issue
I just confirmed that turning off hardware acceleration is fixing the problem. Thanks for all
*** Bug 98229 has been marked as a duplicate of this bug. ***
Created attachment 127911 [details] Fullscreen No HW Acceleration
Created attachment 127912 [details] Fullscreen With HW Acceleration
Created attachment 127913 [details] In-Window HW Acceleration SMALL
Created attachment 127914 [details] In-Window HW Acceleration LARGE
I would speculate that there's a problem with the area that has to be rendered in HW-Accelerated mode. I come to this conclusion with this set of tests. - Requires a large screen (single screen 2560x1440 in my case) - Requires a slide (content irrelevant) Test 1: - Disable HW-Acceleration (Extras -> Options -> LibreOffice -> "Ansicht" (View?) - Enter presentation mode (full screen) -> Everything is fine (looks like attached "Fullscreen No HW Acceleration") Test 2: - Enable HW-Acceleration - Enter presentation mode (full screen) -> Everything looks broken (looks like attached "Fullscreen With HW Acceleration") Test 3: - Confirm HW-Acceleration is on - Change presentation setting from full screen to in window - Have a "smaller" window size (outside: 2361x1400 / inside: 2043x1246 or 2,545,578 pixels) - Enter Presentation mode -> looks fine (looks like attached "In-Window HW Acceleration SMALL") Test 4: - Confirm HW-Acceleration is on - Change window size to be slightly larger (outside: 2368x1400 / inside: 2051x1246 or 2,555,546 pixels) - Enter Presentation mode -> looks broken (looks like attached "In-Window HW Acceleration LARGE") Conclusion: I'd assume that somewhere somebody expected to "never have more than 2.5 Million pixels" or something like that. The window has a very reproducible point at which it will start working. You can easily find it when you have set "in window" presentations, and start with a large window. Just drag it smaller until something is correctly rendered (heads up: the other way round is barely noticable, as the perfectly rendered frame will just sit there when dragging the window larger and larger. It will not get redrawn)
I'm sorry, I forgot to mention: this has been tested with LibreOffice 5.2.2 (but I have been bitten by this bug for at least a year on various releases). I'm currently on windows 10, anniversary update. Again, this has affected me on Windows 8 (and possibly 7?) as well.
@Claudius Coenen interesting theory in comment 58. I hope the developers may take a look at the code to see if that's the root of the bug.
Confirmed with 5.2.3.3 on Windows 10 with a single (laptop) screen of 2560 x 1440. because HW acceleration in on by default this should really be fixed. I nearly abandoned LO for this bug because Impress becomes pretty useless unless you somehow find that it works without HW acceleration. When first having this issue I downloaded a version of OO, which worked. Not sure about HW acceleration there. There is also a short forum thread on this: https://ask.libreoffice.org/en/question/56297/full-screen-mode-impress-on-windows-10/
I raised priority about this bug from "highest normal" to "highest major". as said before, hi-res screens will become more and more diffuse and this bug will start affecting more and more users giving bad publicity to LibO.
@tommy27 I don't think that devs take care of quality impact of a bug. But in this particular case, things are going better With LO 5.3 IF HW acceleration is enabled and OpenGL enabled All works fine IF HW acceleration is disabled, it works fine too the only cse where it doesn't work is HW acceleration enabled and OpenGL disabled Pierre
(In reply to Pierre C from comment #63) > @tommy27 > > I don't think that devs take care of quality impact of a bug. > But in this particular case, things are going better > > With LO 5.3 IF HW acceleration is enabled and OpenGL enabled All works fine > IF HW acceleration is disabled, it works fine too > the only cse where it doesn't work is HW acceleration enabled and OpenGL > disabled > Pierre the fact that the bug is improved in 5.3.x demonstrates that the devs are doing a good work.
>the fact that the bug is improved in 5.3.x demonstrates that the devs are doing a good work. The fact is that this bug is more than five years old. And during this five years, more and more user where enabled to use impress. Of course, there where a workaround. Disabling HW acceleration. But if you do that, all your animations sucks. So no animations, just appear, disappear. And there are other examples, with little bugs, but high quality impact. Especially with Impress. Impress is often used in front of public. Any quality bug will have a big impact on public feeling. That's my case, I often have impress problems, and as it happens, public learn something more than my teaching. LO is cheap yeah, but it's a low quality software. And this have nothing to do with devs's work. Of course there are doing great job. But they don't care about little bugs with hight quality impact. They are just little bugs. This is mostly a fact than a point of view (as I can show you many bugs of this kind especially with impress). They don't care about it, because it is their choice, and they have limited resources.
*** Bug 97943 has been marked as a duplicate of this bug. ***
*** Bug 113010 has been marked as a duplicate of this bug. ***
*** Bug 104773 has been marked as a duplicate of this bug. ***
*** Bug 91718 has been marked as a duplicate of this bug. ***
*** Bug 106526 has been marked as a duplicate of this bug. ***
*** Bug 116521 has been marked as a duplicate of this bug. ***
*** Bug 106341 has been marked as a duplicate of this bug. ***
Indeed, when I use hardware acceleration OR OpenGL rendering, the bug does not show up.
Behaviour for me with LO 6.0.0.3 - OpenGL inactive, HW active: error is still existing - OpenGL inactive, HW inactive: no error - OpenGL active (HW greyed out): no error Basically, it's like before, but OpenGL is new. I am not sure what its default state is, in my case it was _active_, I can't remember if I ever changed this checkbox manually.
Behaviour for me with LO 6.0.2.1 - OpenGL inactive, HW active: error is still existing - OpenGL inactive, HW inactive: no error - OpenGL active (HW greyed out): no error Basically, it's like before, but OpenGL is new. I am not sure what its default state is, in my case it was _active_, I can't remember if I ever changed this checkbox manually.
Verified bug still exists in LO 6.1.3.2 (x64) Machine: Windows 10 professional Surface Book 3000x2000 (4K) display 150%, i7-6600U, 16GB RAM, 1TB SSD External (presentation) monitor connected through display port running in 2160p mode 43" (4K)59Hz 100% scaling (4096 x 2160) Transitioning from "use hardware acceleration" to not, impress "blew up" 2-3 times transitioning from slide 3->4, does not produce a crash file, does "recover" when restarted. Attempts to reproduce "crash" failed after the first 2-3 attempts. This was from a "cold" LO start, one run with HW acceleration, then disable HW acceleration and run presentation again. Point being, don't rely on Impress working with HW Acceleration disabled at 4K resolutions. It may crash a few times. With HW acceleration enabled screen paint is very slow followed by a blanking/tearing of the presentation screen immediately after screen paint completes. After "crashing" behavior stopped (3-4 tries), I was able to make it through the entire presentation, with excruciatingly slow screen paint speeds. Positive comment: Once the screen is rendered, the image is beautiful. I have one animated slide in this presentation which works properly even without acceleration.
Lowering importance: Highest + Inherit from OOo doesn't make much sense at this point anymore...
Created attachment 148243 [details] Shows Presentation screen corruption w/HW Acceleration enabled Initial screen paints very slowly (> 10 seconds) then completed image is replaced with this white corrupt screen. The "Presentation" screen is mostly white with some light blue '=' signs displayed. Not at all usable for a presentation; performance way too slow and display corruption. Presenter screen is Surfacebook 3000 x 2000 (4K) screen 150% Scale Presentation screen is 43-inch monitor @ 4096 x 2160 59Hz (4K), 100% Scale
Created attachment 148244 [details] Shows Presentation screen w/HW Acceleration disabled Initial screen paints very slowly (> 10 seconds). The "Presentation" screen looks fine when painting completes. Not usable for a "real" presentation; performance way too slow. Presenter screen is Surfacebook 3000 x 2000 (4K) screen 150% Scale Presentation screen is 43-inch monitor @ 4096 x 2160 59Hz (4K), 100% Scale
Microsoft Surfacebook Pro Processor Intel Core i7-6600U CPU @ 2.60GHz 2.81 GHz Installed RAM 16.0GB Windows 10 Pro x64 v1803 OS build 17134.523 LibreOffice Version: 6.1.3.2 (x64) Build ID: 86daf60bf00efa86ad547e59e09d6bb77c699acb CPU threads: 4; OS: Windows 10.0; UI render: default; Locale: en-US (en_US); Calc: group threaded Adding LO 6_1_3_2-Impress HW acceleration ON.png (Corrupted screens) LO 6_1_3_2-Impress HW acceleration OFF.png (Not Corrupted) HW acceleration off does not exhibit corruption but takes 10+ seconds/slide to paint screen (not acceptable for a real presentation). MS Power Point paints/builds "next" screen in a non-visible background buffer so when the next slide is requested transition is nearly instant as a result of a HW copy of memory buffer to the screen buffer. LibreOffice Impress needs something close to this level of performance. LibreOffice Impress otherwise is an excellent and impressive tool, it just can't perform well enough for real presentations until this is fixed.
*** Bug 122979 has been marked as a duplicate of this bug. ***
*** Bug 123271 has been marked as a duplicate of this bug. ***
*** Bug 126780 has been marked as a duplicate of this bug. ***
Created attachment 153250 [details] tearing in 6.3.0.4
Created attachment 153251 [details] tearing in 6.3.0.4 full screen
This is still the case, even with 6.3.0.4, the most recent release at the time of writing. Over the past eight years, resolutions above 1920x1200 have become more and more common. I'm starting to see projectors rolled out with 4K. I'm now much more likely to get a broken image when presenting in front of an audience. System: Windows 10 Pro, 2560x1440 monitor (but as we've seen in this ticket, it appears to be a threshhold somewhere slightly below that). I've tried to narrow it down in comment #58 in this ticket. https://bug-attachments.documentfoundation.org/attachment.cgi?id=153250 shows a simple thing in the editor, https://bugs.documentfoundation.org/attachment.cgi?id=153251 is the same slide in presentation mode in 6.3.0.4
*** Bug 125345 has been marked as a duplicate of this bug. ***
Tentative fix: https://gerrit.libreoffice.org/#/c/80628/ I see too many rectangle implementations...
Jan-Marek Glogowski committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/194e7ce17ae7ca278c12d03bc25684b7437f9785 tdf#40534 correctly match page with memory slab It will be available in 6.4.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Jan-Marek Glogowski committed a patch related to this issue. It has been pushed to "libreoffice-6-3": https://git.libreoffice.org/core/commit/edcb363f5eeefcc2ce28a2ab7a57d61b744466cd tdf#40534 correctly match page with memory slab It will be available in 6.3.4. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Verified fixed on Windows 10 Pro Hardware Acceleration on a 4K monitor (Samsung 40" monitor) with Version: 6.4.0.0.alpha0+ (x64) Build ID: 758516295e5f69393bd78bb4af6e7214d48ece0b CPU threads: 8; OS: Windows 10.0 Build 18362; UI render: default; VCL: win; Locale: en-US (en_US); UI-Language: en-US Calc: CL And, presentation using OpenGL rendering continued to work without issue. Thanks Jan-Marek!
Jan-Marek Glogowski committed a patch related to this issue. It has been pushed to "libreoffice-6-3-3": https://git.libreoffice.org/core/commit/5ce21a11ef300603599e4623171c161974582a28 tdf#40534 correctly match page with memory slab It will be available in 6.3.3. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
*** Bug 117627 has been marked as a duplicate of this bug. ***