Spooky delay in PixelGetColor?

[Xibalba]

In my script i check a small area (say 20x20 pixels) with looped PixelGetColor. This has worked without any real problems for months and has taken about 20ms to complete.

To test my script, I'm running Photoshop and activate different layers to show different photos. This has also worked great. After a GPU replace (to the better) a week ago it worked great the first few days, but now I've come to a dead end.

This is the deal:

• I open my .psd file and runs my script - performance is ok
• I switch to layer 2 and runs my script - performance is ok
• I switch back to layer 1 and runs my script - performance is horrible, almost 50ms.
• At this point it doesn't matter what I do, every use of PixelGetColor() is slow.
• Now, if I close Photoshop completely, reopens my .psd file and run the script again - performance is ok

What could possible be the problem!?

Could it be anything with the new Nvidia drivers - PhysX/hyperthreading and all that new shit (which I didnt use earlier)?

After a search through the forums I've found some interesting stuff making me far from the only one having general performance issues using the PixelGetColor() function.

I'm gonna take a shot using _GDIPlus_BitmapLockBits instead and see if that helps. But I wonder if there might be something more at work in my case?

As mentioned, I'm using the same script as I have for months. I've tested with Photoshop again and again - same result. Also tried using Paint but then its horrible speed constantly. It's just now the problems started.

Related links on the matter

Setup

WinXP

GPU 1GB GeForce

3 GB RAM

1600x1200x32

Window Classic theme with all Performance Visual Effects turned off.

AutoIt v3.3.8.1

Edited January 6, 2014 by Xibalba

[Bert]

I have to ask the standard question right from the get go - Why do you have to use pixel searching? Is there a control you can hook into in the application?

Second, do you have code you can share so we can see what you are doing?

[Xibalba]

I was gonna try out _GDIPlus_BitmapLockBits instead of PixelGetColor as described >here.

But my AutoIt crashes running that example, and after some debugging I have this script:

expandcollapse popup

#include <GUIConstantsEx.au3>
#include <GDIPlus.au3> ; for GDI+
Global Const $width = 600
Global Const $height = 400
Global $title = "GDI+ Test"

Opt("GUIOnEventMode", 1)
$wnd = GUICreate($title, $width, $height)
GUISetOnEvent($GUI_EVENT_CLOSE, "close")
GUISetState()
Sleep(10)

; PixelGet method
$n1 = 100 ; set to ~100 if DWM enabled, otherwise ~100,000 (larger samples are more accurate)
$start_time = TimerInit()
For $i = 1 To $n1
    PixelGetColor( 1, 1, $wnd)
Next
$time1=int(TimerDiff($start_time))/$n1
MsgBox(0, "mBox", "PixelGet avg (ms/pixel): " & $time1)

; GDI+ method
_GDIPlus_Startup ()

WinActivate($wnd)
Sleep(10)
$hGraphic = _GDIPlus_GraphicsCreateFromHWND($wnd)
#cs
$BitmapData = _GDIPlus_BitmapLockBits($hGraphic, 0, 0, 10, 10, $GDIP_ILMREAD, $GDIP_PXF32RGB)

$Scan0 = DllStructGetData($BitmapData, "Scan0")
$Stride = DllStructGetData($BitmapData, "Stride")
$pixel = $Scan0 + $Stride + 4

$n2 = 100000 ; 100,000
;$n2 = 1000000 ; one million iterations should take ~3 sec
$start_time=TimerInit()
For $i = 1 To $n2
    DllStructCreate("dword", $pixel)
Next
$time2=int(TimerDiff($start_time))/$n2

MsgBox(0, "mBox", "GDIPlus  avg (ms/pixel):" & $time2)
MsgBox(0, "mBox", "GDIPlus = " & round($time1/$time2,1) & "x PixelGet")

_GDIPlus_BitmapUnlockBits($hGraphic, $BitmapData)
#ce
_GDIPlus_GraphicsDispose ($hGraphic)
_GDIPlus_ShutDown ()
Exit

As you can see, I've commented everything below the line $hGraphic = .

This script runs for me, but the next line is the problem.

If i move the line BitmapData = above the commented section (so it runs) AutoIt just crashes

blabla has encountered a problem and was closed, send report to Microsoft Y/N, error signature:

AppName: autoit3.exe     AppVer: 3.3.8.1     ModName: gdiplus.dll
ModVer: 5.2.6002.23084     Offset: 000464c9

 

Why is it crashing?

Other GDI+ examples are working for me, like >this one.