Apologies for the large paste, though this bit of code feels a bit weird: // transformIsSimple tells you if it's simple enough to use scissoring static bool transformIsSimple (const GLMatrix &transform) { const float *t = transform.getMatrix (); return // t[0] can be anything (x scale) t[1] == 0.0f && t[2] == 0.0f && t[3] == 0.0f && t[4] == 0.0f && // t[5] can be anything (y scale) t[6] == 0.0f && t[7] == 0.0f && t[8] == 0.0f && t[9] == 0.0f && // t[10] can be anything (z scale) t[11] == 0.0f && // t[12]..t[14] can be anything (translation) t[15] == 1.0f; } void GLScreen::glEnableOutputClipping (const GLMatrix &transform, const CompRegion ®ion, CompOutput *output) { WRAPABLE_HND_FUNCTN (glEnableOutputClipping, transform, region, output) // Bottom-left corner of the output: const GLint x = output->x1 (); const GLint y = screen->height () - output->y2 (); const GLsizei w = output->width (); const GLsizei h = output->height (); // Transformed (only scale and translation is supported!) const float *t = transform.getMatrix (); const GLfloat scalex = t[0], scaley = t[5], transx = t[12], transy = t[13]; const GLfloat centrex = x + w / 2.0f; const GLfloat centrey = y + h / 2.0f; const GLfloat scaledw = w * scalex; const GLfloat scaledh = h * scaley; const GLint tx = centrex - (scaledw / 2.0f) + transx * w; const GLint ty = centrey - (scaledh / 2.0f) + transy * h; glScissor (tx, ty, scaledw, scaledh); glEnable (GL_SCISSOR_TEST); } void GLScreen::glDisableOutputClipping () { WRAPABLE_HND_FUNCTN (glDisableOutputClipping) glDisable (GL_SCISSOR_TEST); } The historical purpose of glEnableOutputClipping and glDisableOutputClipping was for plugins to specify their own clip planes. At the moment, we still have extension points for those functions, although the usage of these functions have effectively been hijacked for scissoring to the output region (scaled and transformed by an orthogonal transformation matrix). It feels a bit weird having these extension points remain if they don't do anything. In addition, the plugins are still going to try and enable their own clip planes (see cube) along with scissoring, and this codepath will be taken even if we are using the shader codepath without support for such clip planes. I think there are two roads we can take: 1) Remove glEnableOutputClipping/glDisableOutputClipping entirely - go with either scissoring if the transfomation matrix is orthogonal, or stencil buffers failing that. 2) Re-introduce glEnableOutputClipping/glDisableOutputClipping properly, make them the last resort case in case the transformation matrix is not orthogonal and stencil buffering is not available. This codepath should only be taken if we aren't using vertex shaders, or the vertex shader should be disabled entirely if we are. I think there's another consideration that needs to be made here: At the moment, we are currently allowing plugins to specify an arbitrary clip region to be translated into clip space whenever the screen is painted transformed. This means that they don't necessarily have to provide a region that fills the output (even though they historically have). The question is then - in our API, do we wish to allow this? If not, I think we should make glBufferStencil a nonwrappable function and update either the scissor region (if appropriate) or the stencil buffer (if necessary) using only the transformed co-ordinates of the current output. If we do want to allow arbitrary clipping regions, then I think the API should be redesigned such that plugins can provide an arbitrary region in world space, and then we should use scissoring where both the region and the transformation matrix is orthogonal, or stencil buffers where it isn't.