StrokesPlus Forum
                       
StrokesPlus Forum
Home | Profile | Register | Active Topics
Members | Search | FAQ
Username:
Password:
Save Password
Forgot your Password?

 All Forums
 Bug and Issues
 New Bugs
 Relay Gesture On No Match extremely slow
 New Topic  Reply to Topic
 Printer Friendly
Author Previous Topic Topic Next Topic  

Guillaume

14 Posts

Posted - 08/12/2017 :  13:30:07  Show Profile  Reply with Quote
I'm using the feature "Relay Gesture On No Match" for Firefox. I have only two gestures in S+ that I want to use when a Firefox window is active, otherwise it should relay everything to the FireGestures extension (which can do a couple of things that I can't just let StrokesPlus handle via some keyboard shortcuts).

Now, I made a special Application group for Firefox, enabled "Do not process Global Actions" and added the two gestures. Together with "Relay Gesture On No Match" it does work, but it's extremely slow: without S+ active, FireGestures responds to gestures instantly, and so does S+ in other apps. However, when the S+ gesture relay function kicks in, it takes about a whole second for Firefox to actually respond.

Is there a way to speed up the gesture relay behavior?

Edited by - Guillaume on 08/12/2017 13:32:33

Rob

USA
2415 Posts

Posted - 08/13/2017 :  18:55:10  Show Profile  Visit Rob's Homepage  Reply with Quote
I honestly have no idea why it would be so slow. The code doesn't really do much, and the Sleep commands are only 3ms/1ms to ensure there's a little bit of CPU cycles to process. Clearly there's something going on, but it's not something in the code which is intentionally delayed. The function call referenced have no delays in them at all and call the Windows API directly.

Does it behave any differently if the app group isn't set to only process global actions?

Are all other gestures through S+ nice and quick?
Go to Top of Page

Guillaume

14 Posts

Posted - 08/14/2017 :  05:44:44  Show Profile  Reply with Quote
Ok, this is odd, I started using a backup .xml and now there seemed no delay anymore. I hadn't changed a thing since this backup, but the xml files were different somehow. I am still experiencing that I almost always lose the settings in the "Preferences" tab whenever I change something (anywhere), so I have loads of xml backups now. After a restart, it looked like the delay was gone, but it turned up again after only a few gestures. It's even more than a second sometimes. I'm on an i7-6700 and no other programs were eating CPU cycles.

I have always thought this delay was there because of Firefox, but when I closed S+ the difference was immense.

Edited by - Guillaume on 08/14/2017 06:00:22
Go to Top of Page

Guillaume

14 Posts

Posted - 08/14/2017 :  17:31:25  Show Profile  Reply with Quote
I just learned that the bigger the gesture, i.e. the more pixels I use to draw the gesture, the longer the delay is. I can block the whole user interface for 4-5 seconds or so (no CPU spikes) by using the entire screen to draw the gesture.
Go to Top of Page

Guillaume

14 Posts

Posted - 08/14/2017 :  17:48:02  Show Profile  Reply with Quote
I tried another mouse that has a lower DPI and maybe a lower polling rate. The delay is half as long with that mouse, but still significant.
Go to Top of Page

Rob

USA
2415 Posts

Posted - 08/15/2017 :  06:53:58  Show Profile  Visit Rob's Homepage  Reply with Quote
Yes, that actually makes sense, well kind of...I still can't find a reason that it would be so slow as the loop which retraces the point pattern only has a 1ms sleep per point in the loop (which probably isn't needed, to be honest).

What do you have your Minimum Segment Length set to? That controls how far the mouse has to travel while the stroke button is down between recording each mouse point (coordinate). If it's set really low, the point array would be holding a lot of coordinates. Keep in mind that the entire gesture is interpolated (multiplied and smoothed out), so recognition would not be affected if you increase that, unless you have highly complex gestures which you're able to draw in a very tight cluster.

I wish I could reproduce the steps which cause the Preferences to be lost, but I simply cannot find any reason in the code as to how it could happen, and if I can't reproduce it, I'm kind of dead in the water.
Go to Top of Page

Rob

USA
2415 Posts

Posted - 08/15/2017 :  07:29:42  Show Profile  Visit Rob's Homepage  Reply with Quote
However, if you wouldn't mind, try only closing the S+ window (Actions/Preferences/etc) by clicking the OK button (or Cancel). Closing it by clicking the X (or via a gesture which sends the close window command) allows an odd type of functionality which, at the time, had a purpose...but it shouldn't have really been left in place.

Essentially, clicking the X to close the window leaves the S+ config in an odd state where basically the settings are only in memory, not committed to disk. So say you wanted to try out some gesture changes, but didn't want to save them for sure, and also didn't want to have the S+ window opened while you tested them, you could change the Lua, switch to a different action (with Auto Save checked), and it would save the action to memory, but not actually save the changes to disk.

If you came back in, the action would still be there as you put it, then you could click Apply or OK and it would be saved to disk.

Clicking Cancel always reloads the settings into memory from disk, whatever was last saved.

I wonder if there's a weird sequence of events where that functionality is allowing an unexpected code path to be followed and under certain circumstances, the Preferences node of the settings object is being erased or having its reference changed, or maybe the memory is being seen as unused by Windows or something.

When you close S+, it always performs a save to disk of the current settings.
Go to Top of Page

Rob

USA
2415 Posts

Posted - 08/15/2017 :  07:31:30  Show Profile  Visit Rob's Homepage  Reply with Quote
Actually, it might be clicking Apply, then closing with the X. I think Apply saves it to memory, and OK saves it to disk. So Apply then X would result this weird state.

But regardless of whether you do these certain sequences, just try only clicking OK to close the S+ window and see if the issue still happens.
Go to Top of Page

Guillaume

14 Posts

Posted - 08/15/2017 :  15:21:17  Show Profile  Reply with Quote
quote:
Originally posted by Rob

Yes, that actually makes sense, well kind of...I still can't find a reason that it would be so slow as the loop which retraces the point pattern only has a 1ms sleep per point in the loop (which probably isn't needed, to be honest).

What do you have your Minimum Segment Length set to? That controls how far the mouse has to travel while the stroke button is down between recording each mouse point (coordinate). If it's set really low, the point array would be holding a lot of coordinates. Keep in mind that the entire gesture is interpolated (multiplied and smoothed out), so recognition would not be affected if you increase that, unless you have highly complex gestures which you're able to draw in a very tight cluster.

I wish I could reproduce the steps which cause the Preferences to be lost, but I simply cannot find any reason in the code as to how it could happen, and if I can't reproduce it, I'm kind of dead in the water.



- The minimum segment length is 6px, which is the default value.
- During testing, I always compared with one of the simplest gestures: down, then left. The size of the gesture I draw is indeed directly proportional to the delay I observe.
- I have never used Apply, always OK, or Cancel.
- The idea that it has to do with only writing changes to memory doesn't seem to be directly related to the problem: whenever I experience this problem, the corruption of the Preferences tab is always written to disk: when I observe that the gestures are not registered anymore, a restart it doesn't bring back any of the options.

Edited by - Guillaume on 08/15/2017 15:33:48
Go to Top of Page

Rob

USA
2415 Posts

Posted - 08/15/2017 :  21:42:30  Show Profile  Visit Rob's Homepage  Reply with Quote
Out of curiosity, does it behave the same if you did it for another application? Just to see if it's the way it interacts with Firefox. Like Explorer would probably be a decent candidate, to relay the right-click drag function. Again, I don't use this, I only coded something up to address a request someone made (specifically for the use case you're describing, using Firefox).

I tested it, it worked.

But testing it, and actually using it on a regular basis are two very different things. A delay like that would probably drive me bat-shit crazy! So I certainly understand your reason for posting :)

Go to Top of Page

Rob

USA
2415 Posts

Posted - 08/15/2017 :  21:44:10  Show Profile  Visit Rob's Homepage  Reply with Quote
Also, have you tried bumping up the min segment length to find a tolerable point (in and out of Firefox)?

Not that I'm saying that's a "real" solution, but ya know...since I'm not in active development of S+ and all..
Go to Top of Page

Guillaume

14 Posts

Posted - 08/17/2017 :  06:28:14  Show Profile  Reply with Quote
I see the exact same behavior in Notepad when simply changing the class to Notepad for that Application group.

I've changed the min. segment length to 18 (default x3) and the response is indeed a lot better. Thank you!

Note: it's not like I have a QHD-monitor or anything, so the resolution, and thus density is (below?) average (1920x1080 on 24" monitor).

Edited by - Guillaume on 08/17/2017 06:30:13
Go to Top of Page
  Previous Topic Topic Next Topic  
 New Topic  Reply to Topic
 Printer Friendly
Jump To:
StrokesPlus Forum © 2011-2017 Rob Yapchanyk Go To Top Of Page
Snitz Forums 2000