Posts on Romain Guy

Tap Detection on Arbitrary Shapes with Compose

Sun, 07 Dec 2025 00:00:00 +0000

Detecting whether a user tapped on an arbitrary shape represented by a Path is an unfortunately difficult task on Android. The Path class does not offer any API to do this, and the workaround I have seen folks use (representing the tap as a small rectangle/circle and computing the intersection with the test shape) is inefficient and sometimes fails.

Thankfully, Jetpack Compose a simple way to perform this task. The video below shows how the Compose APIs can be used to detect taps, or generally perform any test requiring to check whether a specific 2D coordinate is contained inside a Path:

Finger Shadows in Compose

Sat, 29 Nov 2025 00:00:00 +0000

I recently realized that I have never discussed graphics programming on this blog, and decided it was time to correct this. A few years ago, Android 13 introduced the RuntimeShader API that allows you to write custom GPU shaders and apply them to UI elements. In this blog post I will show you how this API can be used to simulate shadows projected by the user’s finger (or stylus/pointing device) onto your UI.

Merge Your Computations

Thu, 15 May 2025 00:00:00 +0000

There is a simple but often overlooked technique to optimize performance-sensitive code: merging (or manually inlining) functions. We often build series of low-level functions that execute various computations that we then combine to perform higher-level tasks. When taken in isolation, each of those functions does exactly what it should and might even be perfectly optimized. However, when a series of thosefunctions work together, unnecessary or duplicated work might appear.

Let’s look at a concrete example taken from the Jetpack Compose code base. To apply the various geometric transforms that may affect a layer, Compose needs to build a matrix that combines all the transformations exposed by its APIs:

Eliminating Array Bounds Checks

Tue, 13 May 2025 00:00:00 +0000

The Android Runtime (ART) offers a nice memory safety feature when accessing the content of an array. The indices you use are automatically checked against the bounds of the array to prevent unsafe memory accesses. To achieve this, ART generates extra machine instructions to throw an ArrayIndexOutOfBoundsException when the index is invalid.

Here is a simple Kotlin example:

1fun scaleZ(values: FloatArray, scale: Float) = values[2] * scale

After translation to arm64 assembly, we obtain the following result:

Naming is Hard

Thu, 19 Dec 2024 00:00:00 +0000

Before we dive into today’s topic, I would like to make it clear that what follows is specific to how Android, and more precisely the Android RunTime (ART), works. Some of what follows applies to other environments as well, but the main twist is about Android.

If you have read my previous articles, you should know by now that seemingly small or irrelevant changes can have a large impact on performance. So let’s look at another one! We’ll start our journey with a class containing a bunch of fields. What they are and what they mean isn’t really relevant for now, let’s just imagine we are dealing with a fairly large object¹:

The Path Not Taken

Mon, 16 Dec 2024 00:00:00 +0000

In the last post, we saw that benchmarks don’t always measure what we think they measure. Let’s look at another instance of this problem today, starting with this rather simple benchmark:

 1@RunWith(AndroidJUnit4::class)
 2class DataBenchmark {
 3 @get:Rule
 4 val benchmarkRule = BenchmarkRule()
 5
 6 // Generate data in [0..255]
 7 private val data = IntArray(65_536) {
 8 it % 256
 9 }
10
11 @Test
12 fun processData() {
13 var sum = 0f
14 benchmarkRule.measureRepeated {
15 for (d in data) {
16 if (d < 128) {
17 sum += d / 128f
18 }
19 }
20 }
21 BlackHole.consume(sum)
22 }
23}

This benchmark tests an algorithm that processes an array of values between 0 and 255 (8-bit pixels for instance), and computes the sum of the normalized values for pixels less than 128.

You Are Going to Need It

Fri, 13 Dec 2024 00:00:00 +0000

Optimizing code can be a difficult task because there are so many traps you need to avoid at every step of the way. Today I want to focus on one of the (numerous) benchmarking traps, which you may have run into, and that I myself encounter regularly.

Let’s imagine you are trying to optimize code, and you notice the use of a value.pow(2f). One obvious way to optimize this is to replace the function call with a multiplication (value * value), but is it worth it? Since you are a diligent engineer, you decide to write a microbenchmark to compare before and after:

Optimization, Step by Step

Mon, 25 Nov 2024 00:00:00 +0000

BlurHash is a compact representation of placeholders for images. A blur hash is encoded as a short string that can be rendered to a bitmap at runtime to display a “blurry” version of the source image. The way it works remind me of how spherical harmonics are used in 3D rendering engines to efficiently encode irradiance.

I recently remembered that I had been meaning to look at the Kotlin implementation of BlurHash to see if there was a way to make it faster. I looked up the KMP port and after a few changes, I was able to make decoding a blur hash up to 4.35x faster on a Pixel 6 running Android 14. For all the measurements mentioned in this article, I decoded a fixed blur hash to a 384x384 image. The original code took 24.4 ms to do this when running at full speed, and 41.5 ms when locking the CPU clocks. This is way too long considering the low resolution of the image.

A Micro-optimization You Will Never Need

Sun, 10 Nov 2024 00:00:00 +0000

Today I would like to show you a micro-optimization I recently used more for the fun of it than for its real impact. It’s an interesting trick that you should never bother to use, nor worry about.

It starts from a piece of Kotlin code that looked a bit like this (the original version used named constants, but I replaced them with their actual values for clarity in this context):

Down Another Rabbit Hole

Mon, 27 May 2024 00:00:00 +0000

Jake Wharton recently caused me to go down yet another silly optimization rabbit hole when he nonchalantly linked to a piece of code used to count the number of digits in a Long during a Slack conversation about Kotlin’s lack of ternary operator. This of course triggered folks like Madis Pink and me to want to optimize it…

Counting digits Link to heading

The simplest way to count the number of digits would be to compute log10(n).toInt() + 1, where n is our input number. Unfortunately logarithmic functions like Kotlin’s log10 are only defined for floating point numbers. If our input is an Int or a Long, we could first convert to Double and then call log10, but not all Long values can be stored in a Double (any value above 2^53), and we would have to special case 0. We must therefore find a different solution¹.

Down a Rabbit Hole

Sat, 18 May 2024 00:00:00 +0000

I recently discussed an optimization that I worked on following Leland’s successful nerd snipe. That, however, was not the end of it. He also needed to test for intersecting/overlapping rectangles. The most obvious way to achieve this is pretty straightforward:

1// A rectangle is defined by its left (l), top (t),
2// right (r), and bottom (b) coordinates
3data class Rect(val l: Int, val t: Int, val r: Int, val b: Int) {
4 fun overlaps(other: Rect) =
5 l < other.r && other.l < r && t < other.b && other.t < b
6}

The source code is nice and tidy, but the generated assembly is less than ideal (as always, the code was optimized with R8 first):

Practical Optimizations at Android Makers 2024

Mon, 06 May 2024 00:00:00 +0000

I recently gave a talk called Practical Optimizations at Android Makers 2024. The talk is focused on some of the low-level optimizations we implemented in Jetpack Compose, their impact on performance, and the programming techniques behind them. You will likely find this talk interesting if you’ve been enjoying the articles about performance and optimizations on this blog.

Enjoy!

Readability of Optimized Kotlin Code

Fri, 03 May 2024 00:00:00 +0000

Leland and I were recently discussing how to best implement a new data structure to speed up a specific aspect of Jetpack Compose. He came up with a great idea, and nerd sniped me in the process. The problem was to efficiently encode the occupancy of an 8x8 grid represented as a Long (each bit representing a cell in the grid).

After coming up with the bit twiddling code that quickly “rasterizes” a rectangle into the grid as a bitfield, I found myself thinking about how incredibly helpful Kotlin can be at making low-level/micro-optimized code easy to read¹ for users of an API.

Speeding up isBlank()

Mon, 05 Feb 2024 00:00:00 +0000

I was recently optimizing a small part of the Jetpack Compose runtime when I stumbled upon a seemingly harmless API, isBlank(). This API return true if the string it’s called on is empty or consists solely of whitespace characters.

But is it truly harmless? Let’s look at the JVM implementation to get a better sense of what it does:

1public actual fun CharSequence.isBlank(): Boolean =
2 length == 0 || indices.all { this[it].isWhitespace() }

Simple and straight to the point. Unfortunately the bytecode tells a very different story:

Micro-optimizations in Kotlin — 3

Wed, 31 Jan 2024 00:00:00 +0000

The Kotlin standard library is a wonderful set of APIs, but it sometimes hides… interesting surprises. So today let’s took at the innocent looking minOf() and maxOf() functions.

These functions let you perform a min/max on a series of values, instead of just two with the more common min() and max() functions. Both min() and max() are straightforward and simply delegate — on Android and JVM — to Math.min()/Math.max() respectively, which you can assume to be implemented with intrinsics (and are on Android).

Going Old School

Thu, 25 Jan 2024 00:00:00 +0000

While looking for optimization opportunities in various parts of Jetpack Compose, I recently discovered that calling the cube root function was taking a non-neligible amount of times in two areas of the Toolkit: when evaluating cubic Bézier easing curves and when interpolating colors through the OkLab color space.

Working on graphics projects taught me that approximations can often be powerful optimization tools, so I decided to come up with an approximation of cbrt()¹:

A Better Hash Map — 1

Sat, 20 Jan 2024 00:00:00 +0000

Hash maps are extremely common data structures, and Jetpack Compose unsurprisingly takes advantage of them for various tasks. Kotlin makes it easy to create a new mutable hash map by calling the mutableMapOf() function. Most developer will — and should — stop there, and use the map however they need to. Things are however a bit different when working on a toolkit like Jetpack Compose as we need to ensure the toolkit’s behavior is as unintrusive as possible for the app.

Micro-optimizations in Kotlin — 2

Tue, 16 Jan 2024 00:00:00 +0000

In the previous post, we saw how we could micro-optimize Int.sign to save a few instructions. We are now going to turn to Float.sign (and by extension Double.sign).

Float.sign returns the sign of single-precision float value as a single-precision float value. While similar to Int.sign, this API must handle a special cases: Not-a-Number (NaN). The exact behavior of the API is that it will return:

-1.0f if the value is negative
+/-0.0f if the value is zero (floats can encode both positive and negative zero)
1.0f if the value is positive
NaN if the value is NaN

An easy way to implement this API ourselves is to return the input when the input equals 0.0f or NaN, and to return the input’s sign copied onto 1.0f otherwise. Translated to code, we can write:

Micro-optimizations in Kotlin — 1

Mon, 15 Jan 2024 00:00:00 +0000

While my work responsibilities do not leave me much time to write code nowadays, I have managed to make a few small contributions to Jetpack Compose in the last few months, mostly focusing on performance.

If you are an Android app developer, your performance concerns probably start and stop at a fairly high level ¹. I find working on large scale libraries like Compose fascinating because you need to worry about performance not only at a macro level, but also at a micro level. Since parts of the libraries can be invoked frequently (many times per frame for instance), even micro-optimizations can make a difference ².