Open dhardy opened 2 years ago
Lets list some requirements of the API:
tiny-skia
looks great but is CPU-onlyAll of these dependencies support text rendering, which we don't really need. (If we did have another text-drawing option, we should at least support shared font discovery and config, if not also shared loading. This is already the case with usvg
, used for the CPU-rendered Svg
widget.)
Note that the above libraries are mostly concerned with drawing text, but may not support shaping, wrapping, pointer-coordinate-to-glyph-index translation, and bi-directional text. For these reasons they will not replace KAS-text, thus are at best an alternative for fancy text transformations.
Note also that it would be desirable to offer some transformations for text drawn by KAS-text (at least 90° rotation).
All of the above have some vaguely similar subset of functionality around paths. We could build our own API (possibly a clone of one of the above), and support using multiple of the above libraries as the implementation: tiny-skia
for CPU-only, Lyon for WGPU, femtovg for OpenGL, maybe also Kurbo (Piet's component for curves and shapes).
Probably we would need to make various features of the API optional (likely desired anyway).
This would be a little more work than directly using one of these APIs, but appears to be the only option meeting our goals.
The drawing API (#17) is still quite bad. Existing features:
Potentially desired features:
A modular design would be useful, potentially run-time modular, allowing themes to query supported features and skip or use alternatives for unsupported things (e.g. skip shadows, use simpler shapes).
Using an existing API would be great. Some ideas:
Some of these may be a little lower level than desired in many cases.
Possible revision to KAS's current API:
norm
parameters into a "paint style" parameterPaintStyle
enum; this potentially allows run-time fall-back