Hi Clemens,
Clemens Eisserer wrote:
1.) I've created a seperate struct to hold the per-surface xrender
data structures, similar to ShmPixmapData.
I initialize it in JX11SD_InitWindow for windows, because initSurface
where I do the xrender-initialization for pixmaps is not called for
windows.
Is there a better place to do it for windows, maybe unified for both
windows and pixmaps?
I would indeed suggest to unify your xrender-related initialization
so the same code is used to init xrender-related stuff for
window and pixmams. From that perspective doing it in
InitWindow sounds fine.
I assume that you expect both X11 renderer and XRender renderer
to be able to render to the same surface, right?
2.) For now I also leak xrender-resources, because
Java_sun_java2d_x11_X11SurfaceData_initOps is also called at
window-resize. Whaht should I do about this?
Should I store xrender-related data in the peers, like its done with
the window-handle?
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.
3.) I am currently using lock/unlock/getrasinfo for MaskFill, is it
worth to write seperate upload-routines because of the overhead those
functions have (JNI calls, Locking, Xsync, ...)?
Likely.
4.) In X11SD_InitWindow I've currently RGB24 hardcoded, but I guess
this assumption will be wrong once translucent windows are supported
by Java. How can I get the surfacetype of a window?
You can call getSurfaceType() which is defined in SurfaceData,
Or did you mean something different?
5.) Currently I set the color by passing SunGraphics2D.pixel down to
the native library, which premultiplies it. I guess this „hardcoded"
way of doing things is not really good.
Is the right way to install an appropriate ColorModel?
For premultiplied surfaces I need to specify a ColorSpace, which one
is the right for me?
SurfaceData has an associated SurfaceType, which defines a PixelConverter,
which converts rgb to pixels for particular surfae type. So when
Graphics.setColor is called, the current surfaceData's pixel converter is
called to convert color's rgb to Surface's pixel format.
So if your surface has correct surface type the conversion should
be done automatically. See how it is done for OGL or D3DSurfaceData
classes.
6.) Is there a way to get force a BufferedImage to be cached?
For now texturepaints only work when the image has been drawn already,
otherwise its not cached any my pipeline can't handle this case.
Yes, take a look at D3D/OGLBufImgOps for example. There's a piece
of code which forces the surface to be cached:
if (!(srcData instanceof D3DSurfaceData)) {
// REMIND: this hack tries to ensure that we have a cached texture
srcData =
dstData.getSourceSurfaceData(img, sg.TRANSFORM_ISIDENT,
CompositeType.SrcOver, null);
if (!(srcData instanceof D3DSurfaceData)) {
return false;
}
}
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.
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.
9.) When scaling images e.g. only on the x-axis, the result is also
blurred and smeared over the y-axis.
http://article.gmane.org/gmane.comp.freedesktop.xorg/30507
(One of the screenshots is the wrong one, simply have a look for the
other images in the album of the right image)
Any ideas where this could come from, or how I could avoid it?
Setting RepeatPad helps a bit (at least Nimbus looks right), but seems
to fall back to software.
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.
10.) Just from a quick look at
http://linuxhippy.blogspot.com/2008/07/nimbus_20.html, any ideas what
could cause this artifact? It quite struggles me for some time ;)
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:
http://hg.openjdk.java.net/jdk7/2d/jdk/file/3efc003bf097/src/windows/native/sun/java2d/d3d/D3DContext.cpp
You can use this rather exhaustive regression test (from the
2d repo, not yet in the jdk7 master):
test/sun/java2d/SunGraphics2D/DrawImageBilinear.java
Thanks,
Dmitri
