Proposal: Custom high-performance rendering item

Feature Description

Support custom Slint items that can perform high-performance rendering directly through the active Slint renderer.

The custom item should participate in Slint's normal rendering pipeline, including transforms, clipping, scaling and dirty-region handling, while allowing application code to perform the actual drawing using the active renderer's rendering context.

The API should remain renderer-agnostic. I am not proposing a new universal 2D drawing API; the actual drawing should use the capabilities of the active renderer (for example, a Skia canvas when using the Skia renderer).

I would like to discuss the appropriate API and architecture before implementing an upstream PR.

Product Impact

I am building a cross-platform C++ schematic editor with Slint.

The application needs a highly interactive canvas containing potentially thousands of graphical elements such as wires, symbols, pins, labels, grid elements and selection highlights. These elements need to be redrawn continuously while the user pans, zooms, selects and edits the schematic.

Using individual Slint items or paths for all of these elements would introduce unnecessary UI-item overhead. Rendering the canvas to an Image would also introduce an unnecessary intermediate rendering/copying step.

A custom rendering item would allow Slint to continue handling the UI, layout, input and item hierarchy while the application handles high-performance canvas rendering through the same renderer used by Slint.

This is important for the product rather than a nice-to-have feature. Without this capability, the application needs to maintain a separate rendering mechanism or use approaches that are not appropriate for a large, highly interactive schematic canvas.

One thing we usually recommend is to use an Image with a texture

Both existing routes have C++ examples:

examples/opengl_texture renders into your own FBO and displays it as an Image, which participates in layout, z-order, clipping and transforms like any other element. See Image::create_from_borrowed_gl_texture.
examples/opengl_underlay draws with raw OpenGL beneath the scene via Window::set_rendering_notifier.

So does that fit your usecase, or were you thinking something different?
Could you elaborate a bit more on the specifics and what kind of API you are thinking about?

And if you're up for an experiment, you can try out the simon/vulkan-cpp branch, which adds experimental API to import vulkan textures from C++.

One thing we usually recommend is to use an Image with a texture

Both existing routes have C++ examples:

examples/opengl_texture renders into your own FBO and displays it as an Image, which participates in layout, z-order, clipping and transforms like any other element. See Image::create_from_borrowed_gl_texture.

examples/opengl_underlay draws with raw OpenGL beneath the scene via Window::set_rendering_notifier.

So does that fit your usecase, or were you thinking something different? Could you elaborate a bit more on the specifics and what kind of API you are thinking about?

Thanks, that's helpful. I was aware of both approaches, but my use case is somewhat different.

The Image + texture approach works well when the application renders into its own texture/FBO and then hands that texture to Slint. For my use case, I'd like to avoid that extra render target/boundary. The schematic canvas is continuously and interactively rendered, and I'd like the application renderer to draw directly into the rendering context that Slint is already using for that item.

The OpenGL rendering notifier is also not quite what I'm looking for. I don't want a separate underlay/overlay rendering stage, and I don't want to make the solution dependent on OpenGL. In particular, OpenGL is deprecated on macOS, so I would prefer not to build a new cross-platform solution around an API that is already deprecated on one of the target platforms.

One of the reasons I chose Slint is that its renderers already provide the appropriate native graphics backend on each platform. I'd like the custom rendering to take advantage of that rather than introducing another rendering path or requiring the application to manage platform-specific graphics surfaces.

What I'm envisioning is roughly:

Slint item tree
    |
    +-- CustomCanvas item
           |
           +-- Slint handles layout / clipping / transforms / dirty regions
           |
           +-- application render callback
                  |
                  +-- active renderer's drawing context

The important part is that the last component should be renderer-specific rather than defining a new universal drawing API. For example, with the Skia renderer it could be the existing SkCanvas, while another renderer could provide its own appropriate context.

I don't have a fixed API design yet. My main question with this issue is whether Slint would be interested in such a rendering extension point, and if so, what API shape you would consider appropriate.

The schematic editor is the motivating use case: thousands of dynamic wires, symbols, text, selections, etc., where creating a Slint item/path for every primitive or rendering a separate texture every frame isn't an ideal architecture.

And if you're up for an experiment, you can try out the simon/vulkan-cpp branch, which adds experimental API to import vulkan textures from C++.

Thanks! I hadn't seen the simon/vulkan-cpp branch.

I think this is still similar to the Image and OpenGL approaches, though: the application performs the rendering separately and effectively sends Slint a "screenshot" (a rendered texture) of what should be displayed.

What I'm looking for is slightly different: having a custom Slint item that participates directly in Slint's existing rendering path, with Slint continuing to own the renderer/backend and the application providing the actual drawing for that item.

That distinction is important for my use case because the canvas is highly dynamic and continuously rendered. I want to avoid introducing a separate rendering target and then transferring/importing the result back into Slint.

Also, Vulkan on macOS isn't a native graphics API and requires a portability layer such as MoltenVK. Since Slint already has platform-appropriate renderer backends, I'd prefer the custom rendering to operate through the renderer Slint is already using rather than introducing another graphics path.

Just following up on this proposal.

If this type of custom rendering extension point is something you would consider accepting upstream, I'd be happy to work on a PR and discuss the API/architecture with you.

Before investing in an implementation, I'd mainly like to understand whether this is a direction the Slint project would be willing to merge. My goal is to avoid maintaining a long-term fork of Slint for this functionality.

If the general approach makes sense, I'm happy to work with you on the API shape and implementation details.

Similar requirements here.
Evaluating slint for our new commercial application, windows 10/11 target first.

And if you're up for an experiment, you can try out the simon/vulkan-cpp branch, which adds experimental API to import vulkan textures from C++.

Thanks! I hadn't seen the simon/vulkan-cpp branch.

I think this is still similar to the Image and OpenGL approaches, though: the application performs the rendering separately and effectively sends Slint a "screenshot" (a rendered texture) of what should be displayed.

What I'm looking for is slightly different: having a custom Slint item that participates directly in Slint's existing rendering path, with Slint continuing to own the renderer/backend and the application providing the actual drawing for that item.

That distinction is important for my use case because the canvas is highly dynamic and continuously rendered. I want to avoid introducing a separate rendering target and then transferring/importing the result back into Slint.

Also, Vulkan on macOS isn't a native graphics API and requires a portability layer such as MoltenVK. Since Slint already has platform-appropriate renderer backends, I'd prefer the custom rendering to operate through the renderer Slint is already using rather than introducing another graphics path.

Suppose we had a custom rendering API. What would this API look like in your use-case? Are you looking for a high-level (2D canvas) API? Or do you need access to metal/dx12/vulkan and the ability to submit render passes to the surface texture?

Similar requirements here. Evaluating slint for our new commercial application, windows 10/11 target first.

For Windows, what kind of rendering API are you looking for?

11. > > And if you're up for an experiment, you can try out the simon/vulkan-cpp branch, which adds experimental API to import vulkan textures from C++.
>
>
> Thanks! I hadn't seen the simon/vulkan-cpp branch.
> I think this is still similar to the Image and OpenGL approaches, though: the application performs the rendering separately and effectively sends Slint a "screenshot" (a rendered texture) of what should be displayed.
> What I'm looking for is slightly different: having a custom Slint item that participates directly in Slint's existing rendering path, with Slint continuing to own the renderer/backend and the application providing the actual drawing for that item.
> That distinction is important for my use case because the canvas is highly dynamic and continuously rendered. I want to avoid introducing a separate rendering target and then transferring/importing the result back into Slint.
> Also, Vulkan on macOS isn't a native graphics API and requires a portability layer such as MoltenVK. Since Slint already has platform-appropriate renderer backends, I'd prefer the custom rendering to operate through the renderer Slint is already using rather than introducing another graphics path.
 Suppose we had a custom rendering API. What would this API look like in your use-case? Are you looking for a high-level (2D canvas) API? Or do you need access to metal/dx12/vulkan and the ability to submit render passes to the surface texture?

Thanks for asking. For my use case, I'm looking for a high-level 2D drawing API, specifically access to the active renderer's existing drawing context, rather than direct access to Metal/DX12/Vulkan or the ability to submit native render passes.

I'm building a schematic editor, where the canvas can contain thousands of dynamic elements: wires, symbols, pins, labels, junctions, selection highlights, and so on. I want to render these efficiently in application code without creating a separate Slint item or Path for every primitive.

Ideally, this would be a custom item in Slint's normal rendering pipeline. Slint would continue to handle the item tree, layout, transforms, clipping, scaling, and dirty-region processing, while the item would receive the active renderer's drawing context for its own rendering.

For example, with the Skia renderer, this could expose the existing SkCanvas for the duration of the render callback. If another renderer is active, it could provide its corresponding 2D drawing context. I'm not proposing a new universal drawing API; the drawing context itself could remain renderer-specific.

I'd prefer this over native graphics API access because I want Slint to retain responsibility for the platform-specific backend and surface management. I'd also prefer it over rendering to a separate texture and passing that to an Image, since that introduces a separate rendering target and integration boundary.

Navigation Menu

Repository navigation

Proposal: Custom high-performance rendering item #13495

Feature Description

Product Impact

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Proposal: Custom high-performance rendering item #13495

Description

Feature Description

Product Impact

Activity

ogoffart commented on Sep 19, 2026

tronical commented on Sep 19, 2026

rjbaucells commented on Sep 19, 2026

rjbaucells commented on Sep 19, 2026

rjbaucells commented on Sep 28, 2026

alexis-idigo commented on Oct 8, 2026

tronical commented on Oct 8, 2026

tronical commented on Oct 8, 2026

rjbaucells commented on Oct 17, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions