PDA

View Full Version : Write to stencil buffer halts the application



shachar
12-15-2008, 09:13 AM
I am trying to add a simple feature to my application which will draw a black circular frame around an image.
I have tried to use the stencil buffer to implement this, and it works on one of my PC's and not on the other.
The one it works on has a Core 2 - 6600 CPU with Quadro FX1400 graphics card.
On an almost identical system (same graphic card but with Q6600 CPU) the function glDrawPixels which writes the stencil map takes forever to return (few minutes).
Has anyone experienced such an issue? Any hints on how to debug or overcome this?

Thanks in advance,
Shachar

sharp_pixel
12-15-2008, 01:34 PM
I once saw glReadPixels taking a few minutes but that was with the depth buffer, not stencil. The problem was that the requested format wasn't GL_FLOAT. Putting GL_FLOAT made it work at normal speed. Maybe you are experiencing something related.

dletozeun
12-15-2008, 02:44 PM
To speed up things, I would use a triangle fan to draw a circle in the stencil buffer and then draw the image everywhere outside of this circle setting stencil function correctly. This way you would benefit from hw acceleration which is not the case with glDrawPixels.
For the glDrawPixels that takes forever, I have no idea.

sharp_pixel
12-16-2008, 02:20 AM
It seems glDrawPixels is hardware accelerated if the format and type correspond to the write buffer (same thing with glReadPixels and the read buffer). If it is not the case, it falls to software which explains the problem with the depth buffer and GL_FLOAT and might explain the one with the stencil buffer.
Still, glDrawPixels will be slower than rendering a circle like dletozeun said.

yooyo
12-16-2008, 04:12 AM
In case that image is stored in sys mem, then glDrawPixels cannot be hw accelerated. If you store it in PBO then it can be hw accelerated (depending on matching types of src & dest).

_NK47
12-16-2008, 06:01 AM
you say that GL_FLOAT worked well on depth while other type took forever to recover. who knows what the driver does behind scenes, guess would be to convert the data which is trivial. don't see the point in questioning hw acceleration here. glDrawPixels mainly pushes pixel data from RAM to VRAM depending on the hardware its either slow or less slow but not accelerated (system RAM).

shachar
12-16-2008, 08:51 AM
Thanks for all the suggestions.
After writing this post i finally found the cause for this strange behaviour. It was a simple synchronization issue between the creation and initialization of the OpenGL window and the writing of the stencil buffer. After adding a small delay in the stencil buffer writing the issue was resolved :)
I still dont exactly understand why the glDrawPixels did not return quickly with fail.
I forgot to mention that I only use the glDrawPixels once at init when writing the stencil buffer, so I don't really mind if it takes a few ms.

dletozeun
12-16-2008, 12:13 PM
don't see the point in questioning hw acceleration here. glDrawPixels mainly pushes pixel data from RAM to VRAM depending on the hardware its either slow or less slow but not accelerated (system RAM).


Yes that is what I meant and what yooyo pointed out.