I need to get the OpenGL Context (an HGLRC) from a window (or device context). The function wglGetCurrentContext cannot be used since I do not know whether or not the context is bound to the current thread. How can this be done?
I need to get the OpenGL Context (an HGLRC) from a window (or device context).
You can't!
OpenGL render contexts are in no way tied to windows, at all.
Windows can have an arbitrary number of device contexts. There's at least one primary context, but additional contexts can be created at any time.
OpenGL render contexts can be made active on any device context (DC) that is compatible, but there is – again – no strict tie between a DC and a OpenGL context. As long as any given window's device context is compatible to a certain OpenGL context the OpenGL context can be made current on the device context. Later, if one desires so, that connection can be undone and the same OpenGL context can be made current on a different DC of a different window (as long as they're compatible).
Oh, and it also works the other way round: You can have an arbitrary number of threads, each having a different OpenGL context active on the same window/device context simultanously.
There simply is no bijective mapping between windows and OpenGL contexts.
You can use wglGetCurrentContext() to check if there's a context currently bound. But there isn't any function that can be used to check whether a HDC is associated with a HGLRC.
These are the only functions in relation to getting each other:
HDC GetDC(HWND hWnd)
HWND WindowFromDC(HDC hdc)
// Depends on wglMakeCurrent()
HDC wglGetCurrentDC()
HGLRC wglGetCurrentContext()
So you'd need to keep track of the HGLRC after creating it.
Related
Hi I'm trying to render 3 full screen windows on different monitors, until now I've successfully queried for existing monitors EnumDisplayMonitors to get the 4 parameters necessary to create 3 windows with WS_POPUP style applied.
In one frame I do the following:
for(int i=0; i<monitorsNum; i++)
{
wglMakeCurrent(hdcs[i], sharedHrc);
doRendering();
SwapBuffers(hdcs[i]);
}
Many websites suggest the same, however, when I go from 1 monitor to 2 or more monitors, textures disappear:
What you see is the same scene rendered 3 times, the slight different background clear color shows that at least I'm doing the stuff partially correct (gl clear color showed correctly, it even works with 3 monitors of 3 different sizes). I tried to intercept all the gl calls with glGetError() without getting any error. Is there a specific step I missed, or maybe it is a issue of my laptop?
If it helps, the 3 windows are created with an existing framework, so at creation each window has been given its own hrc, but then I just use one hrc for the other 2 windows. (so 3 hrc created, and 1 used, if it matters)
There are many reasons that a texture may not display correctly when rendering some geometry.
But assuming your problem isn't related to any of these things such as incorrect UVS, shader issues, texture creation etc the issue could be related to the fact that you are now managing multiple contexts.
To set up multiple windows you need to create a context for each window.
The wglMakeCurrent function allows you to switch the context for each window, rendering as you go.
https://learn.microsoft.com/en-us/windows/desktop/api/wingdi/nf-wingdi-wglmakecurrent
The wglMakeCurrent function makes a specified OpenGL rendering context the calling thread's current rendering context. All subsequent OpenGL calls made by the thread are drawn on the device identified by hdc. You can also use wglMakeCurrent to change the calling thread's current rendering context so it's no longer current.
An OpenGL context represents the default frame buffer (default place that your shader will output to when rendering) but it also stores all of the state associated with that instance of OpenGL.
Furthermore:
Each context has its own set of OpenGL Objects, which are independent of those from other contexts.
So this means that each context does not have access to the same resources unless explicitly told.
Any object sharing must be made explicitly, either as the context is created or before a newly created context creates any objects. However, contexts do not have to share objects; they can remain completely separate from one another.
So one reason you may be able to render the same texture(s) in each window is because that texture is not a shared resource. glClearColor works fine because it is not dependent on any resources that are associated with any particular context.
I created two windows using GLFW. The first window has an OpenGL context and the second one doesn't. What I want to do is render the same scene to both windows using a single OpenGL context. Something like this.
glBindVertexArray(vaoId);
// ... tell OpenGL to draw on first window
glClear(GL_COLOR_BUFFER_BIT);
glDrawArrays(...);
// ... swap first window buffers
// ... tell OpenGL to draw on second window
glClear(GL_COLOR_BUFFER_BIT);
glDrawArrays(...);
// ... swap second window buffers
glBindVertexArray(0);
The problem is I don't know how to tell OpenGL to draw on a specific window. And I also don't know how to swap buffers for a specific window. If it's necessary, I can use Win32 API.
As far as I'm aware, GLFW does not directly support that in it's API. It generally considers a Window and a GL context as a unit. However, with the native APIs, you can do what you want. For windows 32 in partiuclar, have a look at wglMakeCurrent(). In GLFW, you can get the required context and window handles via GLFW's native access API. Note that you will only get a HWND that way, you will have to manually use GetDC() to get the device context of the window.
Be aware that switching contexts will imply flushing the GL command queue, which can have negative effects on the performance. See GL_KHR_context_flush_control for more details.
I have an application written in C using GTK (although the language is probably unimportant for this question).
This application has a fullscreengtk_window with a single gtk_drawing_area. For the drawing area, I have registered a tick callback via gtk_widget_add_tick_callback which just calls gtk_widget_queue_draw every tick. Inside the drawing area draw callback, I change the color of the entire window at regular intervals (e.g., from black to white at 1Hz).
Say that in this call to the draw callback I want to change the window from black to white. I would like to know the precise time (down to the nearest ms) that the change is actually drawn on the screen (ideally in the same units as CLOCK_MONOTONIC). I don't think this is the same thing as the GdkFrameClock available in the tick callback, which, as I understand it, is about the time of the frame, not the time when the frame is actually displayed on the screen.
If I just measure the CLOCK_MONOTONIC time in the drawing callback, and then use a photo-diode to measure when the actual change is via an attached A2D, the actual change is the display is understandably delayed by a number of refresh intervals (in my case, 3 screen refreshes).
Just as a summary: if I am in a GTK widget draw callback, is there any way to know the time when the display will actually be shown on the monitor in the units of CLOCK_MONOTONIC? Or alternatively, is there a way that I can block a separate thread until a specific redraw that I care about is actually displayed on the screen (a function I can write like wait_for_screen_flip())?
Update: Ideally, the same solution would work for any Linux compositor (X11 or Wayland), which is why I am hoping for a GTK/GDK solution, where the compositor is abstracted away.
Similarly to Uli's answer of the Present extension and PresentCompleteNotify for X11, Wayland has a similar protocol called wp_presentation_feedback:
https://cgit.freedesktop.org/wayland/wayland-protocols/tree/stable/presentation-time/presentation-time.xml
This protocol allows the Wayland compositor to inform clients when their content was actually displayed (turned to light). It is independent of the actual buffer mechanism used (EGL/SHM/etc). To use it, you call wp_presentation_get_feedback before wl_surface_commit; when the commit has completed, a presented event will be sent to the client from the new wp_presentation_feedback object, or discarded if it was never shown.
Presentation feedback is currently implemented in Weston; it is not yet implemented in Mutter, and I don't believe it's implemented in KWin either. GTK+ plans to support it when it becomes available in Mutter, but I don't have any great insight as to how it would be exposed through the GTK+ API.
That being said, if you can get access to the Wayland display, it's possible that you could use the interface directly yourself.
I just came across https://developer.gnome.org/gdk3/stable/gdk3-GdkFrameTimings.html#gdk-frame-timings-get-presentation-time which seems to do just like what you want and is part of Gdk. I do not know how to use it nor have I seen some example of it, but https://developer.gnome.org/gdk3/stable/gdk3-GdkFrameTimings.html#gdk3-GdkFrameTimings.description says
The information in GdkFrameTimings is useful for precise synchronization of video with the event or audio streams, and for measuring quality metrics for the application’s display, such as latency and jitter.
Take a look at https://cgit.freedesktop.org/xorg/proto/presentproto/tree/presentproto.txt. Specifically, you want PresentCompleteNotify events. Note that these can only tell you later when presentation actually happened, so (I think) you will not know ahead of time when this is (but you could perhaps guess based on recent notifies?).
Note that this is
a relatively new X11 extension, so might not actually be supported everywhere
depends on the driver used (and likely lots of other factors) for the quality of data
cannot be used from GTK since it requires a different way to display to the screen (you draw to a Pixmap and then use PresentPixmap to make it visible and ask for a notify)
Also note that this extension provides lots of other things. You can for example say "please display at time ". Just read the protocol specification from start to end. :-)
I've derived my own widget type from GtkWidget in order to use it as a drawing surface for OpenGL. To give OpenGL control over the underlying X11 Window, I need to disable the widget's double buffering - else the whole rendering result will be drawn over by GTK's buffer swap.
However, gtk_widget_set_double_buffered and the "double-buffered" property have been deprecated in the current version of GTK+3 for being too platform-dependent.
Is there a way to disable double buffering on the GDK or X11 level instead?
This is a rather old question, but I'll give it a shot.
In any even slightly more recent context (i.e. with GTK+ >= 3.16, which is over 6 years old by now), I guess the best solution would be to avoid rolling your own OpenGL widget and just use Gtk.GLArea instead: https://docs.gtk.org/gtk3/class.GLArea.html
Alternatively, if you happen to be stuck with an ancient GTK+ version, maybe on an embedded device, then there aren't many options besides gtk_widget_set_double_buffered (see also https://people.gnome.org/~shaunm/girdoc/C/Gtk.Widget.set_double_buffered.html): this does not set any X11/Xorg window flags or similar, but just changes the internal event handling of GTK+ to either send draw calls to an offscreen buffer, or directly to the visible surface.
Note that this offscreen buffer is completely separate from anything involving X or OpenGL.
The Gtk+ 3 migration guide shows how the GdkEventExpose.region field can be used to provide a fine-grained area for re-rendering widgets. We already do something like this in Inkscape to avoid rendering excessive amounts of complicated stuff on our drawing canvas.
However, the example in the guide shows how to do this for the old Gtk+ 2 expose_event handler.
How do I do the equivalent in a new Gtk+ 3 draw handler, which receives a "ready-clipped" Cairo context as a parameter, rather than a GdkEventExpose?
I guess one possibility is to use cairo_copy_clip_rectangle_list on the "ready-clipped" cairo context to obtain a list of rectangles that make up the region to draw. Does anyone have any experience of using this? Does it seem like a sensible approach?
Yes, you should use cairo_copy_clip_rectangle_list() on the cairo_t that you get in your widget's ::draw() signal handler. See this commit for an example:
http://git.gnome.org/browse/vte/commit/?id=21a064ac8b5925108b0ab9bd6516664c8cd3e268
Since I have not much clue, I decided to check the source code. GDK emits a GDK_EXPOSE event on a window and creates the GdkEventExpose instance for this.
This event is then handled in gtk/gtkmain.c via gtk_widget_send_expose():
http://git.gnome.org/browse/gtk+/tree/gtk/gtkwidget.c?id=eecb9607a5c0ee38eadb446545beccd0922cb0b8#n6104
This function clips the cairo_t to GdkEventExpose.region, as you already learned in the docs.
This then calls _gtk_widget_draw_internal() which emits the actual draw signal:
http://git.gnome.org/browse/gtk+/tree/gtk/gtkwidget.c?id=eecb9607a5c0ee38eadb446545beccd0922cb0b8#n5726
As far as I can see, nothing here let's you access the clip region directly. In gtk_widget_send_expose() the GdkEvent is added as userdata to the cairo context. However, this is not accessible, because all the involved functions and variables are static. So you'll have to use cairo_copy_clip_rectangle_list().
However, this sounds quite inefficent. First gdk_cairo_region transforms the region into a number of calls to cairo_rectangle and then cairo transforms this from its internal representation into a cairo_rectangle_list_t (which may fail if the clip is, for some reason, not a region). If you see this being slow, it might make sense to have some shortcut for this added to gtk directly.