Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Draw API #326

Open
dhardy opened this issue Jun 8, 2022 · 2 comments
Open

Draw API #326

dhardy opened this issue Jun 8, 2022 · 2 comments

Comments

@dhardy
Copy link
Collaborator

dhardy commented Jun 8, 2022

The drawing API (#17) is still quite bad. Existing features:

  • Draw simple filled text
  • Draw text with text formatting
  • Draw images
  • Draw rectangular shapes (rect, frame)
  • Draw rounded shapes (line, oval, frame with rounded corners)
  • Draw rounded shapes with 2-colour fading (circle, rounded frame)
  • Draw rounded shapes with simple 3D-lit shading (square, oval, square-edged frame, rounded frame)

Potentially desired features:

  • Rotation (at least for text)
  • Filled paths
  • Stroked paths (with styles like dashed, etc.)
  • Drop shadows
  • Layers, blending, effects like burring, desaturation

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:

  • Skia: but it's not a Rust library and bindings such as skia-safe are incomplete
  • Piet: designed for (Druid's) UI, with several backends (Cairo, Window's Direct2D, MacOS's CoreGraphics, SVG, web) and lots of features (shapes, paths, text), this could be a good choice, although the currently supported backends are less than desired. Piet-GPU exists, together with a Vision document... it appears that this is an area of active research.
  • femtovg: OpenGL only (with a Metal backend in progress)
  • tiny-skia: CPU-only, pure Rust; already an optional dependency
  • Lyon

Some of these may be a little lower level than desired in many cases.

Possible revision to KAS's current API:

  • move colour, (relative) radius and (3D shading) norm parameters into a "paint style" parameter
  • select between square/rounded/3D-shaded styles via a PaintStyle enum; this potentially allows run-time fall-back
@dhardy
Copy link
Collaborator Author

dhardy commented Jun 10, 2022

Lets list some requirements of the API:

  • Support multiple backends: at least one good option for each major desktop/mobile platform. Skia is fine; Piet, Piet-GPU aren't there yet; femtovg isn't really either; tiny-skia looks great but is CPU-only
  • Support pure-Rust binaries (or as close as we can get): Skia fails here, as does Piet (due to Cairo dependency)

Text

All 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).

@dhardy
Copy link
Collaborator Author

dhardy commented Jun 10, 2022

Custom API over tiny-skia / femtovg / Lyon / kurbo

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant