https://kotlinlang.org logo
Title
k

Kirill Grouchnikov

09/02/2021, 6:28 PM
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?
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?
o

olonho

09/02/2021, 6:45 PM
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
k

Kirill Grouchnikov

09/02/2021, 7:00 PM
Do you plan to have the whole of Skia exposed in Skiko, or only the minimal subset needed for Compose MPP?
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.
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.
s

Sergey Y.

09/02/2021, 7:18 PM
maybe this is a preparation for iOS target 👀
:kotlin-intensifies: 7
o

olonho

09/02/2021, 7:30 PM
Whole API surface that used to be in Skija to be supported
❤️ 9
k

Kirill Grouchnikov

09/02/2021, 9:09 PM
That sounds great. This is what I'm exploring - creating textures like Perlin noise or brushed metal with Skija (soon Skiko)
😍 2
i

Igor Demin

09/03/2021, 8:37 AM
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).
👍 3
k

Kirill Grouchnikov

09/03/2021, 5:45 PM
@Igor Demin - just tagged you in https://github.com/JetBrains/skija/issues/128 to request adding Perlin noise shaders via Skija / Skiko.
i

Igor Demin

09/03/2021, 5:54 PM
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 🙂 .
k

Kirill Grouchnikov

09/03/2021, 6:17 PM
Sure thing. I'll take a look when that big change is merged.
s

SrSouza

09/03/2021, 7:14 PM
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?
k

Kirill Grouchnikov

09/03/2021, 7:28 PM
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.
o

olonho

09/03/2021, 11:29 PM
Skija is no more starting with Skiko 0.4.0
👋 2