[CMP-8343](https://youtrack.jetbrains.com/issue/CMP-8343) Support
`TransformShader` in skiko implementation

Resolving TODO from
https://github.com/JetBrains/compose-multiplatform-core/pull/2171

A followup for https://github.com/JetBrains/skiko/pull/1051

This PR adds support for the linuxArm64 target. It can be cross compiled
from a Linux x64 host.

The `multistrap` package is used for downloading some required arm64
dependencies.

# Testing

GitHub run: https://github.com/Thomas-Vos/skiko/actions/runs/15261348943

Also using it in a compose app.

Needed to add `ARG DEBIAN_FRONTEND=noninteractive` so installation does
not get stuck, copied this from another Dockerfile.
Also `binutils-2.26` was missing so replaced it with `binutils`, this is
in line with the other docker files, but I am unsure if this could break
anything.

On my PC the image build is successful (using `build.sh` script). The
`run.sh` script is also successful after adapting its paths to my local
setup. Unsure about publishing.

Update linux-amd64/Dockerfile with dependencies needed for cross compiling linuxArm64 target (#1061)

https://github.com/JetBrains/skiko/pull/1051#discussion_r2107305732

This fixed
[issue](https://youtrack.jetbrains.com/issue/CMP-7405/Invalid-imports-in-skiko-to-skia-API)
for non-JVM targets.

Some of this fixes overlapped by
[this](https://github.com/JetBrains/skiko/pull/1050) and
[this](https://github.com/JetBrains/skiko/pull/1049) MR's. We could drop
then here or close that MR's at the discretion of the reviewer.

Continuation of https://github.com/JetBrains/skiko/pull/1055

This runs only in master

This PR contain:
1. Using shared metal textures with this JBR API -
[SharedTextures](https://github.com/JetBrains/JetBrainsRuntimeApi/blob/main/src/com/jetbrains/SharedTextures.java).
See `AcceleratedSwingPainter`.

2. Not ultimate, but visible improvement of the not accelerated painting
for Windows(~%25), and MacOS(~20%). Unfortunately, didn't manage to see
a positive change on Linux with XRender pipeline(about the same,
probably few percents down). With opengl pipeline it also got ~20%
faster. But currently our pipeline on linux is XRender
I got rid of make one extra copy of the raster image. See
`SoftwareSwingPainter`

`com.jetbrains:jbr-api` size is about 44kb

Benchmarks:
`Redraw` - time to prepare the offscreen image including sync, but not
including fetching texture to the CPU RAM
`Paint` - time to get the image from GPU(if needed) and draw onto
`Graphics2D`
`Total` - total time to deliver the frame

```
MetalSwingRedrawer:
Image size: 3200x2344
Test: ClocksAwt
MacBook Pro M1 Max
java2d pipeline = Metal
               Current   SoftwareSwingPainter   AcceleratedSwingPainter
FPS              66             80                      141
Redraw(ms)      7.13           7.13                     6.92
Paint(ms)       7.65           6.07                     0.006
Total(ms)      14.78          12.16                     6.92


Direct3DSwingRedrawer
Image size: 3176x2284
Dell Prescision 5570, i9-12900H + GPU Nvidia
Test: ClocksAwt
java2d pipeline = GDI
               Current   SoftwareSwingPainter
FPS              32             41
Redraw(ms)     12.58          11.57
Paint(ms)      17.43          11.54
Total(ms)      29.93          23.11


LinuxOpenGLSwingRedrawer
Image size: 3192x2230
Dell Prescision 5570, i9-12900H + GPU Nvidia
Test: ClocksAwt
java2d pipeline = XRender
               Current   SoftwareSwingPainter
FPS              24             23
Redraw(ms)     20.07          19.64
Paint(ms)      19.69          22.73
Total(ms)      39.77          42.39
```

---------
Co-authored-by: Igor Demin <igordmn@users.noreply.github.com>

The current runners fail with:

This is a scheduled Ubuntu 20.04 retirement. Ubuntu 20.04 LTS runner
will be removed on 2025-04-15. For more details,
see https://github.com/actions/runner-images/issues/11101

GitHub Actions has encountered an internal error when running your job.

feat(jvm): add GLAssembledInterface.createFromNativePointers and DirectContext.makeGLWithInterface (#1048)

Needed to enable OpenGL on Wayland (via EGL)

"AndroidRelease" should be used instead of "Android" since using the
android plugin introduces release/debug variants.

Note: `./gradlew publish -Pskiko.android.enabled=true` would still fail
with the following, but this task is as I understand not used on CI and
"build repo" seem to be a local thing.
```
> Task :publishAndroidReleasePublicationToBuildRepoRepository FAILED

FAILURE: Build failed with an exception.

* What went wrong:
A problem was found with the configuration of task ':publishAndroidReleasePublicationToBuildRepoRepository' (type 'PublishToMavenRepository').
  - Gradle detected a problem with the following location: '/Users/cdelabou/workspace/misc/skiko/skiko/build/libs/skiko-0.0.0-SNAPSHOT-javadoc.jar.asc'.
    
    Reason: Task ':publishAndroidReleasePublicationToBuildRepoRepository' uses this output of task ':signKotlinMultiplatformPublication' without declaring an explicit or implicit dependency. This can lead to incorrect results being produced, depending on what order the tasks are executed.
```

We have a situation on a Linux where a significant portion of time spent
in EDT is spent inside a `glFinish()` call.

OS: Linux bazhenov 6.11.0-19-generic #19~24.04.1-Ubuntu SMP
PREEMPT_DYNAMIC Mon Feb 17 11:51:52 UTC 2 x86_64 x86_64 x86_64 GNU/Linux
Distribution: Ubuntu 24.04
GPU: Intel Corporation AlderLake-S GT1 [8086:4680] (rev 0c) (Intel UHD
Graphics 770)
Driver: i915


![screenshot_from_2025-03-24_14-04-41](https://github.com/user-attachments/assets/a4ed84e1-d299-418e-912c-3f32b15bfaaa)

According to the
[documentation](https://registry.khronos.org/OpenGL-Refpages/gl4/html/glFinish.xhtml):

> glFinish does not return until the effects of all previously called GL
commands are complete. Such effects include all changes to GL state, all
changes to connection state, and all changes to the frame buffer
contents.

It effectively means that there is no overlap in work being done on the
CPU and GPU; we only start to prepare a new frame when we finish
rendering the previous one. It makes sense in the context of direct
draw, but AFAIK, Skiko has a swap chain of frame buffers (I assume 2?),
so `glFlush()` should be enough. Probably, we can get away without
`glFinish()`/`glFlush()` at all, because `glSwapBuffers()`, according to
the documentation, is doing `glFlush()`, but I'm not an expert.

Using `SkiaAwtSample`, I can confirm that performance is improved
significantly (in both cases first 3 FPS samples are skipped).

Before change

```
[1039125906] FPS 36 (29-63)
[1039127906] FPS 46 (29-62)
[1039129906] FPS 43 (29-64)
[1039131922] FPS 39 (29-64)
[1039133923] FPS 42 (29-65)
[1039135940] FPS 52 (29-63)
[1039137957] FPS 36 (29-62)
[1039139974] FPS 53 (29-66)
[1039142008] FPS 34 (29-63)
[1039144024] FPS 47 (30-66)
```

After change

```
[1038654097] FPS 60 (46-67)
[1038656097] FPS 60 (57-65)
[1038658114] FPS 60 (47-68)
[1038660114] FPS 60 (41-67)
[1038662114] FPS 60 (51-67)
[1038664115] FPS 60 (47-67)
[1038666115] FPS 60 (51-67)
[1038668115] FPS 60 (51-67)
[1038670127] FPS 60 (42-67)
[1038672132] FPS 60 (48-67)
```

Follows up MR #1043 that got reverted, new changes also include
corrected signature configuration

https://jetbrains.slack.com/archives/C02DDNREC77/p1744211587478839?thread_ts=1744180296.015109&cid=C02DDNREC77

- now 0.0.1-SNAPSHOT is built
- it can't be used, as it is built from any branch, not only from master

Reverts JetBrains/skiko#1043

```
./gradlew publishKotlinMultiplatformPublicationToComposeRepoRepository
```
Fails on CI

This also fixes SKIKO-934 by making the dependency between
`merge*JniLibFolders` and `unzip*` tasks explicit (the patch actually
adds too much dependencies but this should be limited to android tasks).
After this patch the android sample works from my configuration (might
be worth checking if other issues are still relevant?).

Few things to consider for review:
- I've changed versions of Gradle / AGP / Kotlin until I got something
working on both samples and library side.
- If `ANDROID_SDK_ROOT` environment variable was specified on a CI
before, it should now be `ANDROID_HOME` to work with android gradle
plugin (internal utilities will work with both).
- I've introduce some lazyness in configurations (`matching { ... }`),
as android plugin and previous code would race (android seems to declare
it's configurations quite late). If there's a better way to express it,
please let me know!

renderApi can change if there was a fallback (DIRECT3D -> OpenGL ->
Software). We need to always call it in the frame.

Noticed it during testing.

emscripten 3.1.50 supports mimalloc -
https://github.com/emscripten-core/emscripten/blob/main/ChangeLog.md#3150---112923

We want to try it.

This change will be used in Compose Multiplatform to fix
https://youtrack.jetbrains.com/issue/CMP-6589/wasm-can-not-render-tab-symbol

The difference can be seen here:
**Good**: https://fiddle.skia.org/c/24fb7ebc20eec08077d84b9fe37ceb4f -
`paraStyle.setReplaceTabCharacters(true);`
**Bad**: https://fiddle.skia.org/c/fbcb4a52786d63ed42a85d05d5472164 -
`paraStyle.setReplaceTabCharacters(false);`

Creating transparent views/renderers shouldn't disable window shadows

Context: [CMP-7752](https://youtrack.jetbrains.com/issue/CMP-7752)
Interop blending should not disable window shadows on macOS

This is needed to detect emojis in Compose Multiplatform.

Also, it looks like the native implementations of
`String.intCodePoints()` were broken. I fixed them by copying the
relevant code from Compose.

see https://youtrack.jetbrains.com/issue/CMP-7630

It's for internal usage only (for example in benchmarks).

- skikoWasmJar will include a new file - skikod8.mjs
- The new file skikod8.mjs won't be used by any actual apps (Compose
apps). The apps won't try to download it or use it.
- This file can be used by manually replace skiko.mjs usages (we'll do
it using a gradle task in benchmarks project)

___
This step is required for https://youtrack.jetbrains.com/issue/CMP-6942

My app is used a lot in the background, and I noticed high CPU usage in
the native macOS version. With this PR, CPU usage is reduced when window
is invisible by disabling drawing. This was already implemented for the
JVM, and that behaviour is now copied to native macOS. So the code is
similar to JVM parts in:
-
https://github.com/JetBrains/skiko/blob/master/skiko/src/awtMain/kotlin/org/jetbrains/skiko/redrawer/MetalRedrawer.kt
-
https://github.com/JetBrains/skiko/blob/master/skiko/src/awtMain/objectiveC/macos/MetalRedrawer.mm

The draw function is now suspend, which required moving some other
functions around. I tried to keep the implementation similar to the JVM
version.

# Testing
Tested using `./gradlew runNative` in `samples/SkiaMultiplatformSample`.
Now the CPU usage is reduced a lot when moving another (non transparent)
app over the window.

# Old behaviour


https://github.com/user-attachments/assets/60ad3398-3f44-4e2f-aca7-44a4607d0840

# New behaviour with 300ms timeout
See reduction in CPU usage when window is invisible


https://github.com/user-attachments/assets/106efdeb-0044-4411-9b26-5a6b8886ff04


# New behaviour without 300ms timeout



https://github.com/user-attachments/assets/b986548b-d7ab-497b-9ddb-5b46ca016f83

Fixes
https://youtrack.jetbrains.com/issue/CMP-7603/Fix-Maven-Central-publication
for Skiko

Just a quick fix that adds an updated library.

For a proper fix I created an issue
https://youtrack.jetbrains.com/issue/SKIKO-1003/Unify-Maven-publication-of-Skiko-with-Compose

Official Skia documentation suggests that it's [_highly
recommended_](https://skia.org/docs/user/build/#highly-recommended-build-with-clang-cl)
to build Skia with Clang-CL on Windows, and that this dramatically
improves Skia performance with Software rendering and in other areas.
This corresponds with my experience, so here it is.

Related Skia-pack PR: https://github.com/JetBrains/skia-pack/pull/64

Prerequisite: #1024

This PR is split-off from and is a prerequisite of Clang-cl PR: #1020

BreakIterator.clone() is broken on JVM and seemingly leads to a
use-after-free behaviour. Clang-cl makes this issue more visible, likely
due to address sanitisation.

Explanation why it is deleted in an internal channel:
https://jetbrains.slack.com/archives/C02DDNREC77/p1738678000232729
* `breakIteratorCloneTest` is failing with an access violation in Debug
mode with additional checks, so using it wasn't safe
* it is not used anywhere

This is a breaking change and will require bumping Skiko version to
0.9.0.

Required to fix https://youtrack.jetbrains.com/issue/CMP-7508

Test: covered by existing tests

It is a simplified adoption of Android's `RenderNode`.

```kt
/**
 * <p>RenderNode is used to build hardware accelerated rendering hierarchies. Each RenderNode
 * contains both a display list as well as a set of properties that affect the rendering of the
 * display list. RenderNodes are used internally for all Views by default and are not typically
 * used directly.</p>
 *
 * <p>RenderNodes are used to divide up the rendering content of a complex scene into smaller
 * pieces that can then be updated individually more cheaply. Updating part of the scene only needs
 * to update the display list or properties of a small number of RenderNode instead of redrawing
 * everything from scratch. A RenderNode only needs its display list re-recorded when its content
 * alone should be changed. RenderNodes can also be transformed without re-recording the display
 * list through the transform properties.</p>
 ```
 
 This is a more correct approach to make `GraphicsLayer` in Compose invalidation independently.
 - Moved drawing callback to C++ side to avoid extra interop costs
 - Switched from `SkPicture` placeholder to custom `SkDrawable` implementation

Needed to run benchmarks without vsync interference.

The code extracted from Direct3DSwingRedrawer with minimal changes.

- implementation for other API will be added when it is needed (Metal is
considered later)
- there are no plans to make commonMain abstraction in `skiko` as it is
not needed at the moment

## Testing
- manually in benchmarks with this code:
```
@OptIn(ExperimentalSkikoApi::class)
class DirectXGraphicsContext() : DesktopGraphicsContext {
    private val context = DirectXOffscreenContext()
    private var texture: DirectXOffscreenContext.Texture? = null

    override fun surface(width: Int, height: Int): Surface {
        texture?.close()
        texture = context.Texture(width, height)
        return Surface.makeFromBackendRenderTarget(
            context.directContext,
            texture!!.backendRenderTarget,
            SurfaceOrigin.TOP_LEFT,
            SurfaceColorFormat.BGRA_8888,
            ColorSpace.sRGB,
            SurfaceProps(pixelGeometry = PixelGeometry.UNKNOWN)
        ) ?: throw IllegalStateException("Can't create Surface")
    }

    override suspend fun awaitGPUCompletion() {
        texture?.waitForCompletion()
    }

    override fun close() {
        texture?.close()
        context.close()
    }
}

interface DesktopGraphicsContext : GraphicsContext, AutoCloseable
```
- new test for SkiaSwingLayer
- new test for DirectXOffscreenContext

Currently fails with
```
Error: This request has been automatically failed because it uses a deprecated version of `actions/upload-artifact: v3`. Learn more: https://github.blog/changelog/2024-04-16-deprecation-notice-v3-of-the-artifact-actions/
```

Fixes
https://youtrack.jetbrains.com/issue/SKIKO-994/Add-logging-for-rendering