#46 Stuttering GUI after mouse hovering over the seekbar (NO PLAYBACK + PREVIEW OFF)

[Templayer]

1. Video is not playing. (i.e. the issue itself indeed isn't caused by the playback itself. I just tested it, and as long as I do not cross the seekbar, pausing the playback doesn't trigger GUI "hiccuping")
2. I move the cursor from the video player area down to the subtitle list.
3. It is a quick movement, so the preview doesn't get even rendered. (EDIT: it also happens with the seekbar preview turned off...)
4. But the entire system GUI starts hiccuping. My mouse cursor starts skipping around when moved. Also, this extends to other applications - if I move my mouse cursor from the video player area down to the subtitle list while passing through the seekbar, while at the same time alt-tabbing to another application, its GUI will start "hiccuping" a bit for a moment too.

This issue occurs while the video is PAUSED AND NOT PLAYED AT ALL!!

Let me reiterate - while the video is PAUSED, moving the mouse across the seekbar while the preview feature is turned OFF causes the entire GUI (including my mouse cursor movement) to hiccup and stutter, becoming unresponsive.

It happens only with certain videos. I might provide a sample eventually. I would have done that already, if it wasn't for the reaction I got on the original Issue - https://sourceforge.net/p/subtitle-workshop-classic/tickets/36/

Just for the record - I can (and frequently do though videos downloaded from youtube) play 2K and 4K 60FPS videos just fine. I do have trouble playing 8K 60FPS videos (currently only MatPat has that on youtube, as he was granted that as an experiment from Youtube itself). But since this happens WITHOUT PLAYBACK, that is INCONSEQUENTIAL.

[Kameleon_]

moving the mouse across the seekbar while the preview feature is turned OFF causes the entire GUI (including my mouse cursor movement) to hiccup and stutter, becoming unresponsive.

Thanks vor the problem report (again).
Are yo sure that moving the mouse across the seekbar in conditions as you describe above causes the problem?
With "preview feature" I assume you do mean the "Seekbar Hovering" setting?
Thanks in advance.

[Templayer]

With "preview feature" I assume you do mean the "Seekbar Hovering" setting?

Yes.

Are yo sure that moving the mouse across the seekbar in conditions as you describe above causes the problem?

100% is the trigger. If I pause the playback (i.e. the video IS NOT PLAYING), wait a few seconds (while a "problematic" video is loaded - I will have to determine what causes that and make a sample), and then move the mouse cursour AROUND the seekbar, it works perfectly. But if I move the mouse cursor OVER the seekbar instead, the entire system GUI (main Windows thread) gets hogged for some reason.

I could record a video of it happening REPEATEDLY (I am pretty much used to workarounding this by going AROUND the seekbar with my mouse), but I had little time for the past last few weeks. But eventually, on a weekend, when I find another video that does that.

My theory is that there is some kind of action that is done while entering mouse hover over the seekbar (EVEN WITHOUT THE SEEKBAR PREVIEW FEATURE), and it collides with whatever is happening AFTER the playback is stopped. It might be the case of threads locking and waiting, which would be extremely bad if the system GUI thread had to wait for some kind of lock or synchronization.

[Kameleon_]

Clear. Thanks.

[Templayer]

Ran some more tests today, I do have new observations. And I have copied a 240MB video that can be used to duplicate the issue (it's in .webm), and it was placed on an SSD for my tests.

Further testing findings:

• The video has been paused for over half an hour, further proving that this has NOTHING to do with the hardware not being good enough for playback, as there hasn't been a playback event for half an hour. I.e. your statements in the closed issue were false.

• At first, it was happening sporadically when moving the mouse around the seekbar. I did manage to find why it wasn't triggering sometimes, and I can now trigger it 100% of time!

• To trigger it 100%, I have to move my mouse cursor from the player area (at first I thought it was due to the mouse cursor changing, but because there are black bars that do not trigger a mouse cursor icon change, and moving from there triggers it too, so I no longer think that is the case) to the seekbar, WAIT A SECOND on the seekbar with the cursor and then move it down to the buttons.

This seems to indicate that one of my original theories might be correct - upon mouse hovering over the seekbar, there is some code that gets executed even with the seekbar video preview turned off, and it contains the root cause of the problem. Probably.

Here's the video - to duplicate the issue, I recommend not using VLC (I do not have that piece of garbage even installed, so I cannot tell if it happens when using it for playback or not) with VMR9 playback - I do not know if this is a factor, but if we are to duplicate the issue on your end, we should make sure for everything to be as close to my setup as possible: https://mega.nz/file/BxRliK6a#LtDMvFqwI3UeGCeD5UEZKHu9otvNSyPpw8cPl0eNnK8

I recommend using a screen with a big frequency, but as low delay as possible - to be able to see and "feel" the mouse button becoming jittery. At that point, the system GUI thread becomes hogged for a brief moment, and inputs (such as clicking on the button) can be eaten.

I'm using a Samsung (using a 2K resolution of 2560x1440p) 240Hz screen, but it has a 5ms delay at 240Hz, so I have lowered it to 144Hz frequence in order to have a 1ms delay. It is even more evident when using cursorFX to replace the mouse cursor with a much bigger one, because that software technically hides the original cursor and has a graphic object follow it on the screen - when the system GUI gets hogged, it stops moving for a brief movement (i.e. I am moving my mouse, but the cursor gets "laggy", making it REALLY easy to see the problem)

If you fail to duplicate the issue, I can now record it on a video, perhaps even slow it down and show you exactly what is happening, but I might not have enough time on this weekend to that, it would have to wait until the next one.

If you copy paste in here the exact code that is being run on mouse hover over the seekbar while the preview is turned off, I might find another clue there.

[Kameleon_]

The video has been paused for over half an hour, further proving that this has NOTHING to do with the hardware not being good enough for playback, as there hasn't been a playback event for half an hour. I.e. your statements in the closed issue were false.

At first, it was happening sporadically when moving the mouse around the seekbar. I did manage to find why it wasn't triggering sometimes, and I can now trigger it 100% of time!

To trigger it 100%, I have to move my mouse cursor from the player area (at first I thought it was due to the mouse cursor changing, but because there are black bars that do not trigger a mouse cursor icon change, and moving from there triggers it too, so I no longer think that is the case) to the seekbar, WAIT A SECOND on the seekbar with the cursor and then move it down to the buttons.

Does this only happen if the video is paused (after playing) or also if the video is stopped after playing?

[Templayer]

Just tested it - it also happens after the video has completely stopped playback by being played until the end.

I did also try leaving it there for a while, it still happens.

Makes me really curious at what is happening at that moment the mouse hovers the seekbar even with the seekbar preview feature off. Could you please copy-paste all pertaining code to that event? I might be able to divine the reason out of it.

[Kameleon_]

Just tested it - it also happens after the video has completely stopped playback by being played until the end.

Aha. Thanks.

Hi, could you please do a test with attached version? All mouse events for the seekbar are completely disabled (except for the cursor change when the mouse is in the seekbar).
Thanks in advance.

Could you please copy-paste all pertaining code to that event? I might be able to divine the reason out of it.

I do not think it will make you any wiser, see attachment.

[Templayer]

Thank you, I'll test it once I get home from work.

The code seems straightforward. Or was. In my email notification, it is pretty much unformatted, and I read that one - the // added by adenry: Video thumbnail preview: is inside if SeekbarHoveringAllowed, which makes perfect sense.

But then you have edited the comment and replaced that text with an attachment. In the attachment, the // added by adenry: Video thumbnail preview: part is before the if SeekbarHoveringAllowed and would thus be called everytime even if the video preview feature is turned off. I assume this is a typo that was created when putting it into the txt file, because it doesn't make much sense.

Assuming my assumption is correct (hehe), the only problematic part could (based only on what I can see right now) the call to SetTimeCounter.

Is the sbSeekBarMouseMove event triggered per each pixel when the mouse moves above the seekbar? If that is the case, then a very specific problem might occur with resolutions higher than 1080p that do not do DPI upscaling. Which is my case (1440p, no scaling) - it would simply trigger to many times, and if it uses the GUI thread (which I assume the SetTimeCounter does...), then that could be the culprit. In theory. I do not know if a high Hz value would affect it as well.

If it was me trying to solve it, I would put a counter inside the SetTimeCounterfunction to see how many times it is called when the mose goes over it. And log it at the app exit. This way, we could compare numbers, and if mine is much higher then yours, then we have our culprit.

Alternatively, a profiler could be used, set to a hotkey, started before moving the mouse over, ended after, and then checked with function took what time and resources.

[Templayer]

I'm going to respond to myself. I know nothing of Delphi, but according to this: https://docwiki.embarcadero.com/Libraries/Athens/en/Vcl.Controls.TControl.MouseMove

the event is fired each time the coordinates change (at least. And if the mouse is above them, of course).

Does that mean that the amount of events (and GUI thread calls in this case) scales exponentially with the size of the coordinates? Or something akin to that? Because IF the coordinates are provided by Windows based on the number of pixels (or points based on the pixels and DPI the application uses), then having a bigger resolution with no DPI scaling could indeed be a problem.

[Kameleon_]

I'm going to respond to myself. I know nothing of Delphi, but according to this: https://docwiki.embarcadero.com/Libraries/Athens/en/Vcl.Controls.TControl.MouseMove the event is fired each time the coordinates change (at least. And if the mouse is above them, of course).

Yes. But I tought the problems occur when the mouse is below the seelbar (after hovering over it).

[Kameleon_]

Assuming my assumption is correct (hehe), the only problematic part could (based only on what I can see right now) the call to SetTimeCounter.

Indeed, but SetTimeCounter is a very small routine, see attachment, and it is only called when the mouse is moved and the left shift button is pressed, so I did not suspect that part.

[Templayer]

Yes. But I tought the problems occur when the mouse is below the seelbar (after hovering over it).

Yes, but the mouse is NOT held immobile until the event finishes its function. If hundreds of events are dispatched in the time span of a fraction of a second, and the GUI thread is hogged (for whatever reason we are currently trying to uncover) as a result, by the time the GUI thread is hogged the mouse may no longer be above the seekbar. The mouse movement is not stopped by the events not finishing their processing.

and the left shift button is pressed

Ah, that puts a wrench in my theory. Hmm. Well, the shift state still needs to be determined, and at a low level, that is the i/o thread, right?

The theory of event spamming is still plausible. Who knows what happens when the app is not capable of handling an event (I don't). Probably a queue of some sorts?

It would at least explain why only I had the issue - because pretty much nobody uses high resolutions (2K+) without DPI upscaling, thus nobody probably ever had as many coordinate values on which the events are triggered, thus nobody probably got as many event triggers as I do.

But if this is the case, it may eventually lead to a scaling problem for everybody. The bigger the resolutions with a lower needed DPI threshold (new screens + new operating systems, etc.) may lead to the application being more and more stuttery. What is happening to me without DPI upscaling could happen to somebody with an 8k display at 150% or 200% base DPI. This may slowly make the application unusable in the (possibly far) future.

Hi, could you please do a test with attached version? All mouse events for the seekbar are completely disabled (except for the cursor change when the mouse is in the seekbar).
Thanks in advance.

IT NO LONGER HAPPENS. One step closer. I couldn't click anywhere on the seekbar (d'oh), so I just clicked on play to get it to somewhere that wasn't the very start of the video. The GUI is now perfectly fluid while hovering over the seekbar!

I'm already thinking of various ways to solve it, but we need to confirm the exact cause first. One would be an atomic operation, but that would only work if the problematic part was something INSIDE the function that is called on the event, not by spamming events. Another, more tedious solution would be to put overlay objects as rectangles in front of the seekbar and set the event dispatch on them (but as ON MOUSE ENTRY or whatever that event type is called). Each rectangle would have the height of the seekbar, but the width given by a configured width (in the settings). The default would be one point (i.e. one pixel with DPI taken into account. At 100%, it would be exactly one point. If not set, the default should be as it is now -> one pixel × DPI%). For me, setting it to 10 could alleviate the problem. The app would have to create those rectangles at start, do the math on how many there have to be (with the last one being cut off if the division isn't exact), create them, place them and hook the event on the app startup and during resize events. This is a hacky solution that should only be used if a better one is not found. But that is only if the event spamming theory is correct.

[Templayer]

Also, I just checked the original version, and it also happens if I cross the seekbar from below, or from the tiny bits on the left and right. The same thing happens too.

WAIT.

I FOUND SOMETHING.

If I KEEP my mouse INSIDE the seekbar, moving it left to right and vice versa doesn't cause the issue.

MOVING the mouse INSIDE the seekbar doesn't cause it either.

It is only caused if the mouse LEAVES the seekbar. And it doesn't matter which way, so it is not based on entry onto other elements (unless all elements around have the same on mouse entry event trigger).

Is there an event for the mouse leaving the seekbar that I do not know about? :>

[Kameleon_]

Also, I just checked the original version,
It is only caused if the mouse LEAVES the seekbar. And it doesn't matter which way, so it is not based on entry onto other elements (unless all elements around have the same on mouse entry event trigger).

Does this problem also occurs in the last test version I sent you or only in the original version?

Is there an event for the mouse leaving the seekbar that I do not know about? :>

Of course there are things..., see attachment.
In the original 6.3.2 version the line indicated with the arrow was not present, but I do not think that could be the problem.

Additionally attached a version (#13) where seekbar mouse events are enabled again and the indicated line in the seekbar mouse leave event is present...

[Templayer]

Does this problem also occurs in the last test version I sent you or only in the original version?

In the newest one you have originally send with the events disabled the issue doesn't occur at all.

In all the previous versions, it is like I said - I just didn't have an exact way of telling what kind of event that is until I have managed to get it 100% duplicable. It has been the on mouse leaving event all along, it seems like.

Weird. There is almost nothing in that leave event.

The only thing that could cause it is SeekbarEntered := false;

Could you send me two exe files - one with SeekbarEntered := false; commented out, and one with the entire if SeekbarHoveringAllowed then block commented out? If one causes the issue and the other does not, we will be closer. Unless it is caused by the event being triggered.

[Templayer]

And also a third one - with ONLY the on seekbar mouse leave event disabled.

So we can be sure of it is caused by that event and not something else entirely.

[Kameleon_]

Could you please do a test with attached testversion #14?

In the mean time a lot of things have been changed by me (.e.g. I do not need any longer the variable 'SeekbarEntered' because I can see if a special timer is running (which it only does when the seekbar is entered...). That special timer is necessary as with a quick mouse move over the seekbar the MouseLeave event might not be triggered.

Also attached all seekbar mouse related events...

Thanks for all effort you put in to find the cause of this problem!

[Templayer]

With the exe file you have attached, the issue no longer occurs!

YAY.

Well, this has been a rabbit hole of epic proportions.

Can I keep using that exe for now? Is there something I should know before using it in "production"? (don't know the non-corporate jargon for that :D )

[Templayer]

I'll reply to myself - the version attached is broken for translations. The translation subtitles simply attach themselves to the first original subtitle they can.

I.e. if there are original subtitles that do not have a translation, and then translations that do not have original subtitles, they are squished together and timings are lost on the translations (I assume.)

[Kameleon_]

This is (probably) due to the change of leaving out the '-Untranslated subtitle' text. If the option 'Save empty lines' is off then now the untranslated subtitles are not saved any more and all translations crop up at the beginning...

I wll correct this asap.

[Templayer]

Yeah.

The use-case scenario for this is relatively simple.

If I have a video where I am doing a voice commentary over it in one language, but there is a non-commentary voice over there already in another language, then I have to create translations for each (translation 1 ends up in the original subtitles and translation 2 becomes the translation subtitles). And because I greatly dislike talking over another voice, this usually results in subtitles that are "zigzagging" between original subtitles that have no translation, and translations that have no original subtitles.

It would be also very nice to support multiple translations, and not just one, but that is probably something for the far future.

Right now I would much more prefer a new feature of both the original and translated subtitle to show in the video playback (with some kind of divider between them). Currently I have to CTRL+X the text in the translation, CTRL+V into the original subtitle, look at the preview and then hit CTRL+Z twice just to check if the translation works properly. That is also a reason why the translations for me are usually in English - no pesky unicode symbols to check... most of the time. If you are willing to implement both orig. subtitle and translation to be shown in the video playback, you could make a ticket for it so we can track that.

[Templayer]

This is (probably) due to the change of leaving out the '-Untranslated subtitle' text. If the option 'Save empty lines' is off then now the untranslated subtitles are not saved any more and all translations crop up at the beginning...

Oh, one more thing just we are clear.

The previous version I am using already doesn't save empty subtitles, and I do have plenty of empty original subtitles and translation subtitles.

I do not wish for empty subtitles to be saved. What the previous version did correctly was that it connected the subtitles to their correct times, whereas the new test version does not and so subtitles are timed in the seventh minute of the video suddenly are set to fire in the first minute, because there were empty spots in the list and it moved upwards in order to fill all the translation "slots".

[Kameleon_]

The previous version I am using already doesn't save empty subtitles, and I do have plenty of empty original subtitles and translation subtitles.

I do not wish for empty subtitles to be saved. What the previous version did correctly was that it connected the subtitles to their correct times, whereas the new test version does not and so subtitles are timed in the seventh minute of the video suddenly are set to fire in the first minute, because there were empty spots in the list and it moved upwards in order to fill all the translation "slots".

Yes. In fact the translations saved with v6.3.3 are not read correctly any more with 6.3.2. The other way around is Ok: translations saved under v6.3.2 can be read (without problem of synchronisation) by v6.3.3.
Is it possible that you tried to read newly saved translations (v6.3.3) with old software (6.3.2)?

[Kameleon_]

I do not wish for empty subtitles to be saved.

What the previous version did correctly was that it connected the subtitles to their correct times, whereas the new test version does not and so subtitles are timed in the seventh minute of the video suddenly are set to fire in the first minute, because there were empty spots in the list and it moved upwards in order to fill all the translation "slots".

In translated files there were previously no empty subtitles because of the text "-untranslated Subtitle-" was inserted in th empty ones.
This was done irrespective of the "save empty lines" setting. This automatically keeps the translated text in sync with the original text.
In the version #14 this was not done any more (no more "untranslated subtitle" texts) and those empty translated subtitles were of course not saved when "save empty lines" was off.

Attached a new version (#15) without the sync problems: in translatormode the saving always is done with empty subtitles, also irrespective of the "save empty lines" setting.

Thanks for all the testing!

[Templayer]

Yes. In fact the translations saved with v6.3.3 are not read correctly any more with 6.3.2. The other way around is Ok: translations saved under v6.3.2 can be read (without problem of synchronisation) by v6.3.3.
Is it possible that you tried to read newly saved translations (v6.3.3) with old software (6.3.2)?

No, the problem arose from loading subtitles made in an older v6.3.3 preliminary version into a newer one.