I'd wager that trying to deduce the original transform from the
parameters at that point in the pipeline would be counter-productive
since the destination coordinates represent the product of the
coordinates that the user requested and the current transform, so you
may end up trying to set a transform that is "a scale transform", but
not the same scale as the currently established transform.
With XRender, could you have multiple contexts - one validated with the
current transform, one validated with no transform, and then choose
which of the two to use in a given case? X11 has no problem with having
an unlimited number of outstanding contexts each with its own set of
rendering attributes so I would hope that XRender followed that model.
Of course, if the transform is on the surface rather than the context,
then that might blow that theory out of the water.
Another option would be to expose a getter for the "currently validated
transform" and simply untransform the destination coordinates by that
transform. The untransform operation would probably be a bit faster
than setting/resetting the transform...
...jim
Clemens Eisserer wrote:
Hi,
Thanks for the answers, I already have a guilty conscience because of
asking that much.
All in all the pipelines don't seem to be that complicated, ist just
... beginning with something new is always hard ;)
We recently made some major enhancements to the OGL and D3D pipelines in
6u10 to dispatch transformed wide single lines, and filled and drawn
rectangles directly to a primitive in the RenderQueue and got a huge
performance boost. We'll have to port those changes (along with the D3D
pipeline) to JDK7 sometime soon (after we're done fixing bugs in 6u10) and
then we'd like to continue doing performance work to make transformations of
some other common shapes avoid a lot of the overhead you are seeing here...
Thanks for letting me know about this, I'll have a look as soon as its
available :)
By the way, I've again another question about ScaledBlit:
The scale-method does handle over the already scaled destination
dimensions, but not the AffineTranform used to scale it:
public void Scale(SurfaceData src, SurfaceData dst, Composite comp,
Region clip,
int sx1, int sy1,
int sx2, int sy2,
double dx1, double dy1,
double dx2, double dy2)
The OpenGL pipeline calls from there its OGLBlitLoops.IsoBlit-Method,
and simply passes the "null" for the AffineTransform-Parameter along
with the already scaled coordinates and than calls validateContext, so
although most likely the scale transformation is used for all
primitives, the scaled blit resets the transformation just and the
next primitive rendered sets it again.
I am also quite confused about the validation-code:
// validate transform
if (xform == null) {
if (xformInUse) {
resetTransform();
xformInUse = false;
}
} else {
setTransform(xform);
xformInUse = true;
}
doesn't this set the transformation for any primitive that calls
validateContext?
I would have imagined some code like this:
if (xform != validatedXForm) ....
I guess I just misunderstand the code, but .. well ;)
For XRender this challenges me, because XRender uses a transformation
matrix on the destination surface (I was not able to find out wether
the transformation set on the source surface also impact e.g. src or
srcover operators). Because I don't get any AffineTransform, I don't
see any way to validate it against the last set transform.
I would be able to calculate the scale from the dstwidth/srcwith and
height and set the transformation just for this single operation
reseting it, but that would probably very inefficient.
Is there any need for the ScaledBlit at all, or could I somehow make
my pipeline fall back to an renderImageXform, which just seems to be a
more general case (and as far as I see it would not make my pipeline
any slower, at least theoretically)
Thank you in advance, lg Clemens
