Jump to content

  • Log In with Google      Sign In   
  • Create Account


Inter-Process SetPixelFormat Fails with Vista


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
7 replies to this topic

#1 WaltN   Members   -  Reputation: 156

Like
0Likes
Like

Posted 26 December 2007 - 11:48 AM

I am trying to establish an OpenGL rendering context for a window handle owned by another process. ChoosePixelFormat works returning a good pixel format index. SetPixelFormat with that index fails with a last-error code of 0xc0070006. My environment is Vista with an NVIDIA 8800 GTX (Forceware 169.25, the latest). The above works on other systems tried, including Vista with an ATI RADEON 9600 and several XP configurations (none with 8800 GTX). The same code works on the Vista 8800 GTX system in a single process. This sure smells like a driver problem, but I have to confess that the inter-process communication makes this a peculiar environment. Yahoo and Google searches on "c0070006" suggest that others have gotten this message in other environments, but there is no definitive information for the error code. 1) Does anyone know what "c0070006" is trying to tell me? 2) Does anyone have any troubleshooting suggestions? Walt

Sponsor:

#2 Nypyren   Crossbones+   -  Reputation: 3939

Like
0Likes
Like

Posted 26 December 2007 - 03:46 PM

Did you check to make sure it's not some permissions/security issue? Try running your main process as administrator if you aren't right now...

#3 Yann L   Moderators   -  Reputation: 1794

Like
0Likes
Like

Posted 26 December 2007 - 04:30 PM

Definitely sounds like a permissions thing. You're trying to manipulate a resource owned by a different process (which in turn might be owned by a different user).

In fact, it 'working' on an ATI card could very well be an ATI driver bug (ignoring permissions)...


#4 WaltN   Members   -  Reputation: 156

Like
0Likes
Like

Posted 27 December 2007 - 03:30 AM

Both of those replies are very interesting. My process (the one I am coding) is the one that kicks off the process that creates a dialog window and hands me a handle to a child window for OpenGL I/O. The subsidiary process that owns the dialog window is a commercial product developed by others.

I tried running my process explicitly as Administrator with the same result as described in my original post -- failure. However, then it occurred to me that invoking my process with Administrator permissions may have nothing to do with the permissions of the subsidiary process that owns the dialog window.

I have queried the developer about this, and I'll report back any results.

Thanks,

Walt

#5 AverageJoeSSU   Members   -  Reputation: 516

Like
0Likes
Like

Posted 28 December 2007 - 03:52 PM

Um... i tried something similar. Using Pthread i tried a multithreaded OpenGL Color Cube, and there was a problem when the set pixel when glutInit was seperated , however, it didnt break every time... it worked maybe 1 out of 7 times. the other 6 it gave a pixel format error. Make sure your contexts are ok, i heard that you can only have one active OpenGL context at a time? or something like that.

#6 WaltN   Members   -  Reputation: 156

Like
0Likes
Like

Posted 29 December 2007 - 03:57 AM

Quote:
Original post by AverageJoeSSU
Um... i tried something similar. Using Pthread i tried a multithreaded OpenGL Color Cube, and there was a problem when the set pixel when glutInit was seperated , however, it didnt break every time... it worked maybe 1 out of 7 times. the other 6 it gave a pixel format error. Make sure your contexts are ok, i heard that you can only have one active OpenGL context at a time? or something like that.


Yep. I'm familiar with all of the above. In my current case, all of the OpenGL stuff (including rendering context) is in the same thread and process. It's the hWnd that is owned by another process.

I have an older application that splits application computation (e.g., animation displacements) and OpenGL/GLUT between two processes. The latter process employs a GLUT/OpenGL thread and a thread responsible for asynchronous communication with the other process. It works quite well. At the time, I think it was Nate Robins that advised me to not try to split any GLUT work between multiple threads. All of the OpenGL advice or documentation I have seen says to keep all OpenGL calls within the same thread that owns the rendering context. Other threads can be employed fruitfully if they avoid calling OpenGL functions themselves and are carefully synchronized.

On the current problem, I still have not heard anything from the developer. I assume he is off for the holidays.


#7 WaltN   Members   -  Reputation: 156

Like
0Likes
Like

Posted 07 January 2008 - 08:17 AM

Update: The developer suggested that I try running with Vista User Account Control disabled, which I did. The same SetPixelFormat failure occurred.

Curious, I installed all the prerequisite software on my wife's XP machine, which has an NVIDIA GeForce FX 5200 GPU. I updated Forceware to 169.21, the latest for XP. I got the same SetPixelFormat failure with the same return code.

Conclusion: This problem has nothing to do with Vista. It seems to occur only with NVIDIA GPUs. (I have to add that behavior with ATI GPUs tried is quirky.)

Walt

#8 WaltN   Members   -  Reputation: 156

Like
0Likes
Like

Posted 16 January 2008 - 03:08 AM

Update: An experiment has been tried directing DX9 output to a window owned by a separate process. (The window owner process is identical to that used in all the experiments reported above.) The experiment was successful with two different NVIDIA GPUs, several AMD GPUs, and an Intel chipset. It sure looks like my problem is tied to the OpenGL part of the NVIDIA driver.




Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS