If you're going to require a thread for each window then the next best thing is to try and isolate the threads as much as possible, so that you don't need to share (memory space) data between them. X Windows (
https://en.wikipedia.org/wiki/X_Window_System) uses a client/server architecture so you might gain something by that approach.
Run the logic of your application in its own thread, and use it to create a 'server'. You can then create individual threads for each window you need, completely self containing the drawing and event handling, and then communicate with the server thread using a library such as Enet (
http://enet.bespin.org/). Forward events from your window to the server, process them, then have the server broadcast the results to all connected windows (clients) for them to draw.
In this situation you also get the added bonus that your main logic processing is effectively run in a separate thread to graphics and rendering.
Will this introduce lag? Yes, some, but if it's all running on a local machine it will likely be negligible. Depending on your application, it will be fine, for example if you're running some kind of graphing simulation. Turn based games will probably work very well too (I know this from experience
https://fallahn.itch.io/vga-golf ). For fast action games there are tried and tested methods which can be implemented to negate perceivable lag, should it be deemed necessary:
https://www.gabrielgambetta.com/client-server-game-architecture.htmlhttps://gafferongames.com/categories/networked-physics/ HTH