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
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.
The text was updated successfully, but these errors were encountered:
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.
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:
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.The text was updated successfully, but these errors were encountered: