AutoHotkey Community

It is currently May 26th, 2012, 3:48 pm

All times are UTC [ DST ]




Post new topic Reply to topic  [ 16 posts ]  Go to page 1, 2  Next
Author Message
PostPosted: December 3rd, 2008, 11:53 pm 
Offline

Joined: February 13th, 2006, 10:40 pm
Posts: 389
Location: Utah
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.

_________________
Image
"Power can be given overnight, but responsibility must be taught. Long years go into its making."


Last edited by Veovis on December 4th, 2008, 12:09 am, edited 1 time in total.

Report this post
Top
 Profile  
Reply with quote  
 Post subject: Beautiful.
PostPosted: December 4th, 2008, 12:08 am 
XP Pro
1GB Ram
AMD Athlon 64 X2 Dual core
DX 9.0c

Works like a charm


Report this post
Top
  
Reply with quote  
 Post subject:
PostPosted: December 4th, 2008, 12:08 am 
Pentium D 2.8Ghz Vista Ultra results:
Image
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


Report this post
Top
  
Reply with quote  
 Post subject:
PostPosted: December 4th, 2008, 5:05 pm 
Offline

Joined: February 13th, 2006, 10:40 pm
Posts: 389
Location: Utah
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)

_________________
Image
"Power can be given overnight, but responsibility must be taught. Long years go into its making."


Report this post
Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: April 7th, 2009, 5:04 pm 
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.


Report this post
Top
  
Reply with quote  
 Post subject:
PostPosted: April 7th, 2009, 6:03 pm 
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.


Report this post
Top
  
Reply with quote  
 Post subject:
PostPosted: April 7th, 2009, 7:26 pm 
Use PixelSearch, but have the start/end coords be the same and append 'fast' to the end. Does that work better?


Report this post
Top
  
Reply with quote  
 Post subject:
PostPosted: April 7th, 2009, 10:45 pm 
Offline

Joined: October 9th, 2006, 8:19 pm
Posts: 236
Location: Finland
Old laptop (~2004), Intel Celeron M 1500MHz, 1.25GB, XP (Home):
Image

Fastest of about 10 tests (normally over 600ms):
26000 PixelGetColor calls took 541ms (0.020808ms each)

_________________
Pekka Vartto


Report this post
Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: April 10th, 2009, 3:14 am 
Offline

Joined: April 10th, 2009, 2:13 am
Posts: 2
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)


Report this post
Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: April 10th, 2009, 1:45 pm 
Offline

Joined: April 10th, 2009, 2:13 am
Posts: 2
I found a solution to this!!!!! :D

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)


Report this post
Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: April 11th, 2009, 8:54 am 
EveOnline001 wrote:
I'm pretty sure this is the solution:

Code:
SetBatchLines, -1


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.


Report this post
Top
  
Reply with quote  
 Post subject:
PostPosted: April 11th, 2009, 11:09 am 
Offline

Joined: October 17th, 2006, 4:15 pm
Posts: 7502
Location: Australia
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.
Quote:
Source: Greg Schechter's Blog : Drawing To and Reading From the Screen -- Baaaad!
Reading from the video memory surface is very expensive, requires synchronization with the DWM, and stalls the entire GPU pipe, as well as the DWM application pipe.
IIRC, on-board video chipsets without dedicated memory can do it much faster since the data already exists in system memory.


Report this post
Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: April 11th, 2009, 11:32 am 
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.


Report this post
Top
  
Reply with quote  
 Post subject:
PostPosted: April 11th, 2009, 12:39 pm 
Offline

Joined: October 17th, 2006, 4:15 pm
Posts: 7502
Location: Australia
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.


Report this post
Top
 Profile  
Reply with quote  
 Post subject: Workaround
PostPosted: August 15th, 2009, 11:07 pm 
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


Report this post
Top
  
Reply with quote  
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 16 posts ]  Go to page 1, 2  Next

All times are UTC [ DST ]


Who is online

Users browsing this forum: Bing [Bot], BrandonHotkey, Exabot [Bot], notsoobvious and 21 guests


You can post new topics in this forum
You can reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Powered by phpBB® Forum Software © phpBB Group