Ueno, Tokyo
| GitHub | https://www.github.com/romainguy |
| Flickr | https://www.flickr.com/photos/romainguy |
| Photos | https://www.curious-creature.com |
Romain Guy
- 4.3K Followers
- 301 Following
- 747 Posts
Photography (curious-creature.com), Blog (romainguy.dev). Previously: Engineering Director, Android Toolkit team at Google.
Aurimas Liutikas 
Would you like to work on Compose at Google (Mountain View CA office)?
Apply here and let's work together https://www.google.com/about/careers/applications/jobs/results/97844369196753606
A great talk by @py at DroidCon Berlin on "Embracing the Chaos: Investigating Production Madness".
I couldn't agree more that a lot of growth as a software engineer is all about understanding the root cause. So much of my Grade, JVM and other knowledge came from that.
It was also nice to see that I was able to help with the first USB issue that PY talks about.
Hacker NewsPhysically Based Rendering in Filament
https://google.github.io/filament/Filament.md.html#overview
#HackerNews #PhysicallyBasedRendering #Filament #Graphics #Technology #OpenSource #3DRendering
bµg✨ New blog post: "Sharing everything I could understand about gradient noise"
https://blog.pkh.me/p/42-sharing-everything-i-could-understand-about-gradient-noise.html
I had a lot of fun making the WebGL demos, but it took me weeks of work. Boost are really appreciated if you enjoy it.
Aras PranckevičiusSkribidi - "Nimble bidirectional text stack for UIs" by @MikkoMononen looks very cool. https://github.com/memononen/Skribidi
New blog post, in which I show a real-world Kotlin example of manual inlining/merging computations to improve performance: https://www.romainguy.dev/posts/2025/merge-your-computations/
Merge Your Computations
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:
New blog post! In this post I explain some of the techniques used to eliminate unnecessary array bounds checks when writing Kotlin code.
https://www.romainguy.dev/posts/2025/eliminating-array-bounds-checks/
Eliminating Array Bounds Checks
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:
Tom ForsythLovely nerdy dive on mipmap selection.
https://pema.dev/2025/05/09/mipmaps-too-much-detail/
(cross-posted from https://bsky.app/profile/pema99.bsky.social - looks like they are also @pema ?)
Mipmap selection in too much detail
In this post, I want to shed some light on something I’ve been wondering about for a while: How exactly are mipmap levels selected when sampling textures on the GPU? If you already know what mipmapping is, why we use it, and what pixel derivatives (ddx() / ddy()) are, you can skip to the section Derivatives to mipmap levels. The post does, however, assume some knowledge of graphics programming.