Bug 93530 - menu non-rendering on click ...
Summary: menu non-rendering on click ...
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: graphics stack (show other bugs)
Version:
(earliest affected)
5.0.0.0.beta1
Hardware: Other All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard: target:5.1.0 target:5.0.2
Keywords:
Depends on:
Blocks: VCL-OpenGL
  Show dependency treegraph
 
Reported: 2015-08-19 12:37 UTC by Michael Meeks
Modified: 2016-10-25 19:24 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Michael Meeks 2015-08-19 12:37:51 UTC
if OpenGL is enabled SAL_FORCEGL=1 - then popup menus pop-up, but contain no rendered contents until a mouse-over event or somesuch other thing forces a render, this gives rather a poor visual effect =)
Comment 1 Michael Meeks 2015-08-26 15:33:19 UTC
Horrors - if I add an un-conditional 'glFlush()' to vcl/opengl/gdiimpl.cxx /PostDraw/ then this goes away - and we get things rendered properly - but at some hideous performance cost of course.

So - I assume that all is well with our rendering goodness, but the driver is queuing up work and not performing it in a rather unhelpful fashion =)

I imagine the 2nd popup of a menu produces enough work that it gets flushed out and actually shows up ;-)

Interestingly the SalFrame abstraction already has a 'flush' method; that does (on windows a GdiFlush) - and which ( I suspect ) we should get to do a glFlush() too when we are on a GL backend.

I imagine this is quite a reasonable analog for this:

https://msdn.microsoft.com/en-us/library/windows/desktop/dd144844(v=vs.85).aspx

already in use, and important for threading too.
Comment 2 Michael Meeks 2015-08-26 16:10:08 UTC
A start on this here:
    https://gerrit.libreoffice.org/18030

Clearly we're going to need to have some more 'Flush' events at the tail end of rendering; for the curious - we get a scad of these on startup (under windows) - as we render the progress bar (say 20) - but I guess that's a feature =)
Comment 3 Commit Notification 2015-08-26 21:11:00 UTC
Michael Meeks committed a patch related to this issue.
It has been pushed to "master":

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

tdf#93530 - the VCL GDI flushing abstraction should glFlush too.

It will be available in 5.1.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 4 Michael Meeks 2015-08-27 19:27:17 UTC
My start on this was (it seems) a big bogus; we don't really need to glFlush there at all =)

After adding glFlush's across the code, and binary chopping down to a single nonsensical data-point - I assume memory corruption / non-initialization instead. Reading:

https://www.opengl.org/wiki/Common_Mistakes#Swap_Buffers

It seems we badly need to glClear() our buffers before we begin rendering; I pushed a patch that does this and makes the menus work for me on click - and pleasant it is to see them too.

We should prolly also disable the Windows direct GDI calls that wipe this memory with direct FillRect() calls very early in their creation to avoid flicker & potential aggravation. Input appreciated.
Comment 5 Michael Meeks 2015-08-27 19:30:46 UTC
even more ideally, we should use glClearColor and avoid the Erase that is performed on each of these drawables as we start rendering to them.

cf. https://gerrit.libreoffice.org/18069
Comment 6 Commit Notification 2015-08-28 00:19:25 UTC
Michael Meeks committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=098f9189c603fe8b345d2e64f5579fd7f3e0ca05

tdf#93530 - glClear our depth, stencil and buffer contents on init.

It will be available in 5.1.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 7 Commit Notification 2015-08-28 06:56:40 UTC
Michael Meeks committed a patch related to this issue.
It has been pushed to "master":

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

Revert "tdf#93530 - the VCL GDI flushing abstraction should glFlush too."

It will be available in 5.1.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 8 Commit Notification 2015-09-01 07:25:26 UTC
Michael Meeks committed a patch related to this issue.
It has been pushed to "libreoffice-5-0":

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

tdf#93530 - glClear our depth, stencil and buffer contents on init.

It will be available in 5.0.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.