Haiku Depot Server - Introducing a graphics server

Background

The HaikuDepot desktop application is the means by which many Haiku users learn about and install packages for the Haiku system. Behind the scenes, coordinating data for the desktop application is a server component called HaikuDepotServer (HDS). HDS communicates with the desktop application using HTTP requests.

The HDS server is a Java / SpringBoot application built to a container image that then runs on a Kubernetes deployment system. As part of its operation, HDS needs to frequently perform graphics operations such as;

• Render icons in Haiku’s bespoke HVIF icon format into .png bitmaps so they can be viewed in a browser.
• Optimizing uploaded .png screenshots
• Scaling .png screenshots

In the past these graphics operations have typically occurred in the same execution environment as the Java process running HDS. Some of the graphics operations were undertaken using Java libraries within the same virtual machine as the application server whereas others were undertaken by invoking native executables running in the same environment as the HDS application server.

Problems

This arrangement for undertaking graphics operations presented a few problems.

• The hvif2png tool renders the HVIF icons files. I wrote this tool some years ago and, it is an artefact produced from Haiku’s jam-based build process. This means the tool has to be built before it can be included in the HDS container image. Owing to the complexities around building that and the Java software, the hvif2png tool was packages as pre-build binaries and then bundled into the HDS container image. This posed challenges around updating the tool and the steps related to its packaging.
• The needs of the tools’ execution has meant that a fatter deployable container image has been required for HDS to accommodate them.
• Should one of the graphics tools experience a safety issue such as security vulnerability, a memory leak or a run-away resource consumption situation then the impact will flow over into the HDS application server running in the same execution environment.
• The compute or I/O requirements of the graphics tools may be quite different to the HDS application.
• The graphics library that was used in HDS was no longer actively supported.

Solution

The graphics operations have been separated into another container image with its own small Java / SpringBoot server to mediate inbound graphics requests to and from the tools. Sometimes the tools need to be used in coordination with each other which is also managed by the Java software.

The graphics support services’ container image is built using a multi-stage Docker build system that assembles and builds the hvif2png tool from master of the Haiku source. The remaining tools are native and are either downloaded as part of the Docker container build or are installed via operating system packages as part of the container build. The graphics operations are no longer occurring in the Java virtual machine.

• The hvif2png tool’s build is no longer tied to the HDS application server and the tool is built as the graphics servers’ container is built.
• The tools and their dependencies are no longer required to be included in the HDS application server container image.
• If a tool experiences an operational issue, the impact is more likely to be constrained to the graphics server’s execution environment.
• The compute and I/O requirements of the application server can scale independently of the graphics server.
• The older graphics library used in HDS is no longer used.

The new system has been deployed and the production HDS application now off-loads the graphics operations to the graphics server.

Graphics tools

The hvif2png tool is, as mentioned, custom. The remaining tools are standard. Aside from icons, HDS is processing PNG format images. The tool convert from ImageMagick is used to scale images down and the tool optipng is used to optimize images before they are stored.

Quantizing

Some investigation was undertaken on quantizing images as well, but ultimately it was decided not to use quantization because it would necessarily degrade the images.

As an example of quantization in action, the following cropped screenshot image is 73Kb in size;

When this image is quantized using pngquant, the size comes down to 39Kb which is a saving of around 47%. The resulting image is impressively close to the original;

As is typical for quantized images, differences can be seen around gradated fills.

Future

At the current time, in the interest of convenience and ease of deployment, HDS stores packages’ screenshot images in a relational database as BLOBs. Looking forward to the future, should demand grow, it may prove more practical to store those screenshot images into a dedicated blob storage system that is more tuned toward binary data. Generating scaled images on-demand may also prove impractical at some point and at this time, pre-generated scaled images could also be persisted to dedicated blob storage as well.

Given the nature of the project, the small audience and the limited man-hours available to build and maintain the system, this simple approach is more than sufficient for the foreseeable future.