Direct Compose Desktop rendering into toolkit-owned Wayland wl_surface via EGL, bypassing X11/JAWT; creates wl_egl_window, resizes buffers, supports integer buffer and fractional UI scaling.
Warning: this is slop code generated with AI. It is intended to be used by Echo and people who want to try BetterWindow on direct Wayland rendering.
This fork is based on JetBrains Skiko and prototypes direct Compose Desktop
rendering on JBR's Wayland AWT toolkit (sun.awt.wl.WLToolkit).
The goal is to let Skiko render through Wayland EGL into a JBR-owned
wl_surface instead of using the old X11 JAWT path or falling back to
Swing/AWT graphics.
sun.awt.wl.WLToolkit and selects the Wayland redrawer on Linux.JAWT_WaylandDrawingSurfaceInfo from JAWT_DrawingSurface.wl_display and render wl_surface.wl_egl_window and EGL OpenGL context for that Wayland surface.wl_egl_window when the component/window size changes.wl_surface_set_buffer_scale(surface, 1) and explicit buffer sizing.1.5x.-lEGL-lwayland-client-lwayland-eglThis Skiko fork expects a matching patched JBR fork that exposes Wayland JAWT surface info. Without that JBR-side API, direct Wayland EGL rendering cannot work.
Use this with:
https://github.com/brahmkshatriya/JBRWayland
At runtime the JBR must provide:
JAWT_DrawingSurface.Lock under WLToolkitJAWT_WaylandDrawingSurfaceInfowl_surfaceInstall normal Skiko build dependencies plus Linux Wayland/EGL development packages:
wayland-clientwayland-eglEGLBuild the AWT Kotlin and Linux x64 native bindings:
./gradlew :skiko:compileKotlinAwt \
:skiko:linkJvmBindingsLinuxX64 \
--no-daemon
This fork is published under:
dev.brahmkshatriya.skiko
Linux x64 Compose Desktop apps need these artifacts:
implementation("dev.brahmkshatriya.skiko:skiko:0.148.1")
implementation("dev.brahmkshatriya.skiko:skiko-awt:0.148.1")
implementation("dev.brahmkshatriya.skiko:skiko-awt-runtime-linux-x64:0.148.1")
For local Compose Desktop testing, publish this fork with the same version Compose is already requesting:
./gradlew :skiko:publishToMavenLocal \
-Pdeploy.version=0.148.1 \
-Pdeploy.release=true \
--no-daemon
This publishes 0.148.1 artifacts to Maven local, including:
dev.brahmkshatriya.skiko:skikodev.brahmkshatriya.skiko:skiko-awtdev.brahmkshatriya.skiko:skiko-awt-runtime-linux-x64Make sure mavenLocal() is first in repositories:
repositories {
mavenLocal()
google()
mavenCentral()
}
Then substitute Compose's Skiko dependencies to the locally published fork:
subprojects {
configurations.configureEach {
resolutionStrategy.dependencySubstitution {
substitute(module("org.jetbrains.skiko:skiko"))
.using(module("dev.brahmkshatriya.skiko:skiko:0.148.1"))
substitute(module("org.jetbrains.skiko:skiko-awt"))
.using(module("dev.brahmkshatriya.skiko:skiko-awt:0.148.1"))
substitute(module("org.jetbrains.skiko:skiko-awt-runtime-linux-x64"))
.using(module("dev.brahmkshatriya.skiko:skiko-awt-runtime-linux-x64:0.148.1"))
}
}
}
Run the app on the patched JBRWayland runtime and enable WLToolkit:
-Dawt.toolkit.name=WLToolkit
-Dcompose.application.configure.swing.globals=false
-Dskiko.hardwareInfo.enabled=true
--enable-native-access=ALL-UNNAMED
--add-exports=java.desktop/sun.awt=ALL-UNNAMED
--add-opens=java.desktop/sun.awt.wl=ALL-UNNAMED
compose.application.configure.swing.globals=false matters for fractional
Wayland scale. Without it, Compose can hit a Swing setup path that rounds
scale and breaks fullscreen sizing.
With -Dskiko.hardwareInfo.enabled=true, a 1.5x Wayland setup should show:
LinuxWaylandEGLRedrawer initialized ... scale=2, effectiveScale=1.5
LinuxWaylandEGLRedrawer surface update ... contentScale=1.5 ... buffer=1200x900
Here:
scale=2 is the integer Wayland buffer scale.effectiveScale=1.5 is the fractional UI/render scale from JBR.buffer=1200x900 for an 800x600 window confirms fractional sizing.This is a prototype. It was tested with BetterWindow on Wayland using the
matching JBRWayland fork and fractional 1.5x OS scale.
Known rough edges:
Surfaced from shared tags and platforms — no rankings paid for.