[FEATURE] Implement multi-monitor rendering support
Nobody has claimed this yet.
Assessment
- Difficulty
- 5/5
- Estimated time
- Over a week
- Newbie friendliness
- 25/100
- Issue type
- Feature
- Clarity
- Mostly clear
- Activity status
- Stale
- Tech stack
- cpp
- Domain
- computer-graphics, desktop
Research direction
Start by tracing the existing SDL window and OpenGL context setup, then inspect how the current single output is rendered. Define the work around configurable displays, stretch or clone modes, render-resolution limits, and one UI window; done means these behaviors work across the described multi-monitor layouts.
Written by the indexing model from the issue text.
Description
As requested multiple times by users over the past weeks, adding proper multi-monitor fullscreen support should be considered. Due to today's monitor sizes and different setups, simply stretching a single, borderless window over all displays won't be a great solution. Specifically, the maximum texture size may not be enough if a user arranges 3 4K monitors side by side for example, as many GPUs only support up to 8192×8192 pixels.
My proposal here would be the following:
- Let the user configure on which displays projectM should be rendered on, ideally remembering the display name or port if we can get this from SDL.
- Let the user decide to either stretch or clone the output to the selected displays. Cloning is nice for beamer/LED screen display with a local reference monitor.
- For stretching, add a render resolution selection. If automatic, check maximum texture size and limit the render size accordingly, then stretch as needed.
- One output window should be the main one, which will render the UI.
This will require creating several output windows sharing an OpenGL context, and rendering to an off-screen surface. Then glBlitFramebuffer() can be used to copy the required image parts to each output window, eventually scaling it up.
- Dominant language
- C++
- Stars
- 116
- Forks
- 64
- PR merge metrics
- No merged PRs in 30d
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from projectM-visualizer/frontend-sdl-cpp
-
Difficulty 5/5 Over a week Newbie friendliness 30/100
projectM-visualizer/frontend-sdl-cpp#134 · 4 comments ·
-
Difficulty 5/5 Over a week Newbie friendliness 35/100
-
A delete command to remove visualizations that are buggy, don't work, or are just not good looking. Openenhancement
Difficulty 4/5 3-5 days Newbie friendliness 35/100
projectM-visualizer/frontend-sdl-cpp#120 · 1 comment ·
-
enhancement
Difficulty 5/5 Over a week Newbie friendliness 25/100
projectM-visualizer/frontend-sdl-cpp#118 · 2 comments ·
-
enhancement
Difficulty 5/5 Over a week Newbie friendliness 28/100
projectM-visualizer/frontend-sdl-cpp#110 · 6 comments ·
All issues in projectM-visualizer/frontend-sdl-cpp
Similar issues
-
Difficulty 1/5 Under an hour Newbie friendliness 90/100
AXERA-TECH/ax-llm#77 ·
-
Difficulty 1/5 Under an hour Newbie friendliness 90/100
games-on-whales/wolf#509 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 74/100
-
bug-unconfirmed
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 74/100
NVIDIA/cuda-samples#453 ·