Bug 40534 - slide tearing or not shown in LARGE screens (high resolution) with hardware acceleration enabled (a buffer issue per comment 58)
Summary: slide tearing or not shown in LARGE screens (high resolution) with hardware a...
Status: VERIFIED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Impress (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: x86-64 (AMD64) Windows (All)
: high major
Assignee: Jan-Marek Glogowski
URL:
Whiteboard: target:6.4.0 target:6.3.3
Keywords:
: 61892 66567 68579 72389 73650 74730 89225 91651 91718 92362 92874 92973 97943 98229 104773 106341 106526 113010 116521 117627 122979 123271 125345 126780 (view as bug list)
Depends on:
Blocks: HiDPI Slide-Show Multimonitor
  Show dependency treegraph
 
Reported: 2011-08-31 15:43 UTC by Duarte
Modified: 2023-10-15 13:36 UTC (History)
37 users (show)

See Also:
Crash report or crash signature:


Attachments
Screenshot of screen tearing in impress dual screen mode (746.54 KB, image/jpeg)
2011-08-31 15:43 UTC, Duarte
Details
Another screenshot of the symptoms from a presentation being created inside Impress (880.14 KB, image/jpeg)
2011-08-31 15:47 UTC, Duarte
Details
Screen Tearing in Impress 4.4.3.2 presentation mode (237.58 KB, image/png)
2015-06-06 23:49 UTC, Duarte
Details
Screenshot of destroyed/splitted screen in res. 2560x1900 (20.83 KB, image/jpeg)
2015-12-11 00:08 UTC, Manfred Braun
Details
Fullscreen No HW Acceleration (80.46 KB, image/png)
2016-10-10 08:56 UTC, Claudius Coenen
Details
Fullscreen With HW Acceleration (27.46 KB, image/png)
2016-10-10 08:59 UTC, Claudius Coenen
Details
In-Window HW Acceleration SMALL (118.90 KB, image/png)
2016-10-10 09:02 UTC, Claudius Coenen
Details
In-Window HW Acceleration LARGE (59.56 KB, image/png)
2016-10-10 09:06 UTC, Claudius Coenen
Details
Shows Presentation screen corruption w/HW Acceleration enabled (1.69 MB, image/png)
2019-01-11 21:38 UTC, craig@arno.com
Details
Shows Presentation screen w/HW Acceleration disabled (7.52 MB, image/png)
2019-01-11 21:41 UTC, craig@arno.com
Details
tearing in 6.3.0.4 (109.37 KB, image/png)
2019-08-09 07:17 UTC, Claudius Coenen
Details
tearing in 6.3.0.4 full screen (39.96 KB, image/png)
2019-08-09 07:18 UTC, Claudius Coenen
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Duarte 2011-08-31 15:43:27 UTC
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)
Comment 1 Duarte 2011-08-31 15:47:33 UTC
Created attachment 50789 [details]
Another screenshot of the symptoms from a presentation being created inside Impress
Comment 2 Björn Michaelsen 2011-12-23 12:32:43 UTC Comment hidden (obsolete)
Comment 3 Duarte 2012-02-18 12:32:36 UTC Comment hidden (obsolete)
Comment 4 Roman Eisele 2012-05-04 03:31:08 UTC
This is an Impress issue, therefore changed the 'Component' field appropriately; this allows us to abbreviate the Summary.
Comment 5 Duarte 2013-01-13 19:19:45 UTC
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
Comment 6 sophie 2014-03-11 12:19:18 UTC
*** Bug 74730 has been marked as a duplicate of this bug. ***
Comment 7 ign_christian 2014-07-14 03:38:15 UTC
Hi Duarte.. I know it's a different problem, but perhaps you could try disabling h/w acceleration as suggested in Bug 72389.
Comment 8 Duarte 2014-07-14 21:05:19 UTC
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 :)
Comment 9 ign_christian 2014-07-15 03:15:01 UTC
(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.
Comment 10 ign_christian 2014-07-15 03:20:47 UTC
@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.
Comment 11 Olav Seyfarth 2014-07-15 07:46:19 UTC
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.
Comment 12 Duarte 2014-07-15 09:29:53 UTC
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
Comment 13 ign_christian 2014-07-15 14:30:09 UTC
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
Comment 14 Olav Seyfarth 2014-07-15 14:55:30 UTC
*** Bug 72389 has been marked as a duplicate of this bug. ***
Comment 15 Olav Seyfarth 2014-07-15 14:59:38 UTC
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).
Comment 16 Owen Genat (retired) 2014-09-21 08:02:15 UTC
*** Bug 82121 has been marked as a duplicate of this bug. ***
Comment 17 raal 2014-12-15 10:36:52 UTC
*** Bug 66567 has been marked as a duplicate of this bug. ***
Comment 18 tommy27 2015-06-06 07:10:33 UTC
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
Comment 19 Duarte 2015-06-06 23:49:27 UTC
Created attachment 116341 [details]
Screen Tearing in Impress 4.4.3.2 presentation mode
Comment 20 Duarte 2015-06-06 23:54:30 UTC
(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.
Comment 21 tommy27 2015-06-07 08:16:34 UTC
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.
Comment 22 tommy27 2015-06-07 08:43:53 UTC
*** Bug 68579 has been marked as a duplicate of this bug. ***
Comment 23 Pierre C 2015-06-07 12:09:04 UTC
I've made many tests.

The problem occurs Onlny with my new  lmonitor
Comment 24 Pierre C 2015-06-07 12:16:01 UTC
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
Comment 25 Duarte 2015-06-07 18:18:55 UTC
> 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.
Comment 26 Duarte 2015-06-07 21:57:33 UTC
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/
Comment 27 tommy27 2015-06-24 04:38:50 UTC
*** Bug 73650 has been marked as a duplicate of this bug. ***
Comment 28 tommy27 2015-07-04 04:49:03 UTC Comment hidden (obsolete)
Comment 29 Pierre C 2015-07-04 06:00:36 UTC
The problem is still on 5.0.0.2
Comment 30 Duarte 2015-07-05 23:24:31 UTC
(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
Comment 31 tommy27 2015-07-06 05:22:24 UTC Comment hidden (obsolete)
Comment 32 Duarte 2015-07-06 14:26:14 UTC
(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.
Comment 33 Duarte 2015-07-07 13:00:58 UTC
(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
Comment 34 tommy27 2015-07-23 16:58:25 UTC
*** Bug 92874 has been marked as a duplicate of this bug. ***
Comment 35 tommy27 2015-07-23 16:59:53 UTC
an user reported the same issue at Bug 92874 with this configuration

Graphics card: Nvidia GeForce GTX 780
Monitor:       Dell U3014
Resolution:    2560x1600
Comment 36 tommy27 2015-07-23 17:01:03 UTC
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
Comment 37 tommy27 2015-07-28 12:16:08 UTC
*** Bug 92973 has been marked as a duplicate of this bug. ***
Comment 38 Mikeyy - L10n HR 2015-07-28 13:09:50 UTC
(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.
Comment 39 tommy27 2015-07-28 14:19:43 UTC
*** Bug 91651 has been marked as a duplicate of this bug. ***
Comment 40 Duarte 2015-07-29 16:41:33 UTC
(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.
Comment 41 tommy27 2015-08-15 18:40:25 UTC
*** Bug 92362 has been marked as a duplicate of this bug. ***
Comment 42 tommy27 2015-08-15 18:41:33 UTC
after seeing 10 duplicates I think it's time to set priority to highest.
Comment 43 tommy27 2015-10-04 12:58:54 UTC
*** Bug 89225 has been marked as a duplicate of this bug. ***
Comment 44 Manfred Braun 2015-12-11 00:03:29 UTC
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
Comment 45 Manfred Braun 2015-12-11 00:08:49 UTC
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.
Comment 46 Manfred Braun 2015-12-11 00:15:44 UTC
Sorry, typo: Upload title should contain "2560x1600", like in comment ...
BTW, when does someone make reports/bugs/etc editable ???!!
Comment 47 csongor 2015-12-11 03:02:40 UTC
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.
Comment 48 Duarte 2015-12-11 03:17:04 UTC
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.
Comment 49 Pierre C 2015-12-17 08:14:52 UTC
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.
Comment 50 tommy27 2015-12-23 06:33:13 UTC
*** Bug 61892 has been marked as a duplicate of this bug. ***
Comment 51 David REBOUL 2016-02-02 17:54:03 UTC
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
Comment 52 David REBOUL 2016-02-02 18:05:00 UTC
I just confirmed that turning off hardware acceleration is fixing the problem.
Thanks for all
Comment 53 Buovjaga 2016-03-09 08:21:45 UTC
*** Bug 98229 has been marked as a duplicate of this bug. ***
Comment 54 Claudius Coenen 2016-10-10 08:56:44 UTC
Created attachment 127911 [details]
Fullscreen No HW Acceleration
Comment 55 Claudius Coenen 2016-10-10 08:59:58 UTC
Created attachment 127912 [details]
Fullscreen With HW Acceleration
Comment 56 Claudius Coenen 2016-10-10 09:02:54 UTC
Created attachment 127913 [details]
In-Window HW Acceleration SMALL
Comment 57 Claudius Coenen 2016-10-10 09:06:34 UTC
Created attachment 127914 [details]
In-Window HW Acceleration LARGE
Comment 58 Claudius Coenen 2016-10-10 09:13:18 UTC
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)
Comment 59 Claudius Coenen 2016-10-10 09:16:25 UTC
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.
Comment 60 tommy27 2016-10-10 11:45:21 UTC
@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.
Comment 61 myotheremail 2017-01-28 08:22:29 UTC
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/
Comment 62 tommy27 2017-01-28 08:40:10 UTC
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.
Comment 63 Pierre C 2017-01-28 18:31:19 UTC
@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
Comment 64 tommy27 2017-01-29 08:20:38 UTC
(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.
Comment 65 Pierre C 2017-01-29 08:46:50 UTC Comment hidden (no-value)
Comment 66 Xisco Faulí 2017-10-10 10:58:24 UTC
*** Bug 97943 has been marked as a duplicate of this bug. ***
Comment 67 Xisco Faulí 2017-10-10 10:58:47 UTC
*** Bug 113010 has been marked as a duplicate of this bug. ***
Comment 68 Xisco Faulí 2017-10-28 18:24:52 UTC
*** Bug 104773 has been marked as a duplicate of this bug. ***
Comment 69 V Stuart Foote 2018-03-21 04:03:51 UTC
*** Bug 91718 has been marked as a duplicate of this bug. ***
Comment 70 V Stuart Foote 2018-03-21 04:04:09 UTC
*** Bug 106526 has been marked as a duplicate of this bug. ***
Comment 71 V Stuart Foote 2018-03-21 04:04:43 UTC
*** Bug 116521 has been marked as a duplicate of this bug. ***
Comment 72 V Stuart Foote 2018-03-21 04:32:45 UTC
*** Bug 106341 has been marked as a duplicate of this bug. ***
Comment 73 Frederic Parrenin 2018-03-21 08:44:36 UTC
Indeed, when I use hardware acceleration OR OpenGL rendering, the bug does not show up.
Comment 74 Claudius Coenen 2018-03-21 21:44:40 UTC Comment hidden (obsolete)
Comment 75 Claudius Coenen 2018-03-21 22:03:27 UTC
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.
Comment 76 craig@arno.com 2018-11-27 20:25:46 UTC
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.
Comment 77 Xisco Faulí 2019-01-11 20:36:39 UTC
Lowering importance: Highest + Inherit from OOo doesn't make much sense at this point anymore...
Comment 78 craig@arno.com 2019-01-11 21:38:45 UTC
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
Comment 79 craig@arno.com 2019-01-11 21:41:57 UTC
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
Comment 80 craig@arno.com 2019-01-11 21:46:39 UTC
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.
Comment 81 V Stuart Foote 2019-01-25 23:13:34 UTC
*** Bug 122979 has been marked as a duplicate of this bug. ***
Comment 82 Timur 2019-05-01 14:17:08 UTC
*** Bug 123271 has been marked as a duplicate of this bug. ***
Comment 83 V Stuart Foote 2019-08-08 22:44:19 UTC
*** Bug 126780 has been marked as a duplicate of this bug. ***
Comment 84 Claudius Coenen 2019-08-09 07:17:53 UTC
Created attachment 153250 [details]
tearing in 6.3.0.4
Comment 85 Claudius Coenen 2019-08-09 07:18:20 UTC
Created attachment 153251 [details]
tearing in 6.3.0.4 full screen
Comment 86 Claudius Coenen 2019-08-09 07:20:45 UTC
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
Comment 87 V Stuart Foote 2019-08-09 13:13:06 UTC
*** Bug 125345 has been marked as a duplicate of this bug. ***
Comment 88 Jan-Marek Glogowski 2019-10-10 18:29:47 UTC
Tentative fix: https://gerrit.libreoffice.org/#/c/80628/

I see too many rectangle implementations...
Comment 89 Commit Notification 2019-10-11 15:34:00 UTC
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.
Comment 90 Commit Notification 2019-10-12 19:55:02 UTC
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.
Comment 91 V Stuart Foote 2019-10-16 04:40:53 UTC
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!
Comment 92 Commit Notification 2019-10-17 09:17:46 UTC
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.
Comment 93 V Stuart Foote 2019-11-15 04:41:34 UTC
*** Bug 117627 has been marked as a duplicate of this bug. ***
Comment 94 V Stuart Foote 2023-10-15 13:36:01 UTC
*** Bug 66567 has been marked as a duplicate of this bug. ***