[cairo] Avoiding seams with CAIRO_OPERATOR_SATURATE (the OpenGL way)

[Mike Emmel]

Is there a textbook answer for this the way its been presented makes
it difficult to google for but this seems to be the type of problem
that's been solved a few times. I vaguely remember a similar problem
with adjacent polygons of various types in postscript renders. So what
is the "classic" solution ?

Google finds results like this but that's not what I'm remembering
http://www.sjbaker.org/steve/omniv/tiling_textures.html


On 6/11/05, Robert O'Callahan <rocallahan at novell.com> wrote:
> On Sat, 2005-06-11 at 00:45 +0200, David Reveman wrote:
> > So, OpenGL's GL_SRC_ALPHA_SATURATE blending factor can only be used with
> > non-premultiplied images, that's why glitz doesn't accelerate
> > CAIRO_OPERATOR_SATURATE right now. There's no way to accelerate RENDER's
> > saturate operator with OpenGL, except for when using solid colors of
> > course. I'll add saturate operator support for solid colors in glitz
> > sometime soon but that's pretty much all we can do for acceleration of
> > saturate operator with OpenGL.
> 
> That's not good.
> 
> There are a couple of other problems with this approach (although I do
> find it intriguing):
> 
> Changing all our code to paint front to back would be really painful,
> especially because we'd still have to support back to front painting
> (for non-cairo targets in the interim, and maybe for cairo PDF, unless
> we can work SATURATE support in there by some magic).
> 
> Suppose you start with a black background and fill it with 50%-alpha
> white. Then you fill a white rectangle at (0,0,1,0.5). Using SATURATE
> (and doing these in reverse, of course) the pixel (0,0)-(1,1) ends up
> solid white. But the "true" result should, in this case, be 75% white.
> The underlying problem is that alpha values are unable to distinguish
> "partially translucent shape covering the entire pixel" from "shape
> partially covering the pixel" so it seems to me we must accept either
> this error or seams if our solutions are restricted to compositing
> operators. Now it could well be that this is much less of a problem than
> seams, in real usage, in which case this would be the right thing to do
> if the other issues were fixed.
> 
> Mozilla's objects do have a uniform Z value, even with SVG, but we still
> don't want to see seams along the edges of adjacent objects. For example
> if the star-and-ring example were drawn with Mozilla SVG, each
> individual primitive shape as seen by Mozilla would have a uniform Z
> value, but to the author the combination is *logically* a shape with
> nonuniform Z value so seams would be anomalous. The same thing can arise
> even in HTML/CSS, where authors often position elements adjacent to each
> other and expect continuity.
> 
> Rob
> 
> 
> _______________________________________________
> cairo mailing list
> cairo at cairographics.org
> http://lists.freedesktop.org/mailman/listinfo/cairo
>