[OpenJDK 2D-Dev] How are transformations done and some other questions

[Jim Graham]

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