Do we want a `SurfaceConfiguration` builder?
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 5/5
- Tiempo estimado
- Más de una semana
- Aptitud para principiantes
- 25/100
- Tipo de issue
- Nueva funcionalidad
- Claridad
- Necesita aclaración
- Estado de actividad
- Estancado
- Stack tecnológico
- rust
Línea de trabajo
Comienza leyendo la API propuesta de Surface::configure y las alternativas en torno a next_buffer; después, revisa las PRs 321, 317 y 320, además de issue 29, para conocer los parámetros de configuración pendientes. Compara las ventajas y desventajas de agrupar la reconfiguración, el manejo de errores, la latencia del redimensionamiento y el comportamiento multiplataforma. Se considera terminado cuando se haya acordado la dirección de la API y se haya definido el alcance de la implementación.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
In https://github.com/rust-windowing/softbuffer/pull/321, I've added Surface::configure that takes width, height and AlphaMode. This is necessary because changing those properties requires re-creating the underlying buffers, which is costly, and as such you'll want to do it at once (instead of e.g. having set_width/set_height/set_alpha_mode that each re-creates the buffers).
https://github.com/rust-windowing/softbuffer/pull/317 will add PixelFormat to that as well, and any solution of https://github.com/rust-windowing/softbuffer/issues/29 is probably going to require at least one more parameter. https://github.com/rust-windowing/softbuffer/pull/320 might be in this category as well, I'm a bit unsure.
Do we want to introduce a SurfaceConfiguration struct to help with this, similar to wgpu's? That would allow more easily falling back to default values for parameters that the user doesn't care about:
surface.configure(SurfaceConfiguration {
width: NonZero::new(width).unwrap(),
height: NonZero::new(height).unwrap(),
alpha_mode: AlphaMode::Premultiplied,
.. // rest is default
})?;
An alternative would be to make configuration happen internally in next_buffer, something like:
impl Surface<'_> {
pub fn set_size(width: NonZero<u32>, height: NonZero<u32>) /* does not return an error */ {
self.width = Some(width);
self.height = Some(height);
}
pub fn set_alpha_mode(alpha_mode: AlphaMode) {
self.alpha_mode = alpha_mode;
}
pub fn set_pixel_format(pixel_format: PixelFormat) {
self.pixel_format = pixel_format;
}
// ...
pub fn next_buffer(&mut self) -> Result<Buffer<'_>, SoftbufferError> {
let width = self.width.expect("must set width before calling `buffer_mut`");
let height = self.height.expect("must set height before calling `buffer_mut`");
self.inner.configure(width, height, self.alpha_mode, self.pixel_format, ...)?;
self.inner.buffer_mut()
}
}
This is already what the Wayland backend does internally, so might help make things more cross-platform? Or maybe there are disadvantages to this that I'm not seeing? E.g. maybe resizing in WindowEvent::Resized might help to reduce latency (it could probably be scheduled such that there was a little bit extra time to resize the buffers before WindowEvent::RequestedRedraw)? Creating an IOSurface that fills the screen seems to take anywhere between 30µs and 500µs.
Wrt. error handling, there's probably value in separating the "configure" errors from the "get buffer" errors.
- Lenguaje dominante
- Rust
- Estrellas
- 507
- Forks
- 85
- Métricas de merge de PR
- Sin PR fusionados en 30 d
Preparar el entorno
- Sin Dockerfile ni archivo de Docker Compose
- Tiene una plantilla de pull request
- Sin guía de contribución
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de rust-windowing/softbuffer
-
DS - X11
Dificultad 3/5 1-2 días Aptitud para principiantes 48/100
rust-windowing/softbuffer#368 ·
-
`Buffer<'_>` shouldn't be `Send`Posiblemente ocupada @Guflly la tomó hace 67 días. Abiertobug DS - Android NDK
Dificultad 4/5 3-5 días Aptitud para principiantes 35/100
rust-windowing/softbuffer#347 · 1 comentario ·
-
Needs Design Work
Dificultad 5/5 Más de una semana Aptitud para principiantes 25/100
rust-windowing/softbuffer#342 · 1 comentario ·
-
Zero-copying on AndroidPosiblemente ocupada @MarijnS95 la tomó hace 249 días. AbiertoDS - Android NDK enhancement
Dificultad 4/5 3-5 días Aptitud para principiantes 35/100
rust-windowing/softbuffer#318 · 2 comentarios ·
-
DS - Wayland DS - X11 question
Dificultad 5/5 Más de una semana Aptitud para principiantes 25/100
rust-windowing/softbuffer#306 · 2 comentarios ·
Todos los issues de rust-windowing/softbuffer
Issues similares
-
status:needs-triage
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
agentic-os-org/ANOLISA#6742 · 1 comentario ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 67/100
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 90/100
Kc1t/alethe-agents#312 ·
Los mantenedores suelen responder en 3 días
-
api: storage
Dificultad 2/5 1-3 horas Aptitud para principiantes 74/100
googleapis/google-cloud-rust#7153 ·
Los mantenedores suelen responder en 1 día