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

Add Api trait for hooking into Instance and Device creation #7700

Closed
wants to merge 2 commits into from

Conversation

geieredgar
Copy link
Contributor

Objective

Solution

  • I've added an Api trait and corresponding RenderApi resource that can be inserted before adding the RenderPlugin to gain control over wgpu Instance, Surface, Adapter, Device, and Queue creation.
  • A RenderApi using DefaultApi is inserted automatically at RenderPlugin build time, when a RenderApi is missing.
  • DefaultApi uses the same wgpu functions and methods that were used before this change.

@github-actions
Copy link
Contributor

Example alien_cake_addict failed to run, please try running it locally and check the result.

@SpecificProtagonist
Copy link
Contributor

I believe bevy is moving away from using resources to configure plugins, e.g. WindowPlugin used to be configured by a WindowSettings resource but now just has extra fields. So RenderAPIshould probably just be a field on RenderPlugin.

@geieredgar
Copy link
Contributor Author

I would generally agree with you, but there are several reasons why I didn't do that:

  1. This API will and should only be used by those who really need it. I didn't want to break existing users for this, which adding a field to RenderPlugin would do.
  2. The RenderApi isn't solely used during initialization, but also when a surface is recreated. But I am actually not sure if surface creation should be customized. I have written this because I worked on an personal hobby renderer/game engine and I now want to integrate it into bevy and also reuse the RenderPlugin. But I also want to use some modern and largely unsupported features like raytracing, which wgpu does not support directly.
  3. As long as RenderApi needs to stay around, due to the nature of Plugin being immutable during build time, this would require either an ugly hack like in Add support for adding custom log layers #7682 or using Arc instead of Box. However with Box we can save an extra allocation, because types implementing Api will most likely be zero sized.
  4. If Allow tuples in add_plugins. #7687 is merged, we could provide an API like this:
impl RenderPlugin {
    pub fn with_api(self, api: impl Api) -> impl FnOnce(&mut App) -> Self {
        |app| {
            app.insert_resource(RenderApi(Box::new(api)));
            self
        }
    }
}

fn main() {
    App::new().add_plugin(RenderPlugin::default().with_api(CustomApi)).run();
}

@alice-i-cecile alice-i-cecile added A-Rendering Drawing game state to the screen C-Usability A simple quality-of-life change that makes Bevy easier to use labels Feb 16, 2023
@alice-i-cecile
Copy link
Member

This API will and should only be used by those who really need it. I didn't want to break existing users for this, which adding a field to RenderPlugin would do.

I would expect only the folks doing strange things with rendering already would be broken by this, so I don't think this is a concern.

@NthTensor
Copy link
Contributor

This is listed as superseded in the Triage Doc. If no one disagrees, I propose we close this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-Rendering Drawing game state to the screen C-Usability A simple quality-of-life change that makes Bevy easier to use
Projects
Status: Done
Development

Successfully merging this pull request may close these issues.

Improve control over initialization of render plugin
4 participants