Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

"Multi-window support" brain dump #229

Open
floooh opened this issue Oct 30, 2019 · 19 comments
Open

"Multi-window support" brain dump #229

floooh opened this issue Oct 30, 2019 · 19 comments

Comments

@floooh
Copy link
Owner

floooh commented Oct 30, 2019

What's needed to add "proper" multi-window support to sokol_gfx.h and sokol_app.h:

sokol_gfx.h:
Not strictly multi-window specific, but sg_desc needs a couple more parameters to describe the default framebuffer, this is only needed for validation whether a pipeline object is compatible with that pass:

  • color and depth pixel formats
  • sample count

sg_setup_context() needs a sg_contect_desc* param which contains swap-chain / context-specific parameters (a subset of what's in sg_desc):

    const void* (*mtl_renderpass_descriptor_cb)(void);
    const void* (*mtl_drawable_cb)(void);
    const void* (*d3d11_render_target_view_cb)(void);
    const void* (*d3d11_depth_stencil_view_cb)(void);

...plus the color/depth pixel formats and sample count.

The callbacks are needed because each window has its own swap chain. The pixel formats and sample count are needed for pipeline validation.

Then, for each window call sg_setup_context(), and before the default render pass of that window, call sg_activate_context().

sokol_app.h:

This will be much more work:

  • provide max number of windows in sapp_desc to allocate "window pool"
  • sapp_window handle type (same as the sokol-gfx handles)
  • the "main window" gets a special default handle
  • each window needs its own swap chain / GL context
  • sapp_event needs the window handle, to associate events with windows
  • new sapp_window_width/height() functions which take a window handle
  • sapp_create_window() / sapp_destroy_window()
  • sapp_show_window() / sapp_hide_window()
  • sapp_minimize_window() / sapp_maximize_window() / sapp_restore_window()
  • sapp_resize_window()?
  • ...when in doubt, look how GLFW solves it :)
@incrediblejr
Copy link

A proof of concept implementation can be found here with the test file here which creates multiple windows, each using sokol gfx.

This is by no means complete and should seen as a way to get the ball rolling / discussions started. It is currently only working on Windows with D3D11.

Please refer to the comments (make a diff to master to see what changed) in the sokol_app.h + sokol_gfx.h. As I do not know the limitations/quirks of the non-Windows platforms supported by sokol app/gfx input and help is needed to take this further.

@icefoxen
Copy link

icefoxen commented Jan 8, 2020

Personally as a user I would far prefer sokol_app.h stays simple and only supports one window, rather than adding a bunch of complexity for a big feature that often won't be used. I'm only using it for gamedev though, so I'm biased.

@medvednikov
Copy link
Contributor

For me this is very important since I wanted to use Sokol as a backend for a UI engine.

It's not possible, until this is implemented.

@ikrima
Copy link
Contributor

ikrima commented Apr 21, 2020

(For posterity, posting here as well)

ImGui multiviewport integration:

Demo: https://twitter.com/ikrimae/status/1252194400681127936
Repo: https://github.com/ikrima/sokol

  • Integrated with ImGui 1.76's docking branch
  • Updated/fixed from @incrediblejr proof of concept
  • Windows & DX11
  • Hasitly put together (aka hacky shortcuts abound); will cleanup possibly

@septag
Copy link
Contributor

septag commented May 14, 2020

This is impressive. can't wait for multi-view + imgui support on the official repo

@kattkieru
Copy link

Curious about the state of this, whether or not the plan includes multi-window iOS support?

@ikrima
Copy link
Contributor

ikrima commented Nov 23, 2020

@kattkieru I just merged & updated my fork (https://github.com/ikrima/sokol) to the latest. It's mostly updated to be idiomatic with the rest of sokol

Having that said, some caveats

  • merged 6+mo of commits in one setting so bugs probably
  • probably even more so with new features since I haven't used them yet
  • I only bothered to migrate the win32/d3d path

But given some of the changes in sokol like user context data/etc, it's a bit more feasible to merge into main + add other platforms (cc: @floooh )

It still needs a decent cleanup pass tho since I usually just hack whatever my pressing need is

@floooh
Copy link
Owner Author

floooh commented Nov 26, 2020

Thanks for the headsup. I'll need to set aside a bit of time to play around and get familiar with your fork and my year-end vacation is coming up. It'll most likely slip into the next year.

@ikrima
Copy link
Contributor

ikrima commented Nov 26, 2020

No rush! Only tagged you for your curiosity; fork isn't really in a good PR ready form + cleaning up some old outstanding bugs. Probably will be till next year before i fully sanitize it as well

@kattkieru
Copy link

@ikrima Excellent timing, as I'm looking at this again for my christmas break. Thanks for posting!

@stbachmann
Copy link

@ikrima @kattkieru I've opened a new pull-request that has a more complete multi-window implementation (using some of the previous work done here already): #437

Happy to hear thoughts/feedback!

@ikrima
Copy link
Contributor

ikrima commented Dec 1, 2020

@stbachmann excellent. Don't have too much time right now to dive into it but from quick scan, the only thing that sticks out is updating the sokol imgui bits.

There's a bug in the imgui shader bc it doesn't scale the vtx position according to the window clipspace (imgui emits in absolute window space in multiviewport mode). Here's the updated shader:

@module _simgui

@vs vs
uniform vs_params {
  vec4 disp_rect;
};
in vec2 position;
in vec2 texcoord0;
in vec4 color0;
out vec2 uv;
out vec4 color;
void main() {
  gl_Position = vec4((((position-disp_rect.xy)/disp_rect.zw)-0.5)*vec2(2.0,-2.0), 0.5, 1.0);
  uv = texcoord0;
  color = color0;
}
@end

@fs fs
uniform sampler2D tex;
in vec2 uv;
in vec4 color;
out vec4 frag_color;
void main() {
  frag_color = texture(tex, uv) * color;
}
@end

@program simgui vs fs

@stbachmann
Copy link

@ikrima thanks, great pointer. I'll check out what you did on your branch to make this work. 👍

@ylluminate
Copy link

ylluminate commented Jan 2, 2021

As mentioned before by @medvednikov this is necessary for V lang's (>21k stars) fantastic V UI library. Highly compelling.

@andorxornot
Copy link

Is there any news about support for multiple contexts? Maybe some plans or forecasts

@floooh
Copy link
Owner Author

floooh commented Jan 10, 2024

So from my side, I abandonded the old multiwindow branch I had started because it became too gnarly (and also required too many changes in sokol_gfx.h).

sokol_gfx.h at least will become more flexible to support multi-window scenarios when this is implemented:

#904

(since there will no longer be a special 'default frame buffer' but instead just one or multiple 'external swapchains', the entire context stuff in sokol-gfx will most likely be removed too after this change)

This may be the foundation to do another approach with multi-window support in sokol_app.h, but I was also running into an unrelated problem on macOS with MTKView (there's a one-second timeout freeze when a window becomes fully obscured, this isn't noticeable when there's only a single window, but in an application with multiple windows it becomes a problem).

@digitalsignalperson
Copy link

Has anyone glued together the imgui multiviewports/docking branch & multiple windows with sokol-gfx and glfw per https://github.com/floooh/sokol-samples/blob/master/glfw/multiwindow-glfw.c ?

@creikey
Copy link

creikey commented Aug 26, 2024

Now that #904 is done, I wonder if this'll be implemented. Would be really rad.

@floooh
Copy link
Owner Author

floooh commented Aug 26, 2024

I agree, but the next big things on my mental roadmap are making resource bindings more flexible in sokol_gfx.h, and after that compute shader support.

After that it might make sense to go back to sokol_app.h for a bit.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests