Window not repainted after navigation

[ajschult]

Using up/down to navigate through keyframes, I notice that I seem to get different frames going backward vs. forward (this happens with every video I've tried).  Testing more, I realize that the window is not repainted after navigation.  It's painted before, so the frame I see is the frame I used to be at.  I can verify this by switching windows and then back to force it to paint.

Going through the revisions in git, I see that b6bf31c is the last version that worked and 90eb859 is the first broken version.  Builds between those crash or fail to build.  The code changes are only white-space, string and update changes, so I don't know what actually caused the trouble.

[ajschult]

Further investigation reveals that this is related to the display driver.

fails: VDPAU, LIBVA
works: X11, XVideo, openGL

My inability to see the problem with git revision b6bf31c appears to be pref-related.  After messing with the prefs, I'm able to see the problem with b6bf31c.

[eumagga0x2a]

Unless I miss something, I can't reproduce with VDPAU output and decoding with the current git + http://avidemux.org/smif/index.php/topic,17181.msg77305.html#msg77305.

[eumagga0x2a]

Does http://avidemux.org/smif/index.php?topic=17181.msg77341#msg77341 make any difference?

[ajschult]

Yes, that patch fixes it for me.

[eumagga0x2a]

Thank you, does it fix also video not going back to the beginning when dragging the slider fully back to the left for you?

If the CPU in your computer has at least 4 cores, does setting the affinity of the avidemux3_qt5 process just to one or two of them, e.g.

Code Select Expand

taskset -c 0,1 avidemux3_qt5

for the first two cores (not sure if this would work at all) have any influence on the redraw issue of an unpatched Avidemux?

[ajschult]

Thank you, does it fix also video not going back to the beginning when dragging the slider fully back to the left for you?

I don't see that consistently without the patch.  When I do see it, the window does repaint when I release the mouse button.  With the patch applied, it works consistently.

If the CPU in your computer has at least 4 cores, does setting the affinity of the avidemux3_qt5 process just to one or two of them, e.g.

Code Select Expand

taskset -c 0,1 avidemux3_qt5

for the first two cores (not sure if this would work at all) have any influence on the redraw issue of an unpatched Avidemux?

Invoking avidemux that way, the window never repaints without the patch.  Even the time display does not update.