Bug Hunting Session
Bug 97197 - With OpenGL active Impress slide transition Rochade effect blanking entire UI to white
Summary: With OpenGL active Impress slide transition Rochade effect blanking entire U...
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Impress (show other bugs)
Version:
(earliest affected)
5.1.0.2 rc
Hardware: All Windows (All)
: medium normal
Assignee: Michael Meeks
URL:
Whiteboard: target:5.2.0 target:5.1.1
Keywords:
Depends on:
Blocks: VCL-OpenGL
  Show dependency treegraph
 
Reported: 2016-01-16 22:12 UTC by V Stuart Foote
Modified: 2016-10-25 19:08 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Attachments
sample file that triggers this. (11.39 KB, application/vnd.oasis.opendocument.presentation)
2016-02-10 20:33 UTC, Michael Meeks
Details
seems like we're missing some setContext's ... (2.19 KB, patch)
2016-02-10 20:45 UTC, Michael Meeks
Details

Note You need to log in before you can comment on or make changes to this bug.
Description V Stuart Foote 2016-01-16 22:12:29 UTC
On Windows 10 Pro 64-bit en-US
with OpenGL enabled on
Version: 5.1.0.2 (x64)
Build ID: ecd3574d51754b043f865cf5bafee286d24db7cc
CPU Threads: 8; OS Version: Windows 6.19; UI Render: GL; 
Locale: en-US (en_US)

An Impress presentation open in edit mode, and slide transitions deck active in SideBar. Choosing the Rochade transition effect displays the effect but at the end of the preview--the entire UI goes white. Unable to recover. Buttons of the close dialog also are blanked but are exposed on mouse over.

And, on this system with OpenGL disabled, in edit mode the slide transitions do render.

Likely related, on this two monitor system with OpenGL active when launching slideshow, LO will go inactive while partially bringing up the first slide--before the presentation console is rendered--the OS will report it unresponsive and close it.

With OpenGL disabled the slideshow and the presenter console render.

=-=-=
opengl_device.log

DriverVersion: 10.18.13.5850
DriverDate: 10-2-2015
DeviceID: PCI\VEN_10DE&DEV_1380&SUBSYS_37553842&REV_A2
AdapterVendorID: 0x10de
AdapterDeviceID: 0x1380
AdapterSubsysID: 0x37553842
DeviceKey: System\CurrentControlSet\Control\Video\{8BE1DBA2-2F4C-4D35-826E-7753ABC13F6A}\0000
DeviceString: NVIDIA GeForce GTX 750 TI
Comment 1 V Stuart Foote 2016-01-16 22:23:01 UTC
@Michael M., *

Not sure which OpenGL meta this belonged in-- bug 93529, or the more generic bug 94691

Darn, thought we were past all this with the slide transitions, sorry.
Comment 2 V Stuart Foote 2016-01-17 00:31:33 UTC
On same system Windows 10 Pro 64-bit en-US with recent 32-bit master
Version: 5.2.0.0.alpha0+
Build ID: c71b5b4d2ec76c0a204f9515dece1e0e0689ce3c
CPU Threads: 8; OS Version: Windows 6.19; UI Render: GL; 
TinderBox: Win-x86@39, Branch:master, Time: 2016-01-13_00:15:52
Locale: en-US (en_US)

In edit mode with OpenGL active the Rochade transition displays, but rather than white LO's window changes color with any mouse movement. Force close the window opens the save document dialog, different color and the cancel, don't save, save buttons are exposed on mouse over.

Continue issue of slide presenter console going non responsive on partial display of initial slide. Using the MozTrap 5.1.0 test case #40 document

http://manual-test.libreoffice.org/media/attachments/2014/05/24/test40.odp

=-=-=
DriverVersion: 10.18.13.5850
DriverDate: 10-2-2015
DeviceID: PCI\VEN_10DE&DEV_1380&SUBSYS_37553842&REV_A2
AdapterVendorID: 0x10de
AdapterDeviceID: 0x1380
AdapterSubsysID: 0x37553842
DeviceKey: System\CurrentControlSet\Control\Video\{8BE1DBA2-2F4C-4D35-826E-7753ABC13F6A}\0000
DeviceString: NVIDIA GeForce GTX 750 Ti
Comment 3 V Stuart Foote 2016-01-17 00:48:43 UTC
Working the recent master ( c71b5b4d2ec76c0a204f9515dece1e0e0689ce3c / 2016-01-13 TB39)
 
Had changed transition of initial slide of the presentation to Fade -> Through Black rather than Fade -> Smooth of the original test40.odp -- when I changed it back (or used the original)--the presentation stopped hanging on launch and presenter console came up.  

But still affecting 5.1.0.2 ( ecd3574d51754b043f865cf5bafee286d24db7cc )
Comment 4 Tor Lillqvist 2016-01-20 13:20:44 UTC
Can't reproduce with build from current 5.1 tree, on an AMD A10-7800 (Radeon R7).
Comment 5 Michael Meeks 2016-02-10 00:58:12 UTC
I saw something like this recently while chasing memory corruption issues =) my hope is that fixing tdf#97700 may improve things all over the show wrt. OpenGL reliability =) would love a re-test with 5.1.1 RC1 (due later this week); or a build with the 2x 97700 commits in it.

Thanks ! =)
Comment 6 V Stuart Foote 2016-02-10 05:14:48 UTC
On Windows 10 Pro 64-bit en-US with driver as above and
Version: 5.2.0.0.alpha0+
Build ID: fea95da81260bc7eabe7ece595829009b2db3e62
CPU Threads: 8; OS Version: Windows 6.19; UI Render: GL; 
TinderBox: Win-x86@39, Branch:master, Time: 2016-02-10_00:46:54
Locale: en-US (en_US)

Sorry Michael! Despite your work on bug 97770, continue to have OpenGL glitch in the Rochade transition as in comment 2.

Cloph's TB62 for 5.1 is a bit sporadic, so may have to wait for the RC to roll to check there--but suspect there is still something going on.
Comment 7 Michael Meeks 2016-02-10 20:14:34 UTC
So - Emmanuel and I can reproduce this now even with the latest builds; and I have an api-trace =)
Comment 8 Michael Meeks 2016-02-10 20:33:56 UTC
Created attachment 122510 [details]
sample file that triggers this.

Press F5, then escape -> bingo =)
Comment 9 Michael Meeks 2016-02-10 20:34:58 UTC
This guy:

--- a/vcl/opengl/gdiimpl.cxx
+++ b/vcl/opengl/gdiimpl.cxx
@@ -2042,6 +2042,13 @@ void OpenGLSalGraphicsImpl::doFlush()
 
     VCL_GL_INFO( "flushAndSwap" );
 
+    if( mpWindowContext.is() )
+    {
+        SAL_DEBUG("wiping window context");
+        mpWindowContext->reset();
+        mpWindowContext.clear();
+    }
+
     if( !mpWindowContext.is() )
     {
         // ensure everything is released from the old context.

Avoids the problem.

So - somehow, the GL code must be abusing the VCL GL context associated with the window, instead of using its own separate context; not good.
Comment 10 Michael Meeks 2016-02-10 20:45:40 UTC
Created attachment 122511 [details]
seems like we're missing some setContext's ...
Comment 11 Michael Meeks 2016-02-11 17:23:13 UTC
Thanks for the report - turned out to be a silly one =)
Comment 12 Commit Notification 2016-02-11 17:23:38 UTC
Michael Meeks committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=8973bc02fd9b7f72db9c942e0fbd3a8b156cb53b

tdf#97197 - GL transitions should use their context not VCL's.

It will be available in 5.2.0.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 13 Commit Notification 2016-02-11 19:21:59 UTC
Michael Meeks committed a patch related to this issue.
It has been pushed to "libreoffice-5-1":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=a00e445565d0cd92b32aef2bca33d054b8da1e45&h=libreoffice-5-1

tdf#97197 - GL transitions should use their context not VCL's.

It will be available in 5.1.2.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 14 Commit Notification 2016-02-20 12:56:09 UTC
Michael Meeks committed a patch related to this issue.
It has been pushed to "libreoffice-5-1-1":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=8dd8bee8059da1243b20b47349fcd20ebf93df8a&h=libreoffice-5-1-1

tdf#97197 - GL transitions should use their context not VCL's.

It will be available in 5.1.1.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.