Return mouse co-ordinates with WaitScreenImage

[craige288]

Not sure if I'm correct but it appears that the WaitScreenImage function is extremely fast compared to the FindImagePos function but both appear to perform the same function of finding an image on the screen.

WaitScreenImage seems to access video memory directly to find the image but you need to save a screen-shot to hard drive before FindImagePos can return mouse co-ordinates.

This slows the FindImagePos function noticably & I don't see why it can't use the same method of accessing video memory directly like WaitScreenImage seems to do.

The ideal solution would be to eliminate the FindImagePos function all together & allow the WaitScreenImage function to return mouse co-ordinates.

I know for a fact that some of my scripts would run far quicker if they didn't have to wait for an image & then perform the same function, utilising the slowest component of my system, to return the mouse co-ordinates.

It's a case of 1 line is better than 2 ! Especially when the 2nd line is retarded !

[jpuziano]

Hi Marcus,

I'd be interested in your reply to this one... thanks.

[Marcus Tettmar]

I'm not quite sure what to make of it actually because both WaitScreenImage and FindImagePos use the same techniques internally. WaitScreenImage is basically just a wrapper for a FindImagePos loop. In fact if you create your own loop with FindImagePos you can control the rate of iteration and the area of screen to scan so the FindImagePos would be faster.

WaitScreenImage is designed to do exactly what it says - wait for an image on the screen. FindImagePos will do more, and will return the found locations, as well as let you define the area of the source image to scan.

So if you want more control, want to wait for an image, and return it's position when found, use FindImagePos in a loop. It's pretty straightforward:

Code: Select all

Label>FindLoop
  ScreenCapture>...
  FindImagePos>....
  Wait>0.3
  If>imgs_found=0,FindLoop

I might add that if WaitScreenImage were to return found positions then it would become a more complicated function and would need three more parms - an X array, a Y array and a number found variable. So I don't see the benefit of making an existing function more complicated, when this can be done already with FindImagePos.

[craige288]

Hi Marcus,

My main point is why can't FindImagePos access video memory directly instead of having to save a screenimage. It would appear WaitScreenImage has no problem using video memory & is noticably faster.

Defining a screen area to scan is not an option if you need to scan the entire screen to find what you are looking for. Reducing screen resolution obviously helps to speed the ScreenCapture & FindImagePos functions & will work quite quickly at 800x600 but starts to slow when using a resolution of 1024x768 or higher.

I just don't see the point in utilising the hard drive to perform this function.

For now I have setup a RAM disk to save the screen image file. This method seems to work nicely with a marked improvement in ScreenCapture & FindImagePos performance.

[craige288]

Also.... Any chance of adding a timeout funtion to WaitScreenImage so that script can handle image not appearing within specified time?

[Marcus Tettmar]

A timeout for WaitScreenImage is on the wish list. In the mean time create your own version of WaitScreenImage with FindImagePos in a loop and build in your own timeout. Performance improvements are always a priority for us, so expect improvements with each new version.

[Marcus Tettmar]

BTW - I have just checked the source code and in fact WaitScreenImage currently calls FindImagePos directly and is simply a wrapper. It works off a temporary .bmp file. So your hypothesis is wrong. Both methods are the same. But the improvement in performance you are seeing could be that as the code is at a lower level it is running faster (less delays from running in script etc).

However, as stated earlier, we intend to improve performance wherever possible, so will take all these suggestions into consideration during development.