Conversation
|
🚨 Performance Regression Detected! 🚨 Some benchmarks have worsened in this PR. |
...ing/kmp/androidMain/kotlin/io/openmobilemaps/mapscore/kmp/KMAlphaInstancedShaderInterface.kt
Outdated
Show resolved
Hide resolved
|
|
||
| actual fun asShaderProgramInterface(): KMShaderProgramInterface { | ||
| val result = native.asShaderProgramInterface() | ||
| return requireNotNull((result as io.openmobilemaps.mapscore.shared.graphics.shader.ShaderProgramInterface)).asKmp() |
There was a problem hiding this comment.
This cast would be unnecessary => return result.asKmp(). But asKmp() is defined on the KMP interfaces, so we'd need to create and return a KMShaderInterface with: KMShaderProgramInterface(native.asShaderProgramInterface()).
I.e. returning kmp interfaces is wrapping the native object.
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: ecaeb74408
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
|
|
||
| plugins { | ||
| id("org.jetbrains.kotlin.multiplatform") version "2.3.0" | ||
| id("com.android.library") version "8.13.2" |
There was a problem hiding this comment.
Skip Android plugin for iOS-only Gradle invocations
The script computes isIosOnlyInvocation to support iOS-only runs, but com.android.library is still applied unconditionally, which forces Android plugin configuration even when only iOS tasks are requested. In environments that do not have an Android SDK configured (a common iOS CI setup), this causes configuration-time failure before any iOS task can execute, so the iOS-only path is not actually usable.
Useful? React with 👍 / 👎.
| @@ -0,0 +1,3 @@ | |||
| package io.openmobilemaps.mapscore.kmp | |||
|
|
|||
| expect abstract class KMDataRef | |||
There was a problem hiding this comment.
Provide common constructors/accessors for KMDataRef
KMDataRef is introduced as an opaque expect abstract class with no common API, but common interfaces now expose it in signatures (for example KMDataLoaderResult.data and async loader callbacks). This makes shared commonMain implementations unable to construct or read data payloads without platform-specific code, which effectively breaks common loader implementations; the type needs common creation/read helpers (e.g. byte-array conversion) or a usable common contract.
Useful? React with 👍 / 👎.
No description provided.