Skip to content

Conversation

@waywardmonkeys
Copy link
Collaborator

This is a fork of the upstream, without the backends yet, and without the GL integration, and without some of the winit integration.

@waywardmonkeys
Copy link
Collaborator Author

waywardmonkeys commented Apr 17, 2025

This is part of a conversation starter.

Among questions that should be answered:

  • Does this approach work today?
  • Can we get good backends in place for Core Animation, Windows.UI.Composition, Android's SurfaceControl, Wayland's APIs (including `viewporter), and a wgpu-based fallback?
  • Should we do this here or approach upstream about doing this in the original repo?
  • Should we keep this name or rename it?
  • What will we need to do for winit integration for subsurfaces and such in Wayland and other APIs?
  • Use Kurbo instead of Euclid

@waywardmonkeys waywardmonkeys marked this pull request as draft April 17, 2025 17:06
@waywardmonkeys waywardmonkeys force-pushed the compositor-thinking branch 2 times, most recently from 79ec1d5 to fbfd707 Compare April 18, 2025 16:29
This is a fork of the upstream, without all of the backends yet,
and without the GL integration, and without some of the winit
integration.
Now, only the method that needs the winit Window gets it rather
than trying to store it locally when a feature is enabled. This
also lets the people embedding this library pass in the reference
to the window rather than any sort of window construction being
needed.

This does mean that the correct window must be passed in.
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.

1 participant