Dreamed about getting fired after ending up assigned to the same guy who fired the lion kingdom, 20 years ago.  Wondered what the chances were of ending up under the same guy twice.  In reality, that guy became a multimillionaire at the Goog & probably retired long ago.  Interestingly, his early job titles ascended into management & then descended back to staff positions so it's unlikely lions would ever get fired by him again.

A lot of coworkers simply didn't want to go into management or moved up, discovered it wasn't worth it & got the hell down.  Paygrades & the standard of living have probably evolved to where going into management isn't necessary for having a pretty good life.

Then dreamed about reading about some guy who designed space suits for his entire career.  Pondered how much more influential that was than what the lion kingdom did.

---------------------------------------------------------------------------------------------------------

A new bug emerged whereby when switching between windows & full screen, the GL context changes & all the textures in 1 GL context don't exist in the other.  There are some VFrames which are persistent when switching between windowed & full screen.  

They only have a texture in 1 GL context.  They somehow need to get reset to opengl state RAM when the video output changes contexts.  

 

It seems the textures are specific to 1 pbuffer or screen.  The opengl state for a VFrame needs to be aware of what GL context is currently active.  If it doesn't match the GL context of the texture or screen, its state needs to be RAM.

It doesn't make a lot of sense, since previously it was possible to go from screen to texture in 1 frame, then go from the same texture to screen in another frame.  The textures might span pbuffers but not windows.  The windows have a gl_win_context.  The pbuffers have a gl_context.  glXMakeCurrent takes either argument. 

do_mask_sync first calls enable_opengl in the canvas, which makes the gl_win_context current.  Then it calls enable_opengl in the destination frame which makes gl_context current.  The destination frame is the same but it's gl_pointer changes when the window changes.  That invalidates all the textures.

There is a glBindFramebuffer which makes a pbuffer current without changing gl_context.  That reduces the problem to changing the gl_win_context.  Using different gl_win_contexts for different windows is required if multiple windows are going to show different videos.  It seems to require storing the current gl_context in the setting persistent frames to gl state RAM when their texture doesn't correspond to the current gl_context.

For now, the workaround is an additional test when calling VFrame::get_opengl_state().  It also needs to check if the VFrame's window ID matches the current window ID & reset the frame to RAM. Maybe get_opengl_state should take the current window_id as an argument to do the check itself.  It's not called in many places.

Helas, if the RAM doesn't reflect the contents in the previous texture or pbuffer, the RAM could also be invalid.  get_opengl_state isn't used in any plugins. 




Comments

Popular posts from this blog