There were two problems here:
1) The OpenGLContext ctor registered the instance on the list of
contexts, but platform-specific call (e.g. wglMakeCurrent()) was only
made later. Add a registerAsCurrent() member function that helps
ensuring that the last item in the context list is indeed the current
context.
2) OpenGLContext::prepareForYield() is called without the solar mutex
being locked, but it still assumes that the last context in the context
list is the thread's current context, which may not be true. The result
is that during JunitTest_sd_unoapi, we end up in a situation like:
debug:4640:5240: OpenGLContext::registerAsCurrent: wglGetCurrentContext() is 00010001, pSVData->maGDIData.mpLastContext is 00FA65F8
debug:4640:7944: OpenGLContext::registerAsCurrent: wglGetCurrentContext() is 000D0003, pSVData->maGDIData.mpLastContext is 00FA6C70
debug:4640:5240: OpenGLContext::prepareForYield: start, wglGetCurrentContext() is 00010001, pSVData->maGDIData.mpLastContext is 00FA6C70
I.e. one thread registers as current, an other registers as current, too (while
the other thread has the solar mutex), then once the original thread wants to
release the solar mutex, the real current context and the last item in the
context list won't match, so the assert at the end of prepareForYield() will
fail.
Fix this by releasing the GL context in WinSalInstance::DestroyFrame().
With this, JunitTest_sd_unoapi passes on Windows with GL enabled.
Change-Id: Icfb9c65c871586b5df69b5a2ab3aa91843dfc799
Reviewed-on: https://gerrit.libreoffice.org/18473
Reviewed-by: Michael Meeks <michael.meeks@collabora.com>
Tested-by: Michael Meeks <michael.meeks@collabora.com>
Previously we would get an explicit ~OpenGLContext - and potentially
leave FMR's around for other OGC users, now we treat the other users
properly - we need an explicit dispose() to get Window::dispose ordering
right.
Change-Id: I5edcbd73399b6db3dbcfb391570f364f9ab0c70d
Reviewed-on: https://gerrit.libreoffice.org/18412
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Markus Mohrhard <markus.mohrhard@googlemail.com>
Don't use rtl::Reference for the global / list state, so the
ref-count reflects the number of real users.
Hold a reference during ~OpenGLContext.
Change-Id: I4e57a7246159acd58ae7d5a0dfc8704b9795c894
There are even more and it is causing a number of performance issues.
This just fixes the most obvious place.
Change-Id: Id85c13b5b7f4bb0bc077e62c39258067e17c0094
Fixes regression from otherwise a nice cleanup in:
d20092259c
Also get polarity of debug logging only with a context right.
Change-Id: Id322471f01e5656e758aefc57b0d4d5ad073ec54
This reverts commit 6fd7199230. Kendy says the
original problem can't be reproduced anymore, and most unexpected flickering
goes away with this for my nvidia card.
Also, it's a good idea in general to keep PFD_DOUBLEBUFFER and
WGL_DOUBLE_BUFFER_ARB in sync, which is now the case.
Change-Id: I7a809d1c85be4206c01720d5de9b0a5617a59c87
Annotate when we are in an OpenGL rendering zone.
Check for this in the VCL signal handler, and force OpenGL off here
if exception occurred inside an OpenGL code-path.
Change-Id: I85a4b3d4a374593dc55d01a39ec4c7c3c262c332
Reviewed-on: https://gerrit.libreoffice.org/17881
Reviewed-by: Michael Meeks <michael.meeks@collabora.com>
Tested-by: Michael Meeks <michael.meeks@collabora.com>
At least with my AMD card, in case of SAL_FORCEGL=1 the startup crashes
quite early. DrMemory says:
~~Dr.M~~ Error #1: UNADDRESSABLE ACCESS: writing 0x00001414-0x00001415 1 byte(s)
~~Dr.M~~ # 0 atioglxx.dll!DrvPresentBuffers +0xd6ea6 (0x09a248f6 <atioglxx.dll+0x1248f6>)
~~Dr.M~~ # 1 atioglxx.dll!DrvPresentBuffers +0x3c069c (0x09d0e0ed <atioglxx.dll+0x40e0ed>)
~~Dr.M~~ # 2 vcllo.dll!OpenGLContext::InitGLEW [c:\lo\master\vcl\source\opengl\openglcontext.cxx:949]
~~Dr.M~~ # 3 vcllo.dll!OpenGLContext::ImplInit [c:\lo\master\vcl\source\opengl\openglcontext.cxx:866]
~~Dr.M~~ # 4 vcllo.dll!OpenGLContext::init [c:\lo\master\vcl\source\opengl\openglcontext.cxx:786]
~~Dr.M~~ # 5 vcllo.dll!WinOpenGLSalGraphicsImpl::CreateWinContext [c:\lo\master\vcl\opengl\win\gdiimpl.cxx:36]
Turns out that in order to enable the GL_DEBUG_OUTPUT_SYNCHRONOUS_ARB
extension, the GL context must be created with WGL_CONTEXT_DEBUG_BIT_ARB
set. It seems that other drivers did not enforce this so far, but in
this case the driver just crashes without this.
Fix the problem by splitting out the debug setup part of InitGLEW() into
a new InitGLEWDebugging(), and at least on Windows call it only after
wglCreateContextAttribsARB() and wglMakeCurrent(). Additionally make
sure that in the debug case the necessary flag is passed to
wglCreateContextAttribsARB().
Change-Id: I6b77e0c06fd85fdae0386a0801f1de1838524586
Reviewed-on: https://gerrit.libreoffice.org/17750
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Miklos Vajna <vmiklos@collabora.co.uk>
This may reduce some degree of dependency on boost.
Done by running a script like:
git grep -l '#include *.boost/scoped_array.hpp.' \
| xargs sed -i -e 's@#include *.boost/scoped_array.hpp.@#include <memory>@'
git grep -l '\(boost::\)\?scoped_array<\([^<>]*\)>' \
| xargs sed -i -e 's/\(boost::\)\?scoped_array<\([^<>]*\)>/std::unique_ptr<\2[]>/'
... and then killing duplicate or unnecessary includes,
while changing manually
m_xOutlineStylesCandidates in xmloff/source/text/txtimp.cxx,
extensions/source/ole/unoconversionutilities.hxx, and
extensions/source/ole/oleobjw.cxx.
Change-Id: I3955ed3ad99b94499a7bd0e6e3a09078771f9bfd
Reviewed-on: https://gerrit.libreoffice.org/16289
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
For each iteration of the (gtk) main loop we are dropping the yield
mutext which results in calling OpenGLContext::clearCurrent. That method
calls OpenGLContext::ReleaseFramebuffers which would call in the end
glBindFramebuffer for each framebuffer related to that context.
This would easily grow into the thousand OpenGL calls without doing any
work.
Change-Id: I209cc534fe58a5e11ef7df7f850a787916b8bd43
Reviewed-on: https://gerrit.libreoffice.org/16241
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Markus Mohrhard <markus.mohrhard@googlemail.com>
Tested-by: Markus Mohrhard <markus.mohrhard@googlemail.com>
