LWJGL Forum

Programming => OpenGL => Topic started by: avm1979 on January 10, 2008, 16:28:06

Title: Stencil buffer performance and availability
Post by: avm1979 on January 10, 2008, 16:28:06
Hi,

I'm currently writing a UI api for LWJGL.  I'd like to be able to use the stencil buffer for clipping (for example, having a Frame clip its contents), but I'm concerned about 2 things:

1) Performance - if there are multiple clipping frames that need to be rendered, I'll have to for each one:

How much of a performance problem is this going to be?  I'm assuming there are two potential hits here - rendering with the stencil buffer enabled will be slower (since it's an extra check for every pixel), and actually rendering the quad on the stencil buffer.  How do those compare, to, say, simply rendering a quad?

2)  Availability.  How many video cards don't support stencil buffers?  It seems like most do, by now, but I'm not sure.

Thank you in advance for the help.
Title: Re: Stencil buffer performance and availability
Post by: elias4444 on January 10, 2008, 17:31:49
Well, here's my overly opinionated responses:  ;)

1) Everything costs something. Render another quad, it costs performance. I use the stencil buffer quite a bit in my projects, and have learned a few tricks to save some rendering time. Probably the biggest one is to only clear the stencil buffer once per frame. Secondly, you usually don't have to draw complex geometry to get the effect you want, just general shapes that fit the outlines you need. Also, from what I've seen thus far, drawing to the buffer hasn't proven anymore draining than drawing in anything else.

2) I haven't found any cards that have a problem with supporting stencil buffers. Even Intel's really awful cards and drivers seem to support it.

Notice: Your mileage may vary.  ;D

Title: Re: Stencil buffer performance and availability
Post by: avm1979 on January 10, 2008, 18:06:51
Thanks, elias.

Good to know about clearing it only once.  Hmm.  I guess it'd be easy enough to re-draw the same initial shape in black to clear it off (I think I'll only need to use quads, like you're saying - nothing very complex).

Suppose I just drew a quad to the stencil buffer, and am rendering a scene such that it only renders where the quad is.  From your experience, how much (or at all?) slower is this than just rendering the same scene w/o the stencil?

Good to hear general availability shouldn't be an issue.

Thanks again, really helps to get the info from someone that's done this before  ;D
Title: Re: Stencil buffer performance and availability
Post by: elias4444 on January 10, 2008, 19:16:26
I'd have to say... I have no idea.  ;)

SO much depends on what you're doing in that scene, the hardware you're on, etc.. Off the top of my head, I'd say you won't notice much of a hit, if anything, but I'd recommend you test that exact scenario to find out for sure.

Title: Re: Stencil buffer performance and availability
Post by: avm1979 on January 10, 2008, 21:37:58
Fair enough  :)

I think I'll give it a whirl with some very basic stuff (just drawing a bunch of quads) and see how it compares.  Thanks for the help.
Title: Re: Stencil buffer performance and availability
Post by: spasi on January 11, 2008, 14:51:23
You don't have to use the stencil buffer for this. A better option would be GL_SCISSOR_TEST and glScissor, which is practically free performance-wise. It's easy to track the currect clip rectangle using a clip "stack" in your ui code. You would then only use the stencil buffer for non-rectangle containers.
Title: Re: Stencil buffer performance and availability
Post by: avm1979 on January 11, 2008, 16:23:17
Quote from: spasi on January 11, 2008, 14:51:23
You don't have to use the stencil buffer for this. A better option would be GL_SCISSOR_TEST and glScissor, which is practically free performance-wise. It's easy to track the currect clip rectangle using a clip "stack" in your ui code. You would then only use the stencil buffer for non-rectangle containers.

Ahh, thank you very much!  Looked at the docs, that's perfect, and looks like it'll be very easy to use.

Edit: Got it working, couldn't be easier.  Very cool.