Confusing points in the spec (blending, clip paths, etc.)
I am confused regarding the actual implementation of certain OpenVG functionality. A few of the definitions in the spec seem very strange to me.
E.g. I've browsed dozens of pages on the web and the reference images for SRC or DST at semi-transparent paint always show the src (or dst respectively) pixels actually mixed with the background (e.g. http://www.svgopen.org/2005/papers/a...index.html#S5. ). However the way that SRC function is defined in the OpenVG specification is:
C'r = C's * 1 + C'd * 0
Now, since C' is premultiplied we can write this in non-premultiplied space like this:
Cr = (Cs * As * 1) / (As * 1)
which obviously simplifies to
Cr = Cs
But this means that the source would _never_ be mixed with the background as the reference images usually show. Instead source alpha is completely ignored and the pixel color is directly copied onto surface. The function on the page that I linked is different though: it multiplies a premultiplied source color another time with source alpha which gives ther right result.
I think the big problem of the current specification is that it doesnt include eny images for the results of different blending operations. So I wonder... whats the right function to use? I you ask me, Cr = Cs is not much of a use anyway.
2) Clip paths
The specification says OpenVG is intended to be used for SVG viewers and the like. Then how is one supposed to implement clipping paths with it? There is no blending mode to change only the target alpha which we could use to draw the clipping shape into the alpha plane and clip via SRC_IN operator.
The only way to do it is to actually make an image a render target, draw a path onto it, then revert back to old render target and compose that image into existing mask on the mask surface. Why such a limitation when it could be so easy to integrate such functionality into the spec? The first and easiest thing would be to provide a way of blocking output into certain color planes, like the OpenGL glColorMask() function does.
3) Color interpolation
In the section 3.4.3 of the spec it says:
"In OpenVG, color interpolation takes place in premultiplied format in order to obtain correct results for translucent pixels."
However, I see no reason why interpolating in premultiplied format would give better results compared to non-premultiplied interpolation. On the homepage of the AmanithVG implementation, they even state that:
"Interpolating premultiplied color stops is not equal, nor correct, to produce premultiplied colors from the interpolation output. The example below shows a linear gradient made of three stops in the format (t,r,g,b,a): (0.0, 1.0, 1.0, 1.0, 1.0) - (0.5, 0.0, 1.0, 1.0, 0.0) - (1.0, 1.0, 1.0, 1.0, 1.0)"
And I think it is more than obvious why this is not right thing to do. If you premultiply a color with alpha=0 it will produce a rgba color (0,0,0,0) and thus discard all the actual color information and prevent it from affecting the interpolated values. So whats up with this?
[edit: a typo]
Re: Confusing points in the spec (blending, clip paths, etc.
Originally Posted by ileben
VG_BLEND_SRC is thge closest thing we have to a way of turning blending off (although there is that annoying division by 0 = 0 thing to make life interesting). The color you paint with is the color you get. As such, in any software implemention this mode should be the fastest (blending based on anti-aliasing is independant of this). If you want a regular blending mode, just leave the default setting SCR_OVER.
Rendering into image (pbuffer of such like) and then using it was an alpha mask is indeed the only way I too see to implement clip paths. Clip paths though, if I am not mistaken, are part of the full SVG spec which includes many other things that are also difficult with OpenVG (group opacity for example [and pre OpenVG 1.0.1, dashing]). In addition, full SVG viewers have to be able to parse things like style sheets and java script, making them rather bulky.
Because of all this, SVG tiny was deleoped which doesn't have all the features of full SVG. I believe clippaths are one of the features in the full spec which did not make it to tiny.
I don't know why khronos made the choices it did (some of the color conversion/format choices are even much more questionable). It's the way it is.
I guess the thinking was that translucent is translucent, and interpolating some gray scale with something translucent and getting getting Blue for example must have seemed weird to them. *shrug*