Skip to content

[FEATURE] Implement multi-monitor rendering support #58

Description

@kblaschke

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.

Activity

  1. kblaschke commented on Nov 27, 2023

    @kblaschke
    MemberAuthor

    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.

  2. MadMartian commented on Mar 11, 2025

    @MadMartian

    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.

  3. changed the title [-]Implement multi-monitor rendering support[/-] [+][FEATURE] Implement multi-monitor rendering support[/+] on Oct 7, 2025
  4. added theissue type on Oct 7, 2025
  5. kblaschke commented on Oct 7, 2025

    @kblaschke
    MemberAuthor

    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.

    Any additional input is also welcome.

  6. added
    input wantedThe team wants additional input from the users on this issue.
    on Oct 7, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or requestinput wantedThe team wants additional input from the users on this issue.

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions