Sikuli IDE Disappears When Capture is Invoked

Asked by J. Mailshredder

I have used earlier versions of Sikuli successfully... But I just recently installed Sikuli X-1.0rc2 on Windows Vista 32-bit (a fresh, first time install) using the Windows .EXE installer and I am seeing behavior similar to that mentioned on a couple of "bug reports". The IDE disappears during capture.

It occurs using both a single and dual-monitor configuration.

Even though the IDE disappears, the associated process (javaw.exe) continues to run.

Sikuli was launched using the ".bat" process. ("C:\Program Files\Sikuli X\Sikuli-IDE-w.bat")

I noted some "similar" reports where the following startup process was suggested to capture additional data:

java -Dsikuli.console=false -jar "c:\Program Files\Sikuli X\sikuli-ide.jar"

When I do this... The following console information is captured:

[info] locale: en_US
[debug] init user preferences
[info] install hotkey: CTRL+SHIFT+2 for onQuickCapture
[info] install hotkey: ALT+SHIFT+C for onStopRunning

Then the IDE successfully appears. If you click on the "Take Screenshot" icon the IDE disappears. The following additional console information also appears:

Exception in thread "capture" java.lang.UnsatisfiedLinkError: C:\Users\ud\AppDat
a\Local\Temp\tmplib\Win32Util.dll: Can't find dependent libraries
        at java.lang.ClassLoader$NativeLibrary.load(Native Method)
        at java.lang.ClassLoader.loadLibrary0(Unknown Source)
        at java.lang.ClassLoader.loadLibrary(Unknown Source)
        at java.lang.Runtime.load0(Unknown Source)
        at java.lang.System.load(Unknown Source)
        at com.wapmx.nativeutils.jniloader.NativeLoader.loadLibrary(NativeLoader.java:44)
        at org.sikuli.script.Win32Util.<clinit>(Win32Util.java:14)
        at java.lang.Class.forName0(Native Method)
        at java.lang.Class.forName(Unknown Source)
        at org.sikuli.script.Env.getOSUtil(Env.java:84)
        at org.sikuli.script.ScreenHighlighter.init(ScreenHighlighter.java:175)
        at org.sikuli.script.ScreenHighlighter.<init>(ScreenHighlighter.java:288)
        at org.sikuli.script.Screen.initBounds(Screen.java:96)
        at org.sikuli.script.Screen.<init>(Screen.java:89)
        at org.sikuli.script.UnionScreen.<init>(UnionScreen.java:10)
        at org.sikuli.script.CapturePrompt.<init>(CapturePrompt.java:317)
        at org.sikuli.script.CapturePrompt.<init>(CapturePrompt.java:310)
        at org.sikuli.ide.CaptureButton$1.run(CaptureButton.java:186)

I researched the "error" shown above - and all reference articles I could find seemed to indicate this was a "path" problem. But both Sikuli and Java are mentioned correctly in my PATH variable:

C:\Program Files\Sikuli X\libs;C:\Program Files\Java\jre6\bin

Can anyone familiar with the new version shed some light on why it's not working? Any help would be greatly appreciated.

Thanks...

NOTE: I am currently running an older build of Java JRE (v1.6.0 Build 1.6.0-b105) for testing as the default behavior for "direct draw" was changed after JRE 6 update 10 and the Sikuli IDE does not properly display when running the latest version of the Java JRE on Windows Vista 32-bit - even with antialiasing disabled.

Question information

Language:
English Edit question
Status:
Solved
For:
SikuliX Edit question
Assignee:
No assignee Edit question
Last query:
Last reply:
Revision history for this message
RaiMan (raimund-hocke) said :
#1

You should make a test with the newest JRE version.
Win32Util wants to load a correctly featured jawt.dll from the Java\jre6\bin directory.

Revision history for this message
J. Mailshredder (junkmailshredder) said :
#2

Thank you for the quick reply.

Unfortunately using the latest JRE version is not possible at the present moment. Sun modified the internals of JRE 1.6 somewhere around Update 10 to enable "Direct Draw" by default. This causes the Sikuli IDE to be unusable on many machines with particular graphic chipsets - particularly those manufactured by Intel. We have submitted an inquiry to to the developers to try and figure out a "work around" as their stated workaround:

<app> -Dsun.java2d.noddraw=true

does not revert the behavior to the correct functionality that existed prior to the change.

In the interim, we will continue to use the older version of Sikuli.

I will update this response again once we get an update from Sun / Oracle regarding the JRE fix. And, thanks again for your help!

Revision history for this message
Aaron Portier (aaronsportier) said :
#3

This happens to me as well. I upgraded to the most recent version and installed with Windows 7. I am starting to wish I had not.

Revision history for this message
RaiMan (raimund-hocke) said :
#4

reverted to bug