You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[FEATURE] Implement multi-monitor rendering support #58
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.
In addition to the above, if performance allows, projectMSDL could also run multiple projectM instances, showing each on a single monitor. This would allow showing different presets, but keeping the transitions synced.
I've been looking for something like this for years, ever since the Qt4 projectM visualizer broke. I could make it span all my monitors with a KWin rule. I have been without that functionality for two years now.
While this feature currently has a fairly low priority, it's a good time to ask a few things on how people would expect this to work:
How should the app deal with preset playlists - using the same playlist for each window and either show the same or "next" presets from the same list, or should each window use its own preset playlist?
Should the additional windows have some sort of UI, e.g. their own playback controls etc., or should this all be done from the main window?
Is it a good idea to add an option to make the UI a completely separate window, so there are one or more rendering windows with presets, and an additional UI window to control the setup? This might make the app more useful to DJs for example, putting the preset window(s) on beamers/LED screens and keep the UI on a different screen.
Activity
kblaschke commentedon Nov 27, 2023
In addition to the above, if performance allows, projectMSDL could also run multiple projectM instances, showing each on a single monitor. This would allow showing different presets, but keeping the transitions synced.
MadMartian commentedon Mar 11, 2025
I've been looking for something like this for years, ever since the Qt4 projectM visualizer broke. I could make it span all my monitors with a KWin rule. I have been without that functionality for two years now.
[-]Implement multi-monitor rendering support[/-][+][FEATURE] Implement multi-monitor rendering support[/+]kblaschke commentedon Oct 7, 2025
While this feature currently has a fairly low priority, it's a good time to ask a few things on how people would expect this to work:
Any additional input is also welcome.