Repository navigation
Extract skiko platform code into separate module - #1292
Hubert Błaszczyk (hub-bla) wants to merge 14 commits into
Conversation
ca727bc to
660f7ae
Compare
098c342 to
03108b0
Compare
03108b0 to
c41b90c
Compare
94198bd to
9218f96
Compare
Igor Demin (igordmn)
left a comment
There was a problem hiding this comment.
Only skiko/README.md needs to be updated
73c1bbc to
8f04872
Compare
|
Please adopt the new changes from |
8f04872 to
4b52e55
Compare
cfc2fcc to
58b3e65
Compare
58b3e65 to
b80f7ce
Compare
…initializeCAccessible
b80f7ce to
ecf4654
Compare
Igor Demin (igordmn)
left a comment
There was a problem hiding this comment.
Found new issues with AI help. Some are not trivial, but they might cause Major/Critical regressions, so it is better to check.
| @@ -115,9 +115,8 @@ + (instancetype)sharedCache { | |||
|
|
|||
There was a problem hiding this comment.
This file contains MetalOffscreenContext related functions. We should either move them back to the core library, where the Kotlin class lives, or move the Kotlin class to the skiko-platform (probably we should do this, as we did with DirectXOffscreenContext).
The same for OpenGLOffscreenContext.
| #include <dxgi1_6.h> | ||
|
|
||
| // Set in JNI_OnLoad (jvmMain/cpp/common/impl/Library.cc). | ||
| extern "C" JavaVM *jvm; |
There was a problem hiding this comment.
After moving this into a new dll, all extern variables may stop working. Can you check this?
You can check it resizing a window on Windows with System.setProperty("skiko.rendering.windows.direct3DSynchronousLiveResize", "true")
If it crashes, we should find all moved extern's and fix it somehow.
| skikoArtifacts.jvmAdditionalRuntimeArtifactIdFor("angle", OS.Windows, Arch.X64), | ||
| skikoArtifacts.jvmAdditionalRuntimeArtifactIdFor("angle", OS.Windows, Arch.Arm64), |
There was a problem hiding this comment.
skikoArtifacts.jvmAdditionalRuntimeArtifactIdFor("angle", OS.Windows, Arch.X64),
They seem no longer exist? If so, we should remove these lines
| val commonMain by getting { | ||
| dependencies { | ||
| implementation(libs.skiko) | ||
| implementation(libs.skiko.platform) |
There was a problem hiding this comment.
Probably we need to add it to benchmarks too. Desktop compilation may fail because it imports DirectXOffscreenContext
There was a problem hiding this comment.
This test uses Library.load(), we should probably replace it by PlatformLibrary.load()
| val coreProject = project(":") | ||
|
|
||
| val platformDependencies: SkikoDependencyScope.() -> Unit = { | ||
| dependsOnCore() |
There was a problem hiding this comment.
There is a hypothetical issue for an important Desktop use-case (it might exists in real plugins right now). Not sure if it is real, but worth to check (see an old IntelliJ plugin example)
IntelliJ plugin A uses Skiko 0.100.0
IntelliJ plugin B uses Skiko 0.102.0
skiko-platform 0.100.0, directXRenderer.cc calls throwJavaRenderExceptionByExceptionCode, which is inside skiko 0.100.0
skiko-platform 0.102.0, directXRenderer.cc calls renamed throwJavaRenderExceptionByException, which is inside skiko 0.102.0
But skiko-platform 0.102.0 is linked against a name skiko-windows-x64, and if we have an old Skiko already loaded, it might be linked against 0.100.0 and we have a crash.
We have a fix for it for System.load, but it probably doesn't work for build-time linking
| implementation("org.jetbrains.runtime:jbr-api:1.5.0") | ||
| if (System.getProperty("os.name").startsWith("Win")) { | ||
| implementation("org.jetbrains.skiko:skiko-awt-runtime-angle-$target:$version") | ||
| implementation("org.jetbrains.skiko:skiko-platform-awt-runtime-angle-$target:$version") |
There was a problem hiding this comment.
We should update the doc for val renderingAngleEnabled: Boolean
|
|
||
| private val platformLoader = LibraryLoader( | ||
| name = "skiko-platform-$hostId", | ||
| init = { Setup.init() }, |
There was a problem hiding this comment.
| init = { Setup.init() }, | |
| init = { Setup.init() }, | |
| cls = PlatformLibrary::class.java, |
should we pass it and use here?
private fun getModuleResourceAsStream(resourceName: String) =
Library::class.java.classLoader.getResourceAsStream(resourceName)
There was a problem hiding this comment.
We move classes into another module, but don't change its package to org.jetbrains.skiko.platform, so both modules use name org.jetbrains.skiko.
For compatibility reasons, I would keep it this way, but can it cause issues with JPMS? Can it cause issues with planned work in #1323 (comment)?
This branch introduces a new
skiko-renderingmodule that separates platform rendering integration from the core skiko library.The new module owns the higher-level rendering infrastructure, including SkiaLayer, frame dispatching, render delegates, AWT/Swing integration, platform renderers, ANGLE support.
Fixes SKIKO-1189