Hardware scaling (handle different logical vs. backing size)
Chưa có ai nhận issue này.
Đánh giá
- Độ khó
- 5/5
- Thời gian dự kiến
- Hơn một tuần
- Mức phù hợp với người mới
- 25/100
- Loại issue
- Tính năng
- Độ rõ ràng
- Cần làm rõ
- Mức độ hoạt động
- Đình trệ
- Công nghệ
- rust
- Lĩnh vực
- desktop, performance
Hướng nghiên cứu
Bắt đầu với phần diễn đạt trong README về Softbuffer và hậu xử lý được tăng tốc bằng GPU, sau đó kiểm tra việc kết xuất và cách xử lý kích thước buffer của dự án để xác định liệu việc scaling bằng phần cứng có phù hợp với thiết kế của dự án hay không. Issue không nêu tên tệp hoặc kiểm thử nào; để hoàn thành cần quyết định cách tiếp cận scaling, cùng với việc triển khai và coverage tương ứng.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
The readme says:
Softbuffer should be used over pixels when its GPU-accelerated post-processing effects are not needed.
When I first read this, it didn't occur to me that "post-processing effects" included scaling. I was thinking it was more about things like CRT simulation. Unfortunately, scaling is often a requirement due to high resolution displays. Anyone doing full frame redraws and desiring good performance (60fps+) will almost certainly need to operate on a smaller buffer that can be scaled up, which pixels can do. I couldn't get acceptable performance with softbuffer and software scaling, although admittedly I didn't try very hard on the scaling algorithm.
I wonder if softbuffer could make an exception and support hardware scaling, if it wouldn't go against the spirit of the project. It feels like an almost table-stakes feature for most real world use.
- Ngôn ngữ chính
- Rust
- Star
- 507
- Fork
- 85
- Chỉ số merge pull request
- Không có pull request nào được merge trong 30 ngày
Chuẩn bị môi trường
- Không có Dockerfile hay tệp Docker Compose
- Có mẫu pull request
- Không có hướng dẫn đóng góp
Bắt đầu từ đâu
- Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
- Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
- Fork repository và làm thay đổi trên một nhánh.
- Mở pull request có tham chiếu số hiệu của issue.
Issue khác của rust-windowing/softbuffer
-
DS - X11
Độ khó 3/5 1-2 ngày Mức phù hợp với người mới 48/100
rust-windowing/softbuffer#368 ·
-
`Buffer<'_>` shouldn't be `Send`Có thể đã có người làm @Guflly đã nhận 73 ngày trước. Đang mởbug DS - Android NDK
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 35/100
rust-windowing/softbuffer#347 · 1 bình luận ·
-
Needs Design Work
Độ khó 5/5 Hơn một tuần Mức phù hợp với người mới 25/100
rust-windowing/softbuffer#342 · 1 bình luận ·
-
enhancement question
Độ khó 5/5 Hơn một tuần Mức phù hợp với người mới 25/100
rust-windowing/softbuffer#338 ·
-
Zero-copying on AndroidCó thể đã có người làm @MarijnS95 đã nhận 256 ngày trước. Đang mởDS - Android NDK enhancement
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 35/100
rust-windowing/softbuffer#318 · 2 bình luận ·
Tất cả issue của rust-windowing/softbuffer
Issue tương tự
-
agent:triaged bug bughunt pm:bundler priority:p1
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 70/100
SocketDev/socket-patch#1573 · 1 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
-
rustix::termios::Termios::OutputModes does not expost some const e.g. OLCUC for musl and macOSĐang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 62/100
bytecodealliance/rustix#1706 · 1 bình luận ·
Maintainer thường phản hồi trong vòng 11 ngày
-
`LazyFrameRemote` and `ExecuteRemote` sinks do not accept `Path`, like `LazyFrame` sinks do.Đang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 62/100
-
Bump anybuf version to ^1.0.0Đang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 72/100
wormhole-foundation/wormhole#5062 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
LaunchOrFocusPlugin switches to the wrong tab after tabs are reordered (tab id used as position)Có thể đã có người làm @olegator888 đã nhận hôm nay. Đang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 74/100
zellij-org/zellij#5719 ·
Maintainer thường phản hồi trong vòng 1 ngày