-
Notifications
You must be signed in to change notification settings - Fork 148
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
Better API for already GPU-resident images #664
Comments
What does this mean? I thought Vello was heavily dependent on wgpu. |
We have several users/potential users who cannot use
|
As I am the second kind, what should I do now? |
The situation has changed somewhat since that was written; we've re-evaluated the recording API, as it was not being used at all, and it adds a lot of complexity with unclear semantics. Currently your options would be:
|
Actually I think it would be enough for wgpu to support some kind of concept of "external textures" (something like this already exists in web), that would allow loading wgpu::Texture from different wgpu::Device (as external texture). This is something we would want in servo too (but it's very low priority). EDIT: Here are relevant links to wgpu: gfx-rs/wgpu#2320, gfx-rs/wgpu#3145, gfx-rs/wgpu#4067 |
There have been repeated requests for supporting using a wgpu
Texture
within a VelloScene
, such as #660.We did implement a targeted fix for this in #636.
In #gpu > vello adding wgpu texture buffers to scene, Chad suggested a new variant of Brush for this use case.
I think that is likely to be the best API, due to the other constraints on the
Scene
API (namely that we have chosen to make it independent of wgpu, for any consumers who use Vello without using wgpu directly)The text was updated successfully, but these errors were encountered: