Hacktoberfest 2026:メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

Do we want a `SurfaceConfiguration` builder?

オープン
#338 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

まだ誰も着手していません。

評価

難易度
5/5
見積もり時間
1週間以上
初心者へのやさしさ
25/100
issue の種類
機能追加
明瞭さ
説明が足りない
活発さ
停滞
技術スタック
rust

調査の方向性

まず、提案されている Surface::configure API と next_buffer 周辺の代替案を読み、その後、保留中の設定パラメーターについて PRs 321、317、320 と issue 29 を確認してください。再構成のバッチ処理、エラー処理、リサイズのレイテンシー、クロスプラットフォーム動作について、トレードオフを比較してください。合意された API の方向性に到達し、実装範囲を定義できれば完了です。

索引モデルが issue の本文から書いたものです。

説明

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.

主要言語
Rust
スター
507
フォーク
85
PR マージ指標
30日以内にマージされた PR はありません

環境構築

  • Dockerfile・Docker Compose ファイルなし
  • プルリクエストのテンプレートあり
  • コントリビューションガイドなし

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

rust-windowing/softbuffer のほかの issue

rust-windowing/softbuffer の issue をすべて見る

似ている issue

Rust の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。