This is clearly incorrect; not least because we then re-allocate a texture with the same handle and try to bind it to the same frame-buffer and get: void OpenGLFramebuffer::AttachTexture( const OpenGLTexture& rTexture ) { if( rTexture.Id() == mnAttachedTexture ) return; no binding, and then various unpleasant gl errors from trying to render to a FBO not bound to a valid texture such as GL_INVALID_FRAMEBUFFER_OPERATION ... which can't be good for the rendering stack.
Been poking at this. Added a nice DBG_UTIL assert as attached - and started to try to knobble a few of these. Amazingly working quite nicely on Linux / -5-0 but Windows/master asserts pretty quickly. More amazingly, unbinding the FBO in the ~GdiImpl then gives a number of 'black' areas which (I guess) are not setup right in the status bar. Odd.
Created attachment 118247 [details] assertion patch, with a potential workaround for 1x failure. I suspect that a more elegant way is to associate the texture and the framebuffer together with a mutual pointer so they can dis-associated each other on death etc. Of course - maintaining mutual pointers reliably is fun ;-)
Michael Meeks committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=18dd07ba4fd9ede98ce576e6024831658bbd5401 tdf#93751 - ensure textures are unbound from framebuffers post destroy. 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.
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=0a3cfc66d5c82e5c44ef5220bdbe4344b9d1e2ce&h=libreoffice-5-0 tdf#93751 - ensure textures are unbound from framebuffers post destroy. 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.