[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-2d-dev
Subject:    [OpenJDK 2D-Dev] xrender-pipeline prototype/hack uploaded
From:       linuxhippy () gmail ! com (Clemens Eisserer)
Date:       2008-07-22 8:24:53
Message-ID: 194f62550807220124l3f044040y45add89fc22e6de3 () mail ! gmail ! com
[Download RAW message or body]

Hello Dmitry,

>  I assume that you expect both X11 renderer and XRender renderer
>  to be able to render to the same surface, right?
If the XRender pipeline is enabled, although it shares the native
datastructures with the X11 pipeline,
it does not use its drawing functionality, except for copyArea.

>  When window is resized X11SurfaceData is replaced. So you should
>  dispose of your xrender resources for old surface in X11SD_Dispose
>  just like everything else is. A new surface will be created and
>  initialized when needed.
Ah, thanks for the hint :)

>  You can call getSurfaceType() which is defined in SurfaceData,
>  Or did you mean something different?
Yes this should work.

>  So if your surface has correct surface type the conversion should
>  be done automatically. See how it is done for OGL or D3DSurfaceData
>  classes.
I'll have a look, thanks.

>> 7.) In X11PMBlitLoops/X11PMTransformedBlit/Transform I simply use the
>> inverted transformation on the source. However this means my drawing
>> area is from 0,0 ->bounds.x/bounds.y.
>> If I don't do it this way, e.g. the rotation point is moved.
>> Is there a way to translate the inverted transform, so that I don't
>> need to composite from 0,0?
>
>  Can you elaborate on this one? I don't quite follow.
XRender does only know about transformations set on the source-pixmap.
So when e.g. a rotated image should be drawn, ideally you set the
inverse transformation
on the source and draw only the rectangular area surrounding the
rotated rectangular image.

What I do for now is simply inverting the transformation set on
Graphics2D, however this transformation is relative to 0,0 and also
contains the translation relative to that point, so I also have to
specify to start the composition operation at 0,0 - because the
inverse transformation will translate the image to the place it
belongs.

The drawback of this is that a much larger area than really needed is
involved in the composite operation:
http://picasaweb.google.com/linuxhippy/Transformations/photo#5225748085079311426

I tried to modify the source-transformation, however I always broke it.
It worked when shear was positive, but not when negative; the rotation
point was moved, ....

http://picasaweb.google.com/linuxhippy/Transformations/photo#5225749165321130706
So, instead of composite the whole black area ... would it be possible
to adjust the source-transformation so that I would only have to
composite the red rectangle, and if yes, how?


>
>> 8.) I am a bit puzzeled with the problem described at:
>> http://thread.gmane.org/gmane.comp.freedesktop.xorg/30450/focus=30476
>> Is this a bug, or an unwelcome feature? Any ideas how I can work arround
>> it?
>> I already do clipping the shape-outline however due to rounding errors
>> I either cut something away or get a black thin line.
>
>  That looks like xrender bug to me, unless you're using some
>  mode which tells it to update pixels other than those mapped
>  from the source image to the destination.
No, I told XRender I would like to get "RepeatNone".
Well this is a rather serious bug because for now it breaks more or
less all shear-transformations for single images when XRender is used
:-/


>  I think it could be caused by incorrect pixel to texel mapping -
>  (or the equivalent in xrender). Basically your pixels don't
>  fall where they should, so filtering is applied.
>    http://msdn.microsoft.com/en-us/library/bb219690.aspx
>  See my comments below for 10.
>
>  I don't know how much xrender similar to d3d in this regard
>  but it's worth a look.
Thanks a lot for the hint. XRender itself is pixel-based, so the
driver has to take care about the mapping.
I tried it with XAA (which does transformations using pixman) and the
problem was gone.
I already reported the problem on the intel-mailinglist.


>  Very similar stuff was addressed by these fixes in d3d pipeline
>  and was caused by incorrect pixel to texel mapping:
>    http://bugs.sun.com/view_bug.do?bug_id=6603000
>    http://bugs.sun.com/view_bug.do?bug_id=6602861
>
>  For the fix see SetTransform() method in D3DContext.cpp:
Thanks again for saving me hours of desperate debugging :)
Inspired by 9. I tried it woth Xorg-1.5/Intel-2.3.2 and the bug was gone.

Thanks a lot for your detaild answers, lg Clemens


[prev in list] [next in list] [prev in thread] [next in thread]