1. 12 Sep, 2025 2 commits
  2. 11 Sep, 2025 4 commits
  3. 09 Sep, 2025 4 commits
  4. 08 Sep, 2025 1 commit
    • Shagen Ogandzhanian's avatar
      Simplify gradle web wasm build (#1089) · d65ac361
      Shagen Ogandzhanian authored
      Following changes introduced in this PR:
      * jsWasmMain and jsWasmTest sourcesets renamed to webMain and webTest
      (it causes less confusion, regarding the fact that we already have
      wasmJsMain, apart from that, this would be a standard name for this
      sourceset in webMain)
      * remove redunant resource processing (there's yet room for improvement
      though)
         * Simplify wasm task introduction
      * Remove flag for building js separately from wasm (this flag was a lie
      - we can not have separate js target)
      d65ac361
  5. 05 Sep, 2025 1 commit
  6. 26 Aug, 2025 1 commit
  7. 14 Aug, 2025 3 commits
    • Alovchin91's avatar
      Update DEVELOPMENT.md (#1086) · 2260bbe4
      Alovchin91 authored
      Update instructions for VS 2022.
      2260bbe4
    • Igor Demin's avatar
      Update DEVELOPMENT.md (VS 2022 requirement) (#1084) · e7081fad
      Igor Demin authored
      It is now required for development. Tested it locally
      e7081fad
    • Alovchin91's avatar
      ANGLE support (#1017) · eda88cdc
      Alovchin91 authored
      This change adds ANGLE renderer support to Skiko.
      
      [ANGLE project](https://chromium.googlesource.com/angle/angle)
      translates OpenGL ES API calls to the native platform's graphics API.
      This is mostly useful on Windows where ANGLE provides the Direct3D 11
      backend.
      
      Right now, there is a gap in Skiko's graphics support. On Windows ARM,
      Skia doesn't support OpenGL yet. At the same time, some GPUs, like
      Parallels or VMware virtual GPUs, don't support DirectX 12. This means
      Skiko falls back to the slow software rendering on those GPUs. ANGLE
      solves this problem by providing an easy-to-use DirectX 11 backend.
      
      In addition, ANGLE is used by Chromium-based browsers and apps, so we
      expect it to be more stable than Skia's DirectX backend.
      
      ---------
      Co-authored-by: 's avatarIgor Demin <igor.demin@jetbrains.com>
      eda88cdc
  8. 08 Aug, 2025 4 commits
  9. 21 Jul, 2025 1 commit
  10. 18 Jul, 2025 1 commit
  11. 04 Jul, 2025 1 commit
  12. 02 Jul, 2025 3 commits
  13. 13 Jun, 2025 1 commit
  14. 12 Jun, 2025 2 commits
  15. 06 Jun, 2025 2 commits
  16. 28 May, 2025 1 commit
    • Thomas Vos's avatar
      Update linux-amd64 Dockerfile to Ubuntu 20.04 (#1062) · b4f463b9
      Thomas Vos authored
      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.
      b4f463b9
  17. 27 May, 2025 1 commit
  18. 23 May, 2025 1 commit
  19. 09 May, 2025 1 commit
  20. 30 Apr, 2025 3 commits
    • Igor Demin's avatar
      Update runners to ubuntu-22.04 (docs.yml) (#1056) · 30df516c
      Igor Demin authored
      Continuation of https://github.com/JetBrains/skiko/pull/1055
      
      This runs only in master
      30df516c
    • Vladimir Kharitonov's avatar
      metal: accelerate swing rendering (#1031) · 1b7f65b7
      Vladimir Kharitonov authored
      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: 's avatarIgor Demin <igordmn@users.noreply.github.com>
      1b7f65b7
    • Igor Demin's avatar
      Update runners to ubuntu-22.04 (#1055) · e88dd9c3
      Igor Demin authored
      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.
      e88dd9c3
  21. 22 Apr, 2025 1 commit
  22. 15 Apr, 2025 1 commit
    • Clément de La Bourdonnaye's avatar
      Make configureSignAndPublishDependencies use proper android task names (#1053) · 6955c19e
      Clément de La Bourdonnaye authored
      "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.
      ```
      6955c19e