What Colour Is It

[Fruity]

Inspired by this - http://whatcolourisit.com/

 

I decided to add a little extra to my scripts. Just something small that wont improve the performance or anything. Basically there for cosmetic reasons

 

How to:

 

Add yer start time:

    long startTime;

Then in onStart add:

public void onStart() throws InterruptedException {
        
        startTime = System.currentTimeMillis();
        
}

Then make a timeToHex method:

public static String timeToHex (long time) {
        int sec = (int) (time / 1000), h = sec / 3600, m = sec / 60 % 60, s = sec % 60;
        return "#" + (h < 10 ? "0" + h : h)+(m < 10 ? "0" + m : m)+ (s < 10 ? "0" + s : s);

}

Then in onPaint add:

public void onPaint(Graphics2D g) {
        super.onPaint(g);

        long timeRan = (System.currentTimeMillis() - startTime);
        Color timeColor = Color.decode(timeToHex(timeRan));

        g.setColor(timeColor);

}

Now the colour timeColor will change the more you run the script

 

 

Fruity.

[Reason]

Pretty cool little thing to add.

[Eagle Scripts]

Quite interesting, I like it!

[Fruity]

Quite interesting, I like it!

 

Aha good x]

 

Pretty cool little thing to add.

 

I thought it was :P

[fixthissite]

Very neat idea. You should tend to the excess onjects that are being created though.

Keep in mind, Color is immutable, so decode returns a new Color instance each call. Depending on how fast your onPaint is executing, this could generate a lot of short-lived Color objects, requiring more GCs (although minor, enough minor GCs within a certain timeframe can result in a performance impact). Seeing how a new color generates only every second, you should only be creating a new Color after a second has passed

Edited June 9, 2015 by fixthissite

[Fruity]

Very neat idea. You should tend to the excess onjects that are being created though.

Keep in mind, Color is immutable, so decode returns a new Color instance each call. Depending on how fast your onPaint is executing, this could generate a lot of short-lived Color objects, requiring more GCs (although minor, enough minor GCs within a certain timeframe can result in a performance impact). Seeing how a new color generates only every second, you should only be creating a new Color after a second has passed

 

Thank you! and thank you for the info on the colour

 

Ran script for 30+mins (Not very long to get a good test i know) but this is the memory usage atm:

[fixthissite]

Thank you! and thank you for the info on the colour

 

Ran script for 30+mins (Not very long to get a good test i know) but this is the memory usage atm:

The problem isn't high memory usage. Since the objects are short lived, they will be cleaned up as soon as a minor collection is performed.

 

It's the amount of times the GC is required to perform. Your heap will fill up quickly, requiring far more collections than should be required. This can cause a performance impact when in comes to CPU time, not memory.

 

Similar to defragmenting your hard drive, objects that don't get "sweeped" get reorganized. During this time, the object graph is considered to be in an inconsistent state, and all threads are blocked from accessing objects. This is called safepoint, but most refer to it as "Stop-The-World", and occurs not only for GC, but other "under the hood" systems. The more often STW occurs, the more latency you'll notice in your program. The more often a GC is required, the more often STWs occur

Edited June 10, 2015 by fixthissite