4 ms·
> Not so, SWT uses its own bindings to the OS's native GUI toolkit, using JNI. A right, I forgot that, thanks. What's the SWT approach to use cases where you b
by usrusr 6y ago
> Not so, SWT uses its own bindings to the OS's native GUI toolkit, using JNI.
A right, I forgot that, thanks. What's the SWT approach to use cases where you basically want a pixel canvas? Falling back to AWT on a surface allocated from the native API or its own facade for native APIs?
In any case this property of SWT kind of explains the omission, SWT happens on a level that is two layers away from skija in the stack Jetbrains are building for Compose Desktop.
- MaxBarraclough 6y ago> What's the SWT approach to use cases where you basically want a pixel canvas? Falling back to AWT on a surface allocated from the native API or its own facade for native APIs? I don't think SWT makes any use of AWT, I believe it does the latter. > SWT happens on a level that is two layers away from skija in the stack Jetbrains are building for Compose Desktop The article is making the case for a whole new GUI toolkit for Java, without making a persuasive case against JavaFX (I'm not convinced that its performance is a problem), and without mentioning SWT, the foremost 'unofficial' desktop GUI toolkit for Java. Skija may have its merits as a platform for 2D graphics, but that's not the point. Incidentally, the article's title is misleading. It's about GUI toolkits, not graphics libraries.
- usrusr 6y agoThe whole new GUI toolkit in question is Compose Native and that's not entirely new (only the desktop part is). Literally millions of Android devs would already feel more at home with it than with any other desktop UI toolkit. Maybe it's a bit dishonest to present Skija as if it was made for any other reason than to enable Compose Desktop, but it's very laudable to have the ambition to be more than an enabling component of that.