Don't require an instance of Renderer for updating/layouting

[Drakulix]

Hello 👋,
I am developing smithay a wayland compositor framework and I was looking into implementing an adapter for iced, so that it could be used for example for shell-components.

I was thus looking at the UserInterface struct for wiring up iced and was a little surprised to see, that the build- and update-methods require an instance of the used Renderer.

After digging around in the source code the reasoning for this seems to be mostly the layouting-code. E.g. the Image-widget is using the Renderer to query dimensions.
The problem with that for me is, that smithay might have multiple instances of renderers. Not necessarily different ones, we are (mostly) not mixing graphic apis, but e.g. on multi-gpu systems, users might want one renderer per GPU. When processing input-events, I cannot just pick any renderer, I don't even know, which one does end up being selected for rendering.

Overall iced seems to be build around the assumption, that there is only one instance of a renderer and that preferably is also constant over the lifetime of the program. This also means, that Widgets are able to store their state as GPU resources, which also doesn't really work for my use-case. I would also personally argue, that the layout/update code should be independent of the renderer in use, that makes a better API imo and will also ease providing fallback renderers at runtime in the future instead of having to select a renderer by feature gates.

I would like to lift this limitation, is there interest in removing the Renderer argument from the layouting code and getting rid of any gpu resources in the widgets? (Textures should be cached for each renderer instance.) If so, I would be interested in contributing this change. Is there a formal process to do that?

[13r0ck]

Is there a formal process to do that?

All formal requests can be made at https://github.com/iced-rs/rfcs

Posting a link to the rfc on the discord under #discussions is probably a good idea too

[13r0ck]

From Hecrj on the Iced discord
https://discord.com/channels/628993209984614400/1024013540396371998/1025108282697842718

Event processing and layouting are inherently coupled to rendering. For instance, text layouting and editing (e.g. TextInput) need to know how and where the text is being presented on screen.
The Renderer type you provide to widgets doesn't necessarily have to be the type that actually contains the rendering logic.
But it can be just a type that provides text layouting capabilites and records drawing operations.
That is actually what a Renderer is behind the scenes: https://github.com/iced-rs/iced/blob/master/graphics/src/renderer.rs
The actual drawing and presentation is performed by the Compositor: https://github.com/iced-rs/iced/blob/master/graphics/src/window/compositor.rs
So maybe you just need a new implementation of Compositor?
And maybe a new implementation of Renderer.