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

experiment: providing a gateway for writing your own renderer through MirAL #3338

Merged
merged 9 commits into from
Apr 24, 2024

Conversation

mattkae
Copy link
Contributor

@mattkae mattkae commented Apr 19, 2024

WARNING: Highly experimental, but it works

What's new?

  • Users can now provide CustomRenderer to miral which gives them the rites to entirely replace the existing renderer
  • Although this might not be 100% percent what we want, I would be VERY interested in seeing something like this go into an "internal" headers somewhere as it would enable a lot of interesting things

@mattkae mattkae requested a review from AlanGriffiths April 19, 2024 20:46
@mattkae mattkae marked this pull request as ready for review April 19, 2024 20:46
@mattkae mattkae requested a review from a team as a code owner April 19, 2024 20:46
@mattkae mattkae changed the title Providing a gateway for writing your own renderer through MirAL experiment: providing a gateway for writing your own renderer through MirAL Apr 19, 2024
Copy link

codecov bot commented Apr 19, 2024

Codecov Report

Attention: Patch coverage is 0% with 9 lines in your changes are missing coverage. Please review.

Project coverage is 77.33%. Comparing base (3293097) to head (d65e889).
Report is 3 commits behind head on main.

❗ Current head d65e889 differs from pull request most recent head 7b28349. Consider uploading reports for the commit 7b28349 to get more accurate results

Files Patch % Lines
src/miral/custom_renderer.cpp 0.00% 9 Missing ⚠️
Additional details and impacted files
@@            Coverage Diff             @@
##             main    #3338      +/-   ##
==========================================
- Coverage   77.33%   77.33%   -0.01%     
==========================================
  Files        1062     1063       +1     
  Lines       67817    67826       +9     
==========================================
+ Hits        52449    52451       +2     
- Misses      15368    15375       +7     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

Copy link
Collaborator

@AlanGriffiths AlanGriffiths left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd tweak the MirAL API slightly to be more consistent with other MirAL APIs, but I don't think there's anything problematic about the semantics.

However, my question is whether it is possible to implement the CustomRender::Builder with the APIs we make available? (I suspect that might need "internal" APIs)

Comment on lines 37 to 43
class RendererFactory;
namespace gl
{
class RenderTarget;
}
}
}
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
class RendererFactory;
namespace gl
{
class RenderTarget;
}
}
}
}
}

Comment on lines 47 to 50
typedef std::function<std::unique_ptr<mir::renderer::Renderer>
(std::unique_ptr<mir::graphics::gl::OutputSurface>,
std::shared_ptr<mir::graphics::GLRenderingProvider>)> CreateRenderer;

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
typedef std::function<std::unique_ptr<mir::renderer::Renderer>
(std::unique_ptr<mir::graphics::gl::OutputSurface>,
std::shared_ptr<mir::graphics::GLRenderingProvider>)> CreateRenderer;

class CustomRenderer
{
public:
explicit CustomRenderer(CreateRenderer const& renderer);
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
explicit CustomRenderer(CreateRenderer const& renderer);
using Builder = std::function<
std::unique_ptr<mir::renderer::Renderer>(
std::unique_ptr<mir::graphics::gl::OutputSurface>, std::shared_ptr<mir::graphics::GLRenderingProvider>)
>;
explicit CustomRenderer(Builder&& renderer);

explicit CustomRenderer(CreateRenderer const& renderer);
void operator()(mir::Server& server) const;
private:
std::shared_ptr<mir::renderer::RendererFactory> factory;
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
std::shared_ptr<mir::renderer::RendererFactory> factory;
struct Self;
std::shared_ptr<Self> self;

@mattkae
Copy link
Contributor Author

mattkae commented Apr 22, 2024

I'd tweak the MirAL API slightly to be more consistent with other MirAL APIs, but I don't think there's anything problematic about the semantics.

However, my question is whether it is possible to implement the CustomRender::Builder with the APIs we make available? (I suspect that might need "internal" APIs)

I was able to copy over the entire GL renderer into miracle-wm with a lot of success: miracle-wm-org/miracle-wm#103

It is a really rough copy, but I only required tesselation_helpers.h and primitive.h to be copied over. The rest was already exposed to me in MIRRENDERER. Those two headers aren't very fundamental in my opinion, so I'd say we're good with what we have now.

@mattkae mattkae force-pushed the feature/expose_renderer_factory branch from b90d9d5 to 48789f6 Compare April 22, 2024 18:44
@mattkae mattkae requested a review from AlanGriffiths April 22, 2024 19:05
@mattkae mattkae force-pushed the feature/expose_renderer_factory branch from 48789f6 to 2191081 Compare April 22, 2024 19:06
Copy link
Collaborator

@AlanGriffiths AlanGriffiths left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think miral::CustomRenderer should do one thing, not two

std::unique_ptr<mir::graphics::gl::OutputSurface>, std::shared_ptr<mir::graphics::GLRenderingProvider>)
>;

CustomRenderer(Builder&& renderer, std::shared_ptr<mir::graphics::GLConfig> const&);
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why are we passing a GLConfig here?

There is prior art in miroil::OpenGLContext for doing this independently and that seems like a more flexible approach.

If we don't want to add a dependency on MirOil, then a miral::CustomGLContext seems like a cleaner approach. (What happens when there is another feature that wants to override the GL config?)

}

private:
miral::CustomRenderer::Builder const& renderer;
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should this really be a reference?


struct miral::CustomRenderer::Self
{
Self(Builder const& renderer, std::shared_ptr<mir::graphics::GLConfig> const& config)
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
Self(Builder const& renderer, std::shared_ptr<mir::graphics::GLConfig> const& config)
Self(Builder&& renderer, std::shared_ptr<mir::graphics::GLConfig> const& config)


miral::CustomRenderer::CustomRenderer(
Builder&& renderer, std::shared_ptr<mir::graphics::GLConfig> const& config)
: self{std::make_shared<Self>(renderer, config)}
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
: self{std::make_shared<Self>(renderer, config)}
: self{std::make_shared<Self>(std::move(renderer), config)}

@mattkae mattkae requested a review from AlanGriffiths April 23, 2024 17:41
Copy link
Collaborator

@AlanGriffiths AlanGriffiths left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

IMO the code could be a little clearer. But otherwise fine.

(Approving, but not merging to allow tweak)

Comment on lines 46 to 54
struct miral::CustomRenderer::Self
{
explicit Self(Builder&& renderer)
: factory(std::make_shared<RendererFactory>(std::move(renderer)))
{
}

std::shared_ptr<mir::renderer::RendererFactory> factory;
};
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This would be simpler (fewer classes, less forwarding code) if miral::CustomRenderer::Self IsA mir::renderer::RendererFactory, not HasA. Vis:

Suggested change
struct miral::CustomRenderer::Self
{
explicit Self(Builder&& renderer)
: factory(std::make_shared<RendererFactory>(std::move(renderer)))
{
}
std::shared_ptr<mir::renderer::RendererFactory> factory;
};
struct miral::CustomRenderer::Self : public mir::renderer::RendererFactory
{
explicit Self(Builder&& renderer)
: factory(std::move(renderer))
{
}
[[nodiscard]] auto create_renderer_for(
std::unique_ptr<mir::graphics::gl::OutputSurface> output_surface,
std::shared_ptr<mir::graphics::GLRenderingProvider> gl_provider) const
-> std::unique_ptr<mir::renderer::Renderer> override
{
return renderer(std::move(output_surface), std::move(gl_provider));
}
private:
miral::CustomRenderer::Builder const renderer;
};

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Alternatively, Self::factory should be const.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree with that change!

Copy link
Collaborator

@AlanGriffiths AlanGriffiths left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

More nits

src/miral/custom_renderer.cpp Outdated Show resolved Hide resolved
src/miral/custom_renderer.cpp Outdated Show resolved Hide resolved
@AlanGriffiths AlanGriffiths enabled auto-merge April 24, 2024 15:02
@AlanGriffiths AlanGriffiths added this pull request to the merge queue Apr 24, 2024
Merged via the queue into main with commit 989cebb Apr 24, 2024
33 of 36 checks passed
@AlanGriffiths AlanGriffiths deleted the feature/expose_renderer_factory branch April 24, 2024 15:48
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

Successfully merging this pull request may close these issues.

2 participants