A modern programming language that makes developers happier.

kotlinlang

Has anyone embedded CEF or any other browser into their Compose Desktop application I wonder?

<https://github.com/JetBrains/compose-jb/tree/master/experimental/cef>

Didn’t try myself, but it’s kinda official/experimental

<@U01EXLGH414> I’ve been playing around with it for the past hour.

There are certain files that were hosted on jcenter that I can’t access anymore, which has been frustrating. Namely <https://bintray.com/jetbrains/skija/download_file?file_path=jcef-runtime-$target.zip>

Any idea where I can download this file?

I think you can use `<https://packages.jetbrains.team/maven/p/skija/maven>` repository instead of bintray. At least this is on <https://github.com/JetBrains/skija> page

Also, wrong Ilya mention :)

Wasn't Skija (<https://github.com/JetBrains/skija>) was more-or-less folded into Skiko, probably any references to Skija there should be rewritten to point to Skiko instead?

Also, I'm pretty sure that experimental CEF support was ever fully built out, and certainly it isn't being maintained at the moment.  It might give you some hints as to how to set it up yourself, but it's not an out-of-the-box solution, you'll need to do some implementing yourself if you want to pursue utilizing that code.

Indeed, I didn’t know. Sorry for misleading

If anyone hates himself enough to spend time on this and package it into a 3rd party library, please post it back here. I'm sure a lot of people will find it useful!

interesting project! as someone with a limited understanding of CfD’s low-level drawing capabilities, can I ask if this kind of thing (if it were functional) would have the same Z-index issue that using s SwingPanel currently has?

what I mean by that is: currently if you use a SwingPanel in your CfD app, the SwingPanel is drawn above everything else, so if you have a dropdown menu for example, that menu will be obscured by the SwingPanel where they intersect.. so I wonder would this particular CEF implementation have the same problem?

<@U3VCTDR6E> I don't pretend to be an expert on that code, so take this with a giant grain of salt, but it looks to me like the code grabs a bitmap from the CEF browser and renders it to a Compose Canvas (<https://github.com/JetBrains/compose-jb/blob/master/experimental/cef/src/main/kotlin/org/jetbrains/compose/desktop/browser/BrowserSlicer.kt#L291>).  If my reading of the code is correct, this means the image is painted directly by Compose, so there would NOT be any layering issues.

well.. consider my interest piqued :thinking_face:

I wonder how performant it could be drawing a bitmap like this.

<@U1ZQ36CJD> Probably shouldn't be too bad, especially if the bitmap operations point to GPU buffers (I have no idea if they do in this particular implementation).  Most of the cost for a web browser is going to be parsing+layout+painting of individual DOM nodes.  Once you have all those nodes painted into the CEF buffer, copying the output buffer from one canvas to another can be a shockingly cheap operation.

Of course, it can also be slow if the operation involves serializing across the CPU instead of just referencing GPU buffers (I don't know how it's currently implemented, I'm not familiar with that code).  Even in such a case, I'd expect web-animations to stutter, but rendering a page of content should still be reasonably performant.

You could also try using Swing+JavaFX WebView node.

That's relatively easy to package, at least.