eclipse-platform
SkiaCanvas: a GC implementation with GPU support
We develop a "Skia Canvas for SWT" that utilizes the Skia 2D graphics library for drawing on the canvas in SWT. As Java binding we use Skija. The code currently under development can be found here: https://github.com/swt-initiative31/skija-canvas This feature has several advantages:
- Skia is an established 2D graphics library that can be used across multiple operating systems.
- Hardware acceleration is supported for various backends, including OpenGL, Vulkan, Metal, and DirectX12.
- A raster implementation is also available.
- There are two Java bindings: Skija and Skiko. If one binding is deprecated, we can switch to the other.
- big parts of this feature can be developed OS independent
To achieve this, a new fragment, org.eclipse.swt.skia, will be created next to the org.eclipse.swt plugin in the SWT repository: https://github.com/eclipse-platform/eclipse.platform.swt. All jar dependencies for Skija (these include Skia) will reside in this new plugin. However, some code modifications to the SWT plugin and its fragments are necessary.
We have discussed the API with application developers, who prefer making minimal modifications to their code to use the Skia canvas.
They favor an API resembling the following:
SkiaConfiguration.applyRasterCanvas(); // Configures to Skia Raster Canvas. Canvas c = new Canvas(parent, SWT.NONE); // This canvas will use a Skia delegate, directing specific drawing calls to Skia. SkiaConfiguration.resetCanvasConfiguration(); // Subsequent canvases will revert to the classical canvas.
This approach removes the necessity for modifications to class hierarchies. However, if the canvas configuration isn't reset, all future canvases will be Skia canvases. Conversely, application developers can opt to switch entirely to Skia canvases. This configuration method offers flexibility for multiple scenarios.
For the drawing events, the class GC will be refactored from a final class to a sealed class, which is extended by the final class GCExtension. This GCExtension delegates all drawing commands with an interface to SkiaGC, which interprets them for Skia. Thus, application developers might not even notice a difference between drawing events with the classical GC and an embedded "SkiaGC."
Please let us know whether this concept is feasible for you.
This project requires much resources, so we would like to know whether this development offers advantages for you and whether it can be integrated into the SWT master branch.
And of course nothing in this design is final, it is a way to integrate Skia in SWT in order to enhance the canvas performance for application developers.
So let us know whether this design can be improved.
The more natural SWT way would be "new Canvas(parent, SWT.SKIA)" . That is the way used by Browser widget to allow selecting underlying backend (e.g. IE vs Edge).
IIRC SWT.EDGE could also be set as default. This would also be nice in case you go for @akurtakov suggestions.
Assuming that this change would result in faster rendering for custom drawn widgets, like NatTable or GEF based UIs your suggestion would be a very desired improvement in SWT and GEF.
In additional to that it would be desired to have better control about drawing in SWT, e.g. moving from int to floats to support sub-pixel drawing but I assume that is another discussion. I just mention that because AFAIK Skia is float based so the drawing with it would be more natural if SWT would support this too.
cc @fipro78 @azoitl
Of course, we can use SWT.SKIA.
But currently there are two modes for the skia drawing: Raster (CPU+RAM) and OpenGL. Potentially possible for the future are also Vulkan, Metal and DirectX12.
With a separated configuration we can be more specific. But of course, with SWT.SKIA, we can just chose the most suitable option.
@vogella For the future float based drawings would be great. At the moment i have the intention to make the Drawing engine switchable between the existing GCs and the Skia GC implementation. Then application developers can just try the Skia Canvas and switch back if something does not work.
For floats we need a new API.
I want to show the current state of the SkiaCanvas in the Eclipse IDE - Developers Community Call on 23.10.25. If you are interested.
@DenisUngemach Would you please make the presentation you used on the call public? I would like to share it a bit.
@DenisUngemach Would you please make the presentation you used on the call public? I would like to share it a bit.
Sorry for the delay...
Any news on this? I think a lot of users should be very happy to have a Skia based canvas.
Here are some key points:
- Feature Scope: I have reviewed the entire GC API, and all features can be implemented. Proof-of-concept implementations exist for each feature.
- Capacity: As it seems, I'm currently the sole developer on this project, which is resulting in slower progress. Evaluation on Linux: I am unable to assess the performance improvements of Skia + OpenGL compared to the traditional Cairo canvas on Linux. This limitation arises from my lack of access to a Linux PC and the absence of benchmarkings. This is quite critical for me; if there's no performance benefit on Linux, the use of Skia may not be justified.
- Cross-platform Development: Developing for three operating systems is challenging, especially as a solo developer. Therefore, I prefer to concentrate on supporting Windows for the initial release, but without the evaluation on linux, this might not make sense.
If anyone is interested in contributing to the development of the Skia canvas for Linux or macOS, please feel free to contribute.
I have created an issue : https://github.com/swt-initiative31/skija-canvas/issues/53
You can checkout the branch: skia_canvas in the repo: https://github.com/swt-initiative31/skija-canvas -> Execute the maven build in order to support all necessary c-bindings. I only use the gtk3 bindings.
Then you can use the plugins just like the swt plugins. The skia snippets are in: org.eclipse.examples.skia
If you have further questions, just write it in the issue.