In the context of

Question

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 · Answer

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 · Answer

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 · Answer

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

Kirill Grouchnikov · Answer

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 · Answer

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. · Answer

maybe this is a preparation for iOS target eyes

olonho · Answer

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

Kirill Grouchnikov · Answer

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

Igor Demin · Answer

gt 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 thinking face 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 · Answer

< Igor Demin> just tagged you in to request adding Perlin noise shaders via Skija Skiko

Igor Demin · Answer

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 slightly smiling face

Kirill Grouchnikov · Answer

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

SrSouza · Answer

gt 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 · Answer

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 · Answer

< Igor Demin>

olonho · Answer

Skija is no more starting with Skiko 0 4 0