Seems like this should work although 2D doesn't use an alpha component in the LCD software loops that's not an issue so long as alpha is 1 (ie 255). The equation you point to then reduces to the blend 2D does. Eg for the red component : dstR = srcR * maskR + (1-maskR) * dstR; where maskR is the LCD glyph cache component for the red subpixel.
Your ARGB values for a solid pixel would look like 0xffffffff and for a transparent pixel 0xff000000. So if its all zeros then the above is dstR = (srcR * 0) + (1-0) * dstR; So it should leave dst unchanged (if not untouched). Since you are getting yellow where the glyph cache component will have all zeros, then clearly something has gone wrong, but I think its in the details rather than the concepts. Looking at the yellow RGB in your .png its 0xfefe00 I'm going to guess you have the alpha value set as zero and you've got something like RGBA when you should have ARGB, so the zero alpha component is being interpreted as the blue component. And "fe" instead of "ff" is a rounding error somewhere. I'd hope xrender bypasses doing the blend if the component is "00" or "ff", but maybe it doesn't. Verify your ARGB values that are uploaded are what you expect and in the correct order required. If they are then maybe its something in the xrender usage. The LUTs are used as pre and post conversions on the components of the destination. They apply an inverse gamma adjustment on the component that is read from the device, and a gamma adjustment on the results before they are written back. If Xrender does something like this at all, then it should have some way for you to specify the gamma value. If it doesn't then you'll either have to accept what it does, or if the results aren't ideal, then Xrender can't be used at all for this case. The effect of this is to increase or decrease the contrast, and JDK needs this to be compatible with Windows behaviours. So if you don't or can't apply it then the text rendered will be different in contrast between the xrender and the other pipelines, but has no bearing on the bigger problems you are seeing. -Phil. Clemens Eisserer wrote:
Hello, I started working on lcd-antialiased text now that grayscale and non-AA case works fine (http://linuxhippy.blogspot.com), however I experience some problems. I know the basics, and how it basically works - but I have a hard time understanding the insights. I am running a bit out of time, so I hope I don't bother anybody by asking on this list. XRender provides (only) component alpha for subpixel-antialiasing. The glyph is uploaded to an ARGB surface which is used as mask, each component acts as mask for its counterpart (http://anholt.livejournal.com/32058.html). I tried uploading the glyph-images produced by Java2D directly into an ARGB-glyphcache and using that, but the results are (of course) not intended: http://picasaweb.google.com/linuxhippy/Subpixel It seems the concepts do not match 100%, e.g. java2d does not provide an alpha-component. I tried setting the alpha-value manually but the results are really strange - for 100% alpha the background suddenly turns into yellow (with black used as src over white as background) And what is the LUT-Table for, why doesn't XRender need it? Has the XRender approach disavantages, and/or what is the cause the Java2D uses a more complex approach? Thank you for your patience and help, Clemens
