Hello, I have prototyped JAWT support for WLToolkit and would like to gauge interest in contributing it.
Today no JDK exposes a Wayland surface through JAWT: jawt_md.h is X11-only and libjawt links only libawt_xawt. As a result, JAWT-based native renderers (Skia/Compose, OpenGL or Vulkan canvases) cannot render natively under WLToolkit and fall back to XWayland. What works today for top-level windows: - a JAWT_WaylandDrawingSurfaceInfo (wl_surface*, wl_display*) in jawt_md.h; - a libawt_wlawt implementation that resolves the peer's wl_surface under the AWT lock and reports JAWT_LOCK_SURFACE_CHANGED when it is recreated; - runtime toolkit dispatch in libjawt via AWTGetToolkitID (the awt_LoadLibrary.c idiom), so libjawt is no longer statically bound to libawt_xawt. The JAWT drawing-surface cycle returns a live wl_surface on a real compositor and has a jtreg test. Two questions before I file an issue and open a PR: 1. Scope. Top-level windows have a wl_surface and work. A lightweight java.awt.Canvas under WLToolkit has no surface of its own, so serving it needs a per-component wl_subsurface, analogous to the CALayer that macOS JAWT hands a lightweight canvas. Would a top-level-windows-first change be acceptable with Canvas as a follow-up, or should the first change include Canvas? 2. API. Does JAWT_WaylandDrawingSurfaceInfo carrying only wl_surface and wl_display (leaving wl_egl_window or VkSurfaceKHR creation to the consumer, as X11 leaves GLX to the consumer) look like the right shape? Is there interest in this, and any guidance on the above? Thanks, Vitalii Vakar
