HUSL: Colorspace for programmers

HUSL is a color space that is perfect for programmers that want to choose colors dynamically for their program.

Compare Blue to Yellow. In the Hue-Saturation-Value space, both have a “saturation” and “value” of 100. But the yellow is clearly closer to white than the blue is, since I can’t actually read yellow on white. (This is used to identify color laser printers without significanly affecting the appearance)

In HUSL, the luminance sets how bright any of the colors in the hue-saturation plane appear. In my case, I use a default luminance of 50%, and a saturation of 100%. Hue is what I change, advancing by 1 degree in hue per step of the wallpaper.

Interface Responsiveness

Recently, while working on the Cellular Background, I discovered (again) that doing things in the main interface thread is bad.

In this case, I was working on WallPaperService.Engine.onOffsetsChanged(), which gets calls for each step of the home screen in Android moving. This means that that function gets called many times a second when the user is swiping to the next panel of the home screen. Doing any kind of processing while that is happening is a very bad thing to do, from a user experience prospective.

In the end, I am using something like this:

Class MyWallPaper extends WallPaperService {
   Class MyEngine extends Engine {
       Handler handler;
       Runnable runnable;

        public void onOffsetsChanged(float xOffset, float yOffset, float xStep,
                float yStep, int xPixels, int yPixels)
        {
            this.xPixels = xPixels;
            this.yPixels = yPixels;
            handler.removeCallbacks(runnable);
            handler.post(runnable);
        }
   }
}

The important thing here is that I don’t do any heavy lifting here. The runnable draws the Bitmap I have as a buffer onto the canvas of the WallPaper, which also gets called from the separate Thread that I have doing the lions share of the processing. This lets the main thread send me a message, and I queue further processing to run, and let the interface thread get on with its work.

Android Sound Limitations

Android doesn’t have a low-latency audio API. The current bug for this is 3434.

What does this mean for me? Since the Iambic Keyboard would want to play the tones at the same time as the paddles are flashing, and not up to 300ms later, that means that I can’t do audio until this is resolved. The good news for me is that the vibrator is pretty low-latency, which makes it an acceptable substitute for me. This does mean that I can’t make a music game for Android, though.