slider position displayed time

[Jan Gruuthuse]

most of the time, It goes wrong when mouse pointer goes of avidemux gui: seems to me.

[eumagga0x2a]

most of the time, It goes wrong when mouse pointer goes of avidemux gui: seems to me.

I'm very sorry, but I fail to follow you in this description. I'm pretty sure that the concept of the initial version of patch is correct. The redraw issue is probably a separate thing which misleadingly overlays this one. I still have no idea why you and ajschult experience the redraw problem and I can't, absolutely can't reproduce it on my system running gnome-shell.

[eumagga0x2a]

Just a wild guess, but could repeated doubled and tripled entries/calls to HandleAction like

Code Select Expand

[edCache] Flush
[canSupportThis]  Vdpau not enabled
  [canSupportThis]  LibVA not enabled
  [lookup]  No Matching Hw accel
  [ADM_FFgetFormat]  No Hw Accel for that
  [HandleAction]  ************ Scale **************
  [HandleAction]  ************ Scale **************
  [HandleAction]  ************ Scale **************
  [HandleAction_Navigate]  Scale :1407
  [HandleAction_Navigate]  Scale Time:1139726 ms (total=8100366 ms)
  [HandleAction_Navigate]  Scale Time:00:18:59,726 ms
  [HandleAction_Navigate]  Seeking to  Time:00:18:59,346 ms
  [DecodePictureUpToIntra]   DecodeUpToInta 56705 ref:0
[edCache] Flush


be related to (unwanted) multithreading? I currently fail to understand autolock in

Code Select Expand

  admScopedMutex autolock(&singleThread); // make sure only one thread at a time calls this

from [GUI] Use a scoped mutex to make sure the main event function is not called multiple concurrent time because in

Code Select Expand

class ADM_CORE6_EXPORT admScopedMutex
{
  private:
    admMutex       *_tex;
   
  public:
    admScopedMutex( admMutex *tex);
    ~admScopedMutex();       
    uint8_t lock(void);
    uint8_t unlock(void);
    uint8_t isLocked(void);
};

from ADM_threads.h there is nothing like autolock (but this should be just due to my deep ignorance). Does locking work or rather fail here? My CPU has only two cores, maybe this is the clue why I can't reproduce the redraw issue?

[Jan Gruuthuse]

tried to follow your thinking:
attached 2 files both with moving slider left to right, right to left.
- SliderDragLeftRight-RightLeft2cores set in preferences.
- SliderDragLeftRight-RightLeftMultithreadingLAVCthreadsDisabled in preferences.
both keep showing:

Code Select Expand

[edCache] Flush
[canSupportThis]  [b]Vdpau[/b] not enabled
  [canSupportThis]  [b]LibVA[/b] not enabled
  [lookup]  No Matching Hw accel
  [ADM_FFgetFormat]  No Hw Accel for that
  [HandleAction]  ************ Scale **************
  [HandleAction]  ************ Scale **************
  [HandleAction_Navigate]  Scale :356
  [HandleAction_Navigate]  Scale Time:191437 ms (total=5377305 ms)
  [HandleAction_Navigate]  Scale Time:00:03:11,437 ms
  [HandleAction_Navigate]  Seeking to  Time:00:03:10,975 ms
  [DecodePictureUpToIntra]   DecodeUpToInta 9428 ref:0

is

[HandleAction]  ************ Scale **************
[HandleAction]  ************ Scale **************

not the result from revisiting every time testing [canSupportThis]

[edCache] Flush
[canSupportThis]  Vdpau not enabled
  [canSupportThis]  LibVA not enabled

1st time you have:

Paint event
[refresh]  XV:refresh
  [HandleAction]  ************ Scale **************
  [HandleAction_Navigate]  Scale :71
  [HandleAction_Navigate]  Scale Time:38183 ms (total=5377305 ms)
  [HandleAction_Navigate]  Scale Time:00:00:38,183 ms
  [HandleAction_Navigate]  Seeking to  Time:00:00:37,935 ms
  [DecodePictureUpToIntra]   DecodeUpToInta 1776 ref:0

2nd time and follow ups:

[edCache] Flush
[canSupportThis]  Vdpau not enabled
  [canSupportThis]  LibVA not enabled
  [lookup]  No Matching Hw accel
  [ADM_FFgetFormat]  No Hw Accel for that
  [HandleAction]  ************ Scale **************
  [HandleAction]  ************ Scale **************

clash of found hardware?
Probably should test preference settings once with loaded video and see if that works with wanted setting and not with possible settings.
avidemux should not visit Vdpau nor LibVA, the hardware is there, the settings are not set to use one of these?

the system contains
- nvidia gpu
- 4 core intel cpu with hyperthreading and gpu

system is used for building avidemux deb and has present developer libraries for intel, amd and nvidia hardware.

my idea/deduction could be wrong.

[mean]

autolock, is made so that the lock is freed when exiting the function
i.e. when the destructor is called.

It is to avoid tracking every code path.

Qt events are normally only managed on one thread on linux, but no on windows if my memory is correct

*edit: typos

[eumagga0x2a]

Thank you very much for explaining the purpose. I still fail to understand where autolock is defined (to understand why this works at all), but I'll find this out on my own.

What do you think about multiple calls to ACT_Scale in the console output of Jan's Avidemux?

If Qt GUI is always running in a single thread, it is not the GUI which is causing issues like Window not repainted after navigation here. If putting admPreview::samePicture() all over the place works around the problem, maybe take this workaround now and investigate (which would be beyond my capabilities for sure) later?

Did you have a minute or two to look at the patch for ACT_Scale in http://avidemux.org/smif/index.php/topic,17181.msg77305.html#msg77305 or even to test it if you deem the logic to be correct?

[mean]

It looks like a double buffering problem
i.e. bufferA is updated but not displayed
If you call it a second time, bufferB is updated and bufferA is displayed, so it "looks" ok

I dont have much time atm, didnt look into that patch yet

I'd like to have the h264/h265 intel hw encoder to work to see how it fares

[Jan Gruuthuse]

just tested with160927_54.app, very confusing
no double:

Code Select Expand

[HandleAction]  ************ Scale **************

[mean]

It is made using debian Qt5, not ubuntu Qt5
Some settings are different

[eumagga0x2a]

I'm sorry, but if we're at it, would you add the patch in http://avidemux.org/smif/index.php/topic,17181.msg77305.html#msg77305 to the queue? That one was really difficult to narrow down

[mean]

done
I can't keep up

[eumagga0x2a]

Thank you very much! The redraw issues I'd prefer to address separately later.