OK, here’s a thought. When editing preferences one of the things we do is rebuild the toolbar (as things like the tooltip language, grid settings, etc. may have changed). That results in a size-event on the window (wxWidgets doesn’t appear to know that the size will end up being the same). This results in an onPaint(), which is where we run into trouble.
Is it possible that the frame-buffer is somehow smaller than we’re trying to draw into because it hasn’t been updated yet or something? > On 12 Oct 2018, at 23:10, Jeff Young <[email protected]> wrote: > > I added a call to glCheckFramebufferStatusEXT(), and it returns > GL_FRAMEBUFFER_COMPLETE_EXT. So it sounds like > GL_INVALID_FRAMEBUFFER_OPERATION is returned under other conditions as well, > but what those are I haven’t the foggiest. > >> On 12 Oct 2018, at 22:29, Jeff Young <[email protected] >> <mailto:[email protected]>> wrote: >> >> So we no longer get a deadlock. But the application still crashes when it >> tries to display the error using DisplayError(). >> >> The error is GL_INVALID_FRAMEBUFFER_OPERATION. Wiki states this is: “Given >> when doing anything that would attempt to read from or write/render to a >> framebuffer that is not complete.” They have a whole section on what “not >> complete” means, but it’s all Greek to me. >> >> What sort of things might we do when updating the GAL display settings on >> two GAL canvasses that would leave an incomplete framebuffer? Any ideas on >> what else to check? >> >> Thanks, >> Jeff. >> >>> On 12 Oct 2018, at 22:21, Seth Hillbrand <[email protected] >>> <mailto:[email protected]>> wrote: >>> >>> Hi Jeff- >>> >>> Am Fr., 12. Okt. 2018 um 13:46 Uhr schrieb Jeff Young <[email protected] >>> <mailto:[email protected]>>: >>> That doesn’t work because the lock/unlock calls are in separate routines >>> (BeginDrawing() and EndDrawing()). >>> >>> Sorry, I was unclear. There are catches for OpenGL failures that do not >>> unlock the context if the error thrown is not std::runtime_error. I >>> believe that the locking conflict is triggered here where an error is >>> thrown all the way up to GAL, bypassing the unlock and leading to deadlock. >>> Adding a default catch that unlocks the context before re-throwing would >>> fix that >>> >>> That’s fundamentally unsafe, so I’m adding lockContext() and >>> unlockContext() protected methods to the GAL API and a GAL_CONTEXT_LOCKER >>> friend class that can be created on the stack. BeginDrawing() will ASSERT >>> that the context has indeed been locked. >>> >>> RAII locking is definitely the safest way to go. Lose the stack->lose the >>> lock. >>> >>> -S >> >> _______________________________________________ >> Mailing list: https://launchpad.net/~kicad-developers >> <https://launchpad.net/~kicad-developers> >> Post to : [email protected] >> <mailto:[email protected]> >> Unsubscribe : https://launchpad.net/~kicad-developers >> <https://launchpad.net/~kicad-developers> >> More help : https://help.launchpad.net/ListHelp >> <https://help.launchpad.net/ListHelp> > > _______________________________________________ > Mailing list: https://launchpad.net/~kicad-developers > Post to : [email protected] > Unsubscribe : https://launchpad.net/~kicad-developers > More help : https://help.launchpad.net/ListHelp
_______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
