• 0

WPF rendering with OpenGL in another thread


Question

I'm trying to make a video player in WPF, using libavcodec for decoding and OpenGL for rendering.

I host my own C++/CLI control derived from Windows.Forms.UserControl inside a WindowsFormsHost. I use its Handle to initialize an OpenGL context.

Here is the code for my override of OnPaint:

wglMakeCurrent(m_hDC, m_hRC);
glClearColor(1.0f, 0.0f, 0.0f, 0.0f);
glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT);
SwapBuffers(m_hDC);

This works fine. When OnPaint is called, the control, which covers the whole window, is cleared to red.

Now, WPF controls when OnPaint is called, not me. When I'll be rendering video, I need to be able to draw to the screen when I decide to. So I've put the above code in an infinite loop and made it execute on a BackgroundWorker thread. Now, the problem is that wglMakeCurrent fails in this situation with"error 170: the requested resource is in use". Consequently, the call to glClear() (and any further rendering) does nothing.

I don't understand exactly which resource is in use and why, and I'd like to know what's wrong with my approach.

Thanks!

P.S. here is the initialization code in case this could be useful. It is hooked to the "Load" event of the control. And yes this is essentially copy-pasted from a tutorial on the net.

m_hWnd	= (HWND) this->Handle.ToPointer();

			if(m_hWnd)
			{
				m_hDC = GetDC(m_hWnd);
				if(!m_hDC)
				{
					Helper::ErrorExit(L"BuildWindowCore");
				}
				uint PixelFormat;

				BYTE iAlphaBits = 0;
				BYTE iColorBits = 32;
				BYTE iDepthBits = 16;
				BYTE iAccumBits = 0;
				BYTE iStencilBits = 0;

				static PIXELFORMATDESCRIPTOR pfd = 
				{
					sizeof(PIXELFORMATDESCRIPTOR),	//size
					1,								//version
					PFD_DRAW_TO_WINDOW|				//flags
					PFD_SUPPORT_OPENGL|
					PFD_DOUBLEBUFFER,
					PFD_TYPE_RGBA,					//pixeltype
					iColorBits,
					0, 0, 0, 0, 0, 0,				//color bits ignored
					iAlphaBits,						
					0,								//alpha shift ignored
					iAccumBits,						//accum. buffer
					0, 0, 0, 0,						//accum bits ignored
					iDepthBits,						//depth buffer
					iStencilBits,					//stencil buffer
					0,								//aux buffer
					PFD_MAIN_PLANE,					//layer type
					0,								//reserved
					0, 0, 0							//masks ignored
				};

				PixelFormat = ChoosePixelFormat(m_hDC, &pfd);
				if(!PixelFormat)
				{
					Helper::ErrorExit(L"BuildWindowCore");
				}

				if(!SetPixelFormat(m_hDC, PixelFormat, &pfd))
				{
					Helper::ErrorExit(L"BuildWindowCore");
				}

				m_hRC = wglCreateContext(m_hDC);
				if(!m_hRC)
				{
					Helper::ErrorExit(L"BuildWindowCore");
				}

				if(!wglMakeCurrent(m_hDC, m_hRC))
				{
					Helper::ErrorExit(L"BuildWindowCore");
				}

1 answer to this question

Recommended Posts

  • 0

I'm guessing I am not allowed to update it on a thread other than the UI thread, since it is part of the UI. But I don't want playing video to block the UI. So, I need to implement a scheme where I render one frame at a time, using something like a DispatcherTimer. Am I on the right track?

This topic is now closed to further replies.
  • Recently Browsing   0 members

    • No registered users viewing this page.
  • Posts

    • I disabled the optical camera in device manager.. leaving only the IR. This has fixed the issue for me...but only because I never use the optical camera. After each monthly update re-enable the optical just to see if it's fixed...but nope! It's annoying though how this issue hasn't been acknowledged by Microsoft.
    • Linux is a different kettle of fish to macOS and Windows, if it ran the software I required, I may have looked at it, instead of the Mac, also the Mac is a pretty powerful machine that uses less energy than x86 machines. I never in my widest dreams thought I would ever buy a Mac, the price and restrictions of the hardware, I always liked machines that I could update internally, one reason why I never liked laptops. But here I am, a nice little Mac mini M2 pro. I doubt i will replace it for a long time, if I ever do, it does what I need.
    • 106 years ago! A comic strip from 1919 predicted — eerily and accurately — what would happen if our phones fit into our pockets.  W. K. Haselden’s ‘The Pocket Telephone: When Will it Ring?’ was published in “The Mirror” when barely 1/3rd of American homes even had telephones. (A double irony: most of us are viewing this on our “pocket phones”.)
    • It's a feature, not a bug: Windows Hello face unlock no longer works in the dark by Usama Jawad Windows Hello is a security mechanism offered by Microsoft in compatible Windows PCs that allows customers to use biometric authentication mechanisms such as facial or iris recognition, fingerprint, or a PIN to access their accounts. Although it's a great feature when it works correctly, that is not always the case. Now, Microsoft has changed the way this feature works, and people aren't exactly pleased. As spotted by Windows Central, Windows Hello hasn't been working as people would expect since at least April's Patch Tuesday update. Since then, the mechanism requires both an infrared (IR) sensor and a color webcam to function correctly. Previously, Windows Hello relied on IR sensors to create a 3D facial map, just like the iPhone. IR sensors work quite well in low-light environments, but Microsoft does not allow customers to rely on them anymore due to a patch for a security vulnerability. It is important to note that most webcams don't illuminate the environment on their own and rely on external light. This essentially means that Windows Hello simply doesn't work in low-light environments for many users. In our own testing, Windows Hello seems to be working in low warm light, shown below: However, it now fails to work in an even dimmer environment, such as that with red light: That said, it seems that Microsoft has not implemented the change perfectly. Users have reported that if they disable their webcam through Device Manager, Windows Hello falls back to using IR sensors only and continues to function the way it used to. While that may act as a workaround for users right now, it'll be interesting to see if Microsoft patches this loophole down the line, too; it certainly wouldn't be surprising now that it's more widely known. Source: Windows Central
  • Recent Achievements

    • Week One Done
      patrickft456 earned a badge
      Week One Done
    • One Month Later
      patrickft456 earned a badge
      One Month Later
    • One Month Later
      Jdoe25 earned a badge
      One Month Later
    • Explorer
      Legend20 went up a rank
      Explorer
    • One Month Later
      jezzzy earned a badge
      One Month Later
  • Popular Contributors

    1. 1
      +primortal
      642
    2. 2
      ATLien_0
      278
    3. 3
      +FloatingFatMan
      172
    4. 4
      Michael Scrip
      156
    5. 5
      Steven P.
      132
  • Tell a friend

    Love Neowin? Tell a friend!