 |
AutoHotkey Community
Let's help each other out
|
| View previous topic :: View next topic |
| Author |
Message |
Veovis
Joined: 13 Feb 2006
Posts: 389
Location: Utah
|
 Posted: Wed Dec 03, 2008 10:53 pm Post subject: pixel get color painfully slow (vista problem?) |
 |
|
Alright, so i decided to make a pixel color getter in AHK, similar to Instant Eyedropper but that would work on both screens, and be triggerable via hotkey (having the drag the thing all the way across the screen is annoying).
Basically it creates a grid (5x5, progress controls) and updates them to the pixels around your cursor. and has a text box of the one under your cursor.
But i ran into somewhat of a problem...
It's painfully slow, updating at around once a second.
I ran into this topic and modified it slightly.
| Code: | Start := A_TickCount
count = 26
Loop, %count%
PixelGetColor, var, 1, 1,alt
end := A_TickCount
MsgBox % count " PixelGetColor calls took " (end - Start) "ms (" (end - start)/count "ms each)"
exitapp
|
Heres what i got:
26 PixelGetColor calls took 812ms (31.230769ms each)
200 PixelGetColor calls took 5865ms (29.325000ms each)
1000 PixelGetColor calls took 28595ms (28.595000ms each)
I'm on Quad Core AMD 64bit, 4gigs of ram, so thats not the problem. Is it possible its a vista thing? Could some other people try the code up there and give me your results? Also here is my current version if you want to check it out. (clipboard features not added yet)
| Code: |
#singleinstance force
#NoEnv ; Recommended for performance and compatibility with future AutoHotkey releases.
SendMode Input ; Recommended for new scripts due to its superior speed and reliability.
SetWorkingDir %A_ScriptDir% ; Ensures a consistent starting directory.
coordmode,pixel,screen
coordmode,mouse,screen
gui,color,EEEEEE
gui,margin,0,0
gui,-caption +alwaysontop
loop, 5 {
i := A_index
loop, 5 {
j := A_index
x := 10*i -9
y := 10*j -9
gui, add, progress, w10 h10 x%x% y%y% vPixel%i%%j% backgroundRed
}
}
gui,add,progress,w7 h1 x22 y25 backgroundBlack vc1
gui,add,progress,w1 h7 x25 y22 backgroundBlack vc2
guicontrol,+backgroundBlue,pixel33
gui,font,s14,
gui,add,text,x60 y15 vtext,#EEEEEEEE
gui,show,,ColorFinder
loop {
mousegetpos,mx,my
if (mx=lastx && my=lasty) {
sleep 50
continue
}
lastx := mx
lasty := my
;now lets do the pixels
loop, 5 {
i := A_index
loop, 5 {
j := A_index
pixelgetcolor,color,% mx -3 + i ,% my -3+j,RGB
guicontrol, +background%color%, Pixel%i%%j%
}
}
pixelgetcolor,color,%mx%,%my%,RGB
stringtrimleft,color,color,2
guicontrol,,text,#%color%
guicontrol,movedraw, c1,w7
guicontrol,movedraw,c2,h7
guix := mx + 20
guiy := my - 25
gui,show,NA x%guix% y%guiy% w160 h52
}
return
|
Edit: I also tried SetBatchLines, -1 and it didn't seem to help, as suggested in this thread.
_________________
"Power can be given overnight, but responsibility must be taught. Long years go into its making."
Last edited by Veovis on Wed Dec 03, 2008 11:09 pm; edited 1 time in total |
|
| Back to top |
|
 |
Szeraax
Guest
|
| Posted: Wed Dec 03, 2008 11:08 pm Post subject: Beautiful. |
|
|
XP Pro
1GB Ram
AMD Athlon 64 X2 Dual core
DX 9.0c
Works like a charm |
|
| Back to top |
|
|
evan
Guest
|
| Posted: Wed Dec 03, 2008 11:08 pm Post subject: |
|
|
Pentium D 2.8Ghz Vista Ultra results:
i thought that was pretty fast to run a complicated function in 13ms
of course, it will be much faster if u read a chunk of data at once, instead of performing the same function 1000 times |
|
| Back to top |
|
|
Veovis
Joined: 13 Feb 2006
Posts: 389
Location: Utah
|
| Posted: Thu Dec 04, 2008 4:05 pm Post subject: |
|
|
Hahaha, yeah its definetely a vista thing. Just tried the script on a AMD X2 64 2.6, 2gigs of Ram, Win XPx64. And it looks awesome.
How funny is this?
Win XP:
26000 PixelGetColor calls took 594ms (0.022846ms each)
Vista:
26 PixelGetColor calls took 812ms (31.230769ms each)
And there you have it. Win XP is more than 1000 times faster than Vista.
(Note than this was an two different computers, but the Vista machine had better specs. so i think its still valid)
_________________
"Power can be given overnight, but responsibility must be taught. Long years go into its making." |
|
| Back to top |
|
|
newToAHK
Guest
|
| Posted: Tue Apr 07, 2009 4:04 pm Post subject: |
|
|
| Im having the same issue. I might go back to XP for the faster performance on getpixelcolor but if anyone has a workaround it would be much appreciated. |
|
| Back to top |
|
|
Veovis_
Guest
|
| Posted: Tue Apr 07, 2009 5:03 pm Post subject: |
|
|
| Yeah, i was unable to get it working on Vista (i didn't try terribly hard though), and i have since returned to using XP. |
|
| Back to top |
|
|
Guest
|
| Posted: Tue Apr 07, 2009 6:26 pm Post subject: |
|
|
| Use PixelSearch, but have the start/end coords be the same and append 'fast' to the end. Does that work better? |
|
| Back to top |
|
|
svi
Joined: 09 Oct 2006
Posts: 236
Location: Finland
|
| Posted: Tue Apr 07, 2009 9:45 pm Post subject: |
|
|
Old laptop (~2004), Intel Celeron M 1500MHz, 1.25GB, XP (Home):
Fastest of about 10 tests (normally over 600ms):
26000 PixelGetColor calls took 541ms (0.020808ms each)
_________________
Pekka Vartto |
|
| Back to top |
|
|
ATH
Joined: 10 Apr 2009
Posts: 2
|
| Posted: Fri Apr 10, 2009 2:14 am Post subject: |
|
|
Anyone found a solution to this yet?
I never knew it was a Vista problem until now, when my laptop (Lenovo Thinkpad) was so much slower at PixelGetColor and PixelSearch than my desktop. I thought it the graphic card (Nvidia Quadro NVS 140M) that was slow. I was running Vista 32bit but somewhere along the line it got quicker at PixelGetColor, perhaps when I upgraded to Service Pack 1 or when I upgraded graphic drivers.
Now I installed Windows 7 64bit beta on a new harddrive and its painfully slow again, and I even tried the same graphic driver version (except 64bit) as in my Vista installation, but it didn't help, which seems to eliminate graphic driver as the cause.
Here is the timings with the script from post #1 in this thread:
Desktop: Windows XP SP3 64bit: 100000 PixelGetColor calls took 1031ms (0.010310ms each)
Laptop: Windows Vista SP1 32bit: 100000 PixelGetColor calls took 3962ms (0.039620ms each) ("only" 4 times slower now than WinXP, was much slower when I got my laptop, maybe Service Pack 1 helped?)
Laptop: Windows 7 64bit beta: 100 PixelGetColor calls took 1497ms (14.970000ms each) (1452!!! times slower than WinXP) |
|
| Back to top |
|
|
ATH
Joined: 10 Apr 2009
Posts: 2
|
| Posted: Fri Apr 10, 2009 12:45 pm Post subject: |
|
|
I found a solution to this!!!!! 
Its all the visual fancy stuff that somehow makes Pixel operations take very long time.
- Rightclick on Computer or "My Computer" and choose Properties.
- In the left side menu choose "Advanced System Settings".
- Click "Advanced"-Tab
- Under "Performance" click Settings.
In "Visual Effects"-Tab is all the settings. You can choose to remove everything by choosing "Adjust for best performance", but for me in Windows 7 64bit beta the only one I have to remove is "Enable desktop composition", that is the big culprit in this.
With every visual off I get: 10000 PixelGetColor calls took 562ms (0.056200ms each)
Everything on except "Enable desktop composition": 10000 PixelGetColor calls took 740ms (0.074000ms each)
Everything including "Enable desktop composition": 100 PixelGetColor calls took 1498ms (14.980000ms each) |
|
| Back to top |
|
|
Guest
|
| Posted: Sat Apr 11, 2009 7:54 am Post subject: |
|
|
| EveOnline001 wrote: | I'm pretty sure this is the solution:
The default SetBatchLines has a 10ms wait after each line. So a loop that reads 1000 pixels will wait:
1000 pixels x 10ms = 10000ms (10 secs!!!) |
No, you have not read the help file correctly.
| Quote: | | In the following example, the script will sleep for 10ms every time it has run for 20ms: SetBatchLines, 20ms |
and | Quote: | | default to SetBatchLines 10ms |
So by default the script runs for 10ms then sleeps for 10ms. |
|
| Back to top |
|
|
Lexikos
Joined: 17 Oct 2006
Posts: 7295
Location: Australia
|
| Posted: Sat Apr 11, 2009 10:09 am Post subject: |
|
|
| ATH wrote: | | "Enable desktop composition", that is the big culprit in this. |
The way I understand it, each time you read a pixel, you must wait for the video hardware to transfer it from video memory to system memory (via the CPU?). With desktop composition disabled, what you see on screen already exists in system memory.
IIRC, on-board video chipsets without dedicated memory can do it much faster since the data already exists in system memory. |
|
| Back to top |
|
|
Slav2_
Guest
|
| Posted: Sat Apr 11, 2009 10:32 am Post subject: |
|
|
| We have also noted that script start to work much faster with windows classic theme. From the other hand Vista Aero theme is slowest, untill you switch off transparency of windows. |
|
| Back to top |
|
|
Lexikos
Joined: 17 Oct 2006
Posts: 7295
Location: Australia
|
| Posted: Sat Apr 11, 2009 11:39 am Post subject: |
|
|
| That's what I was implying with "With desktop composition disabled,..." If it's already in system memory, you do not need to wait for the video hardware. |
|
| Back to top |
|
|
blamestar.de
Guest
|
| Posted: Sat Aug 15, 2009 10:07 pm Post subject: Workaround |
|
|
For anyone who is still struggling with this (as I was) and does not want to turn of those nice shiny transparent windows (aka Aero Glass, or compositing):
There's now a workaround available at http://www.autohotkey.com/forum/post-288755.html |
|
| Back to top |
|
|
|
|
You can post new topics in this forum
You can reply to topics in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|
FAQ
Search
Memberlist
Register
Profile
Log in to check your private messages
Log in
