https://kotlinlang.org logo
Join Slack
Powered by
Hi! I heard in a lightning talk from the Kotlin Co...
# webassembly
j
Hi! I heard in a lightning talk from the Kotlin Conf 2025 that Compose Multiplatform on Web (with Wasm) is rendered on Canvas. How does that work? Are there any resources diving into rendering? I have a bunch of questions like • Does it write ui updates as bytes into a shared memory and the web browser reads from it as a stream and sends that to the canvas? • Does it calculate/render the compose tree and send that over the browser where it converts it as UI?
c
It’s using skiko to draw to an 
<canvas>
Element
Check out the web samples https://zal.im/wasm/iv and see that the whole website is just one canvas element. There is also #C01F2HV7868 where you might get better answers to questions like this.
👍🏻 1
a
Its not canvas anymore. I think it used to be, and there's a deprecated API that you can still use to render into a canvas. This is completely done in compose, and you can see its all shown as DOM in the browser.
c
That’s compose HTML and not Compose web. They are 2 different things. Compose HTML is not multiplatform. https://github.com/JetBrains/compose-multiplatform
a
I'm writing this using standard multiplatform compose API primitives. Not the compose HTML wrapper API. If you haven't tried it for a while, try it. Launch into Compose using: ComposeViewport(document.getElementById("some div")!!) { ... } There is a deprecated API that I think is what you are talking about 
CanvasBasedWindow
p
ComposeViewport is still canvas based but it uses some shadow dom elements for accessibility and input methods
☝🏻 1
a
Maybe they are slowly transitioning it? If you look at my screencap, there is a single canvas up top. However, all of the text on the screen is inside divs in the DOM. The original question here was whether a compose WASM app can be indexed by search engines. It certainly looks to me like this is now going to work given that I can see the text right in the DOM.
c
Maybe they are slowly transitioning it?
definitely not. they tried with Compose HTML but that breaks the whole concept of Compose to be Multiplatform and using the same rendering engine on all target platforms.
The original question here was whether a compose WASM app can be indexed by search engines
where do you see this question? OP asked about how rendering works and Oleksandr answered in the cross post.
a
I'm not saying they are transitioning from the multiplatform API to the HTML API. I'm saying that under the covers maybe they are slowly moving from a Canvas implementation to a DOM implementation. This would explain why so many people are SURE its entirely Canvas, but my screenshot is showing DOM. Are you looking at my screen shot? >> The original question here was whether a compose WASM app can be indexed by search engines > where do you see this question? OP asked about how rendering works and Oleksandr answered in the cross post. Ach you are right, I must have seen that debate in a different thread... I've been searching this topic and reading lots of threads because for performance gfx I was actually hoping it WAS rendered in a canvas and I could get access to the skia layer directly. But now to do that you need to create a separate Canvas, lay it on top of the other Composables and work thru issues related to touch/click being captured by your gfx canvas.
j
Yes, my original question didn’t have anything to do with html. I was wondering about how composables written in kotlin are rendered on a webpage
c
Are you looking at my screen shot?
yes, and do you see that this is a 
#shadow-root
host. and Paul pointed out that
it uses some shadow dom elements for accessibility and input methods
But now to do that you need to create a separate Canvas
are those API’s not available in Compose web? https://developer.android.com/develop/ui/compose/graphics/draw/overview
30 Views
Open in Slack
PreviousNext
Powered by