kicad-developers team mailing list archive

[Jeff Young <jeff@xxxxxxxxx>]

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 <jeff@xxxxxxxxx> 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 <jeff@xxxxxxxxx <mailto:jeff@xxxxxxxxx>> 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 <seth@xxxxxxxxxxxxx <mailto:seth@xxxxxxxxxxxxx>> wrote:
>>> 
>>> Hi Jeff-
>>> 
>>> Am Fr., 12. Okt. 2018 um 13:46 Uhr schrieb Jeff Young <jeff@xxxxxxxxx <mailto:jeff@xxxxxxxxx>>:
>>> 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     : kicad-developers@xxxxxxxxxxxxxxxxxxx <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx>
>> 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     : kicad-developers@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp