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 !
Return mouse co-ordinates with WaitScreenImage
Moderators: Dorian (MJT support), JRL
Hi Marcus,
I'd be interested in your reply to this one... thanks.
I'd be interested in your reply to this one... thanks.
jpuziano
Note: If anyone else on the planet would find the following useful...
[Open] PlayWav command that plays from embedded script data
...then please add your thoughts/support at the above post -
Note: If anyone else on the planet would find the following useful...
[Open] PlayWav command that plays from embedded script data
...then please add your thoughts/support at the above post -
- Marcus Tettmar
- Site Admin
- Posts: 7386
- Joined: Thu Sep 19, 2002 3:00 pm
- Location: Dorset, UK
- Contact:
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:
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.
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
Marcus Tettmar
http://mjtnet.com/blog/ | http://twitter.com/marcustettmar
Did you know we are now offering affordable monthly subscriptions for Macro Scheduler Standard?
http://mjtnet.com/blog/ | http://twitter.com/marcustettmar
Did you know we are now offering affordable monthly subscriptions for Macro Scheduler Standard?
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.
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.
- Marcus Tettmar
- Site Admin
- Posts: 7386
- Joined: Thu Sep 19, 2002 3:00 pm
- Location: Dorset, UK
- Contact:
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
http://mjtnet.com/blog/ | http://twitter.com/marcustettmar
Did you know we are now offering affordable monthly subscriptions for Macro Scheduler Standard?
http://mjtnet.com/blog/ | http://twitter.com/marcustettmar
Did you know we are now offering affordable monthly subscriptions for Macro Scheduler Standard?
- Marcus Tettmar
- Site Admin
- Posts: 7386
- Joined: Thu Sep 19, 2002 3:00 pm
- Location: Dorset, UK
- Contact:
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.
However, as stated earlier, we intend to improve performance wherever possible, so will take all these suggestions into consideration during development.
Marcus Tettmar
http://mjtnet.com/blog/ | http://twitter.com/marcustettmar
Did you know we are now offering affordable monthly subscriptions for Macro Scheduler Standard?
http://mjtnet.com/blog/ | http://twitter.com/marcustettmar
Did you know we are now offering affordable monthly subscriptions for Macro Scheduler Standard?