Kirill Grouchnikov09/02/2021, 6:28 PM
olonho09/02/2021, 6:45 PM
Kirill Grouchnikov09/02/2021, 7:00 PM
by using Skia's
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.09/02/2021, 7:18 PM
olonho09/02/2021, 7:30 PM
Kirill Grouchnikov09/02/2021, 9:09 PM
Igor Demin09/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 releasesBut 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 Grouchnikov09/03/2021, 5:45 PM
Igor Demin09/03/2021, 5:54 PM
Kirill Grouchnikov09/03/2021, 6:17 PM
SrSouza09/03/2021, 7:14 PM
we'll no longer depend on SkijaWhat 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 Grouchnikov09/03/2021, 7:28 PM
olonho09/03/2021, 11:29 PM