sikuli-driver team mailing list archive

[RaiMan <rmhdevelop@xxxxxx>]

** Summary changed:

- [feature request] control over how rapidly / when the screen is sampled 
+ [request] control over how rapidly / when the screen is sampled

-- 
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?