[OpenJDK 2D-Dev] Problems with lcd-antialiased glyphs
Phil Race
Phil.Race at Sun.COM
Wed Jun 11 18:18:41 UTC 2008
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
More information about the 2d-dev
mailing list