Pixel format API design
評価
- 難易度
- 5/5
- 見積もり時間
- 1週間以上
- 初心者へのやさしさ
- 25/100
- issue の種類
- 機能追加
- 明瞭さ
- 説明が足りない
- 活発さ
- 停滞
- 技術スタック
- rust
調査の方向性
まず、この issue のピクセル形式の要件を、issues 17 と 44、および pull request 95 と併せて確認します。Web バックエンドの BGRX-to-RGBA 変換と、Wayland の wl_shm における形式の制約を調査します。サポート対象および最適な形式、alpha の処理、汎用的な fallback の動作、ならびにそれらを一覧表示して選択するための API について合意できれば完了です。
索引モデルが issue の本文から書いたものです。
説明
We need an API to list available pixel formats, and select one. Some considerations:
- We want a way to support transparency: https://github.com/rust-windowing/softbuffer/issues/17
- The web backend current converts BGRX to RGBA. It would be better if it could use RGBA directly, if an application can render that way.
- It looks like for https://github.com/rust-windowing/softbuffer/issues/44 we'd have to use RGBX, rather than BGRX.
- For https://github.com/rust-windowing/softbuffer/pull/95, it seems BGRA is supported, but not BGRX. So we need to make sure to set alpha to 255.
- Wayland's
wl_shmcan support many formats, but only two are required to be supported by compositors.
So some questions here:
- What formats should be supported?
- We want to offer a format for each platform that can be used efficiently without conversion, at least, and there doesn't seem to be one that can be assumed everywhere, unfortunately.
- There are many formats that could be supported on at least some platforms.
- Do we want to support formats that are not 4 byte per pixel? This will impact the API, which currently uses u32 values for pixels.
- How to we communicate what formats are supported, and what formats are optimal?
- We still want at least one format to work on all platforms, even if it requires conversion on some, right? What formats should be universally supported, then?
- 主要言語
- Rust
- スター
- 507
- フォーク
- 85
- PR マージ指標
- 30日以内にマージされた PR はありません
環境構築
- Dockerfile・Docker Compose ファイルなし
- プルリクエストのテンプレートあり
- コントリビューションガイドなし
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
rust-windowing/softbuffer のほかの issue
-
DS - X11
難易度 3/5 1〜2日 初心者へのやさしさ 48/100
rust-windowing/softbuffer#368 ·
-
`Buffer<'_>` shouldn't be `Send`対応中かも @Guflly が 69 日前に担当しました。 オープンbug DS - Android NDK
難易度 4/5 3〜5日 初心者へのやさしさ 35/100
rust-windowing/softbuffer#347 · コメント 1 件 ·
-
Needs Design Work
難易度 5/5 1週間以上 初心者へのやさしさ 25/100
rust-windowing/softbuffer#342 · コメント 1 件 ·
-
enhancement question
難易度 5/5 1週間以上 初心者へのやさしさ 25/100
rust-windowing/softbuffer#338 ·
-
Zero-copying on Android対応中かも @MarijnS95 が 251 日前に担当しました。 オープンDS - Android NDK enhancement
難易度 4/5 3〜5日 初心者へのやさしさ 35/100
rust-windowing/softbuffer#318 · コメント 2 件 ·
rust-windowing/softbuffer の issue をすべて見る
似ている issue
-
難易度 2/5 1〜3時間 初心者へのやさしさ 62/100
NuSkooler/enigma-bbs#907 ·
メンテナーはふだん 1 日以内に返信
-
bug
難易度 2/5 1〜3時間 初心者へのやさしさ 62/100
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 62/100
EasyTier/EasyTier#2672 · コメント 1 件 ·
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 72/100
メンテナーはふだん 1 日以内に返信
-
bug good first issue
難易度 2/5 1〜3時間 初心者へのやさしさ 84/100
repowise-dev/repowise#3374 ·
メンテナーはふだん 1 日以内に返信