Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
vo_opengl: fix blue screen issues and image stalls #3773
The logic seems to have been flipped around for some reason. (Judging by
The second check that was in gl_video_upload_image was removed because
By the way, as mentioned, I'm pretty sure that check for blend_subs etc. is redundant; because the only thing blended by the blend_video code path is stuff that's dependent on the video frame itself (i.e. actual subtitles, not OSD). The OSD always gets drawn at screen res at the end even with blend_subs enabled.
Since the only case where the video gets repeated is in the case where the same video frame gets shown twice, I can't imagine a scenario in which we'd need to flush the cache for subtitles.
But it could be that I'm misunderstanding the intent of that original check. (That said, whatever the intent was, it doesn't seem to be implemented correctly at any rate)
The upload isn't necessary in these cases, and that's why it was done this way. We actually want to try hard to avoid redundant uploads even in corner cases, because cover art mode is one big corner case (where reuploading might cause noticeable delays).
The thing is just that hardware decoding mode "unmaps" the textures after rendering, so trying to use the textures agains without re-"upload" will not work.
Probably true, since vo.c now resets the repeat flag properly on redraws. So feel free to drop that code. In theory it's still needed for frames which are very long: i.e. frames repeated for longer than an acceptable UI response delay - if all frames have repeat=true set, the subs would never be redrawn, even if things like changing subtitle position would require this. But you could argue that vo.c or the core should force redrawing by unsetting repeat once in a while. So feel free to remove this code.
Actually, forget the latter part. I think my discussion applies mostly to the behavior according to your interpretation. But the intention was actually completely different. This code was supposed to trigger always redrawing the frame it blend_subs is used - except when a frame is repeated. Repeated frames should still be cheap, because forcing subtitle redrawing would be expensive for not much gain. So I think the original condition in the code is correct, but it should have always set
I think we need to clarify something - what is the relationship between
When the user is watching a hypothetical low-FPS video and changes a subtitle setting, would the frame ID stay the same or be incremented? And what would happen to the
I think that maybe the intent was to use the frame ID to distinguish actual source pictures (a change of which would always trigger a redraw) and use the
In this case, I think that maybe
Either way, I guess that means we want to use a logic like this:
Also, I think mixing the question of whether or not a given setting changing requires a redraw or not into the
The logic is already somewhat separate, because the upload function checks the frame ID. It just happens that the upload function is also called on the redraw path.
Yes, many things are muddy, software is a mudbath.
The frame ID is essentially connected to the frame contents. If we were webdevs, we'd use a md5sum of the frame's bitmap data instead.
The repeat flag is essentially an older way to signal that the frame data didn't change. But it also can have other purposes, such as signaling that drawing an exact duplicate is ok. So the repeat flag isn't only about the frame contents, but also other things that could influence final output, like OSD.
Yes, except that the repeat flag is the opposite.
Yes, I'm not happy with those vo_frame flags. They all seem so specific and corner-caseish.