In the context of <https://github.com/JetBrains/sk...

# compose-desktop

[Kirill Grouchnikov]

In the context of https://github.com/JetBrains/skiko/pull/150 which is titled "Remove Skija, prepare for truly MPP Skiko", can the "Remove Skija" part be clarified a bit? Right now I've started to lean more on Skia (through Skija), primarily in the area of dynamic filtering and texture generation. Is that dependency eventually planned to go away in Compose Desktop?

[Kirill Grouchnikov]

Or maybe everything that is right now in Skija will now be in Skiko, including the Java / Kotlin bindings to the whole of Skia API surface?

[olonho]

yes, we'll no longer depend on Skija, being Java library, code for Skia bindings planned to be fully common between targets and written in Kotlin only

[Kirill Grouchnikov]

Do you plan to have the whole of Skia exposed in Skiko, or only the minimal subset needed for Compose MPP?

[Kirill Grouchnikov]

And perhaps a related question - would Skiko be considered a part of Compose Desktop API surface in terms of compatibility between releases, or will that be treated as internal implementation details? The reason I'm asking is that I'd like to know if I can plan on using Skia features directly beyond what is exposed by Compose APIs in canvas, image bitmap, etc.

[Kirill Grouchnikov]

This is a sample usage - where I create Compose's ColorFilter by using Skia's SkTableColorFilter.MakeARGB exposed by Skija. If this is subject to be removed at any point in time, I'd love to understand the longer-term solution on doing things that are not directly available in core Compose / Compose Desktop.

[Sergey Y.]

maybe this is a preparation for iOS target 👀

[olonho]

Whole API surface that used to be in Skija to be supported

[Kirill Grouchnikov]

That sounds great. This is what I'm exploring - creating textures like Perlin noise or brushed metal with Skija (soon Skiko)

[Igor Demin]

And perhaps a related question - would Skiko be considered a part of Compose Desktop API surface in terms of compatibility between releases

But we not sure, that it will compatible between releases, as Skia itself not always compatible between releases. If I am not mistaken, for backward compatibility they usually add some compilation constant SK_SUPPORT_LEGACY_*. If we build with such constants, then probably, skiko bindings will be backward-compatible, but at some point Skia removes legacy code 🤔

And if I understand correctly our plans, Skia bindings still not be stable with CfD 1.0, and we probably mark experimental all compose functions which expose skia classes (canvas.nativeCanvas, asDesktopBitmap, etc).

[Kirill Grouchnikov]

@Igor Demin - just tagged you in https://github.com/JetBrains/skija/issues/128 to request adding Perlin noise shaders via Skija / Skiko.

[Igor Demin]

I would love to have this Shader in skiko. If we won't find time to implement it ourselves, we can find time to review a PR into skiko with it 🙂 .

[Kirill Grouchnikov]

Sure thing. I'll take a look when that big change is merged.

[SrSouza]

we'll no longer depend on Skija

What this actually means? Skiko will still use Skija in JVM target and in Native/WASM target using directly native Skia library ? or Skiko will also reimplement the hole Skia binding also for JVM target?

[Kirill Grouchnikov]

My understanding is that Skija was providing Java bindings to a certain subset of Skia. And Skiko is doing the same, but Kotlin bindings instead. Same APIs, just different bindings. Probably Skija at some point will be marked as obsolete then.

[Kirill Grouchnikov]

https://github.com/JetBrains/skiko/pull/165/files @Igor Demin

[olonho]

Skija is no more starting with Skiko 0.4.0