Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

Do we want a `SurfaceConfiguration` builder?

Abierto
#338 0 comentarios 0 reacciones 0 asignados Ver en GitHub

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

enhancement question

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

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de rust-windowing/softbuffer

Todos los issues de rust-windowing/softbuffer

Issues similares

Más issues de Rust

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.