1.1.33.10 PixelSearch without Fast mode hangs up the script Topic is solved

Report problems with documented functionality
teadrinker
Posts: 4309
Joined: 29 Mar 2015, 09:41
Contact:

1.1.33.10 PixelSearch without Fast mode hangs up the script

Post by teadrinker » 21 Sep 2021, 19:31

This code

Code: Select all

PixelSearch, x, y, 300, 300, 600, 600, 0xFFAABB
makes the script unresponsive.

swagfag
Posts: 6222
Joined: 11 Jan 2017, 17:59

Re: 1.1.33.10 PixelSearch without Fast mode hangs up the script

Post by swagfag » 21 Sep 2021, 20:56

which is a bug how? its busy executing the 300*300=90k GetPixel calls uve scheduled it to

User avatar
boiler
Posts: 16772
Joined: 21 Dec 2014, 02:44

Re: 1.1.33.10 PixelSearch without Fast mode hangs up the script

Post by boiler » 21 Sep 2021, 21:18

I’ve always had it hang up in the past when I didn’t use Fast. I figured regular mode was only useful over very small search areas, so I avoided using it.

teadrinker
Posts: 4309
Joined: 29 Mar 2015, 09:41
Contact:

Re: 1.1.33.10 PixelSearch without Fast mode hangs up the script

Post by teadrinker » 21 Sep 2021, 22:15

Ah, got it. It would be nice to mention this issue in the docs.

joefiesta
Posts: 494
Joined: 24 Jan 2016, 13:54
Location: Pa., USA

Re: 1.1.33.10 PixelSearch without Fast mode hangs up the script

Post by joefiesta » 23 Sep 2021, 14:36

@teadrinker: it IS in the doc under REMARKS at PIXELSEARCH.

If the region to be searched is large and the search is repeated with high frequency, it may consume a lot of CPU time. To alleviate this, keep the size of the area to a minimum

teadrinker
Posts: 4309
Joined: 29 Mar 2015, 09:41
Contact:

Re: 1.1.33.10 PixelSearch without Fast mode hangs up the script

Post by teadrinker » 23 Sep 2021, 16:27

@joefiesta
IMO, not very intelligible. Even if the region is 100x100 and the search is repeated just once, it hangs up the script for quite a long time.

lexikos
Posts: 9560
Joined: 30 Sep 2013, 04:07
Contact:

Re: 1.1.33.10 PixelSearch without Fast mode hangs up the script  Topic is solved

Post by lexikos » 25 Sep 2021, 01:23

The comment about search area relates to both modes, and cannot explain the difference between the two modes.

Fast mode "dramatically reduces the amount of CPU time used by the search". The difference between so long you give up and terminate the process and mere milliseconds is dramatic, right? ;)

On systems with desktop composition, GetPixel is orders of magnitude slower.
With Aero enabled, Windows doesn't need to maintain an actual bitmap of the display. It simply maintains polygons that hold individual window contents and lets the compositor handle mixing them in the correct way. As soon as you make a call to GetPixel, it is forced into rendering all the windows into a single bitmap so that it can figure out what colour that pixel is. Doing this is always going to be very, very slow in comparison.
Source: GetPixel calls slow under Aero??
Also,
PixelSearch's slow mode was removed, as it is unusable on most modern systems due to an incompatibility with desktop composition.
Source: Changes from v1.1 | AutoHotkey v2
I've added a note to the v1 docs.

boiler wrote: I figured regular mode was only useful over very small search areas, so I avoided using it.
IMO, regular mode isn't useful even over very small search areas on systems without desktop composition. I think the only reason it didn't simply replace the default mode (in v1) is that it may produce different results (for multiple reasons).

Post Reply

Return to “Bug Reports”