>> If so, then this violation might be caused by the fact that we >> (1) did resize windows according to the new sizes but (2) did not update >> the frame sizes accordingly. > > Can you elaborate on how this could be possible? I always thought we > first allocate the frame matrices, and then the window matrices (by > suballocating them from the frame matrices). Am I mistaken?
But if glyph_row_slice_p (window_row, frame_row) fails, something else must have invalidated that. I made that change here more than three years ago and I can neither remember whether an assertion violation made me do it or a crash nor why I did chose a term like "congruent" in the comment. One possibility I cannot exclude is that adjust_frame_size tries to resize windows, that step (silently) fails in window_resize_check, the old values stay in place but the new frame sizes are applied by adjust_frame_size. But precisely this scenario cannot be healed by my patch so it's unlikely that it was the cause for the problem I experienced back then. > Moving code in adjust_frame_glyphs could affect the assertion if the > assertion was being hit while adjust_frame_glyphs is still being > executed. But that is not the case, so I don't understand how moving > some code in adjust_frame_glyphs without changing it could affect the > assertion violation. I'm probably missing something. I'm still too dense to understand what "Moving code" and "moving some code" could mean in this context. If you have enough patience left, please elaborate. Thanks, martin
