sikuli-driver team mailing list archive
-
sikuli-driver team
-
Mailing list archive
-
Message #00338
[Bug 681065] Re: [request] control over how rapidly / when the screen is sampled
** Changed in: sikuli
Status: Fix Committed => Fix Released
--
You received this bug notification because you are a member of Sikuli
Drivers, which is subscribed to Sikuli.
https://bugs.launchpad.net/bugs/681065
Title:
[request] control over how rapidly / when the screen is sampled
Status in Sikuli:
Fix Released
Bug description:
It would be nice if some sort of control when or how rapidly the
screen is sampled would be exposed to the script (since taking
screenshots is expensive to the system, eg. leading to choppy
animations in some instances).
These i would like to see to have more control over the performance
impact of sikuli:
An option to dynamically (changeable by the script at runtime) set the minimum timespan between screencaptures.
Exposed as a property (eg. 'samplerate') to screen and region (with region inheriting from screen in case property is None there).
Idea is that observers, find, wait and waitVanish can be tuned to be
nicer to the system (or can react faster in case a low delay is set).
Second part of this is that screen captures can be made or reused on scripts demand.
Leading to script being in control if it wants to perform several operations on a single captured frame, or to request a new one.
So the signature of exists() should be extended with an optional
parameter: capture=None
Possible values for capture:
True: instant new screencapture for this operation.
False: reuse of last screenshot.
None: normal screen polling (= as it currently works), but modified by samplerate option above.
Related: https://answers.launchpad.net/sikuli/+question/132797
Any comments on this?