[OpenJDK 2D-Dev] [9] Review request for 8023794: [macosx] LCD Rendering hints seems not working without FRACTIONALMETRICS=ON
Andrew Brygin
andrew.brygin at oracle.com
Fri Oct 10 14:34:17 UTC 2014
Hello Denis,
could you please take a look at a preliminary version of the fix?
http://cr.openjdk.java.net/~bae/8023794/9/webrev.00/
This fix promotes the text antialiasing from grayscale to LCD if
destination surface data is able to render LCD, and provides
selection of an appropriate text pipeline for both cases.
It also separates production of gatyscale and LCD glyph images.
Thanks,
Andrew
On 10/9/2014 4:13 PM, Denis Fokin wrote:
> Hi Andrew,
>
> I am happy about you participation in this work!
>
> Looks like, I have missed this letter, while being sick. Sorry about this.
>
> I signed OCA, but I have not gotten access to cr.openjdk.java.net
> <http://cr.openjdk.java.net> yet. This is the reason why I have not
> updated the webrev.
>
> I think that an API that is consistent with other platforms is a great
> solution. It just requires more efforts and multi-platform testing. On
> the other hand, a property could be a safe start.
>
> As for the offscreen rendering, I have some kind of a workaround with
> the next approach.
>
> In BufImgSurfaceData.getRenderLoops() I always return
> super.getRenderLoops(sg2d), and never solid loops.
>
> In case if “useQuartz" flag is specified, I return only
> lcdTextRenderer from SurfaceData.getTextPipe()
>
> Of course it is a brute force approach, but it allows producing a
> legible text in case of offscreen rendering.
>
> Thank you,
> Denis.
>
> On 29 Sep 2014, at 19:30, Andrew Brygin <andrew.brygin at oracle.com
> <mailto:andrew.brygin at oracle.com>> wrote:
>
>> Hello Denis,
>>
>> I am not sure whether we should use 'apple.awt.graphics.UseQuartz'
>> property.
>> Probably we have to change the text antialiasing defaults for macosx
>> instead.
>>
>> I am working on the issue with software loops. I will update the thread
>> with my findings.
>>
>> Thanks,
>> Andrew
>>
>> On 9/3/2014 3:32 PM, Denis Fokin wrote:
>>> Hi Sergey and 2d team,
>>>
>>> I have rewritten the fix. It works fine for text rendered on window
>>> using OpenGL.
>>>
>>> http://web-dot.ru/openjdk/8023794/webrev.00/index.html
>>>
>>> It is incomplete though. It does not work for rendering in a
>>> buffered image.
>>>
>>> Additionally, I have not tested the code on other platforms except
>>> MacOS X.
>>>
>>> To enable the antialiasing you should pass
>>>
>>> -Dapple.awt.graphics.UseQuartz=true
>>>
>>> to java.
>>>
>>> The current issue now is the glyph info bytes that are passed from
>>> CGGlyphImage to AATextRenderer.
>>>
>>> To render data we use DEFINE_SOLID_DRAWGLYPHLIST* macros. Basing on
>>> the macros a set of functions is generated for the next loops.
>>>
>>> sun/java2d/loops/ByteGray.c
>>> sun/java2d/loops/ByteIndexed.c
>>> sun/java2d/loops/FourByteAbgr.c
>>> sun/java2d/loops/FourByteAbgrPre.c
>>> sun/java2d/loops/Index12Gray.c
>>> sun/java2d/loops/Index8Gray.c
>>> sun/java2d/loops/IntArgb.c
>>> sun/java2d/loops/IntArgbBm.c
>>> sun/java2d/loops/IntArgbPre.c
>>> sun/java2d/loops/IntBgr.c
>>> sun/java2d/loops/IntRgb.c
>>> sun/java2d/loops/IntRgbx.c
>>> sun/java2d/loops/LoopMacros.h
>>> sun/java2d/loops/ThreeByteBgr.c
>>> sun/java2d/loops/Ushort555Rgb.c
>>> sun/java2d/loops/Ushort555Rgbx.c
>>> sun/java2d/loops/Ushort565Rgb.c
>>> sun/java2d/loops/UshortGray.c
>>> sun/java2d/loops/UshortIndexed.c
>>>
>>> For instance, C preprocessor generates the next code for IntRgb.c
>>>
>>> voidIntRgbDrawGlyphListLCD(/*…*/){
>>> jint glyphCounter, bpp;
>>> jint scan = pRasInfo->scanStride;
>>> IntRgbDataType *pPix;
>>> fprintf(__stderrp, "NAME_SOLID_DRAWGLYPHLISTLC\n");
>>> jint srcA;
>>> jint srcR , srcG, srcB;;;;
>>> do {
>>> (srcB) = (argbcolor) & 0xff;
>>> (srcG) = ((argbcolor) >> 8) & 0xff;
>>> (srcR) = ((argbcolor) >> 16) & 0xff;
>>> (srcA) = ((argbcolor) >> 24) & 0xff;
>>> } while (0);;
>>> // and so on…
>>>
>>> Looks like rgb loop expects to see 4 8-bit color channels per pixel.
>>>
>>> For now, I do not understand which contract should be honoured to
>>> meet DEFINE_SOLID_DRAWGLYPHLIST* expectations, i.e. how should I
>>> place bytes in GlyphInfo.
>>>
>>> May be it should be set somewhere in Java code.
>>>
>>> Could anyone share this knowledge with me?
>>>
>>> Thank you,
>>> Denis.
>>>
>>>
>>> On 09 Jul 2014, at 19:22, Sergey Bylokhov
>>> <Sergey.Bylokhov at oracle.com <mailto:Sergey.Bylokhov at oracle.com>> wrote:
>>>
>>>> Hello, Denis.
>>>> Thanks for this research!
>>>> On 09.07.2014 15:13, Denis Fokin wrote:
>>>>> The current version consist of three parts.
>>>>>
>>>>> 1. We are rendering glyphs in offscreen images using Quartz
>>>>> functions. This does not work without kCGBitmapByteOrder32Host mask.
>>>> I assume LCD hint does not work? this looks good.
>>>>>
>>>>> 2. We assume that subpixel antialiasing should not be used on a
>>>>> non-opaque surface. As I understand the vImage in
>>>>> CGLVolatileSurfaceManager is not related directly to our window.
>>>>> For a start, I have hardcoded Transparency.OPAQUE, but it requires
>>>>> much better understanding of the architecture to make a more
>>>>> proper solution.
>>>> It is related to the CGLOffScreenSurfaceData, which is used as a
>>>> surface for VolatileImages. I check this code and looks like we
>>>> ignore type of the ColorModel and create a transparent native
>>>> texture anyway.
>>>>>
>>>>> 3. When I started using CGGI_CopyImageFromCanvasToRGBInfo as a
>>>>> rendering mode, I had found that the little endian mode should be
>>>>> undefined. Again, it might be an improper way to do this.
>>>> It seems __LITTLE_ENDIAN__usage in this file should be checked.
>>>>>
>>>>> Thank you,
>>>>> Denis.
>>>>>
>>>>> diff -r f87c5be90e01
>>>>> src/macosx/classes/sun/java2d/opengl/CGLVolatileSurfaceManager.java
>>>>>
>>>>> ---
>>>>> a/src/macosx/classes/sun/java2d/opengl/CGLVolatileSurfaceManager.javaFri
>>>>> Jun 20 10:15:30 2014 -0700
>>>>>
>>>>> +++
>>>>> b/src/macosx/classes/sun/java2d/opengl/CGLVolatileSurfaceManager.javaWed
>>>>> Jul 09 14:50:09 2014 +0400
>>>>>
>>>>> @@ -108,7 +108,7 @@
>>>>>
>>>>> } else {
>>>>>
>>>>> CGLGraphicsConfig gc =
>>>>>
>>>>> (CGLGraphicsConfig)vImg.getGraphicsConfig();
>>>>>
>>>>> - ColorModel cm =
>>>>> gc.getColorModel(vImg.getTransparency());
>>>>>
>>>>> + ColorModel cm =
>>>>> gc.getColorModel(Transparency.OPAQUE);
>>>>>
>>>>> int type = vImg.getForcedAccelSurfaceType();
>>>>>
>>>>> // if acceleration type is forced (type !=
>>>>> UNDEFINED) then
>>>>>
>>>>> // use the forced type, otherwise choose one based
>>>>> on caps
>>>>>
>>>>> diff -r f87c5be90e01 src/macosx/native/sun/font/CGGlyphImages.m
>>>>>
>>>>> --- a/src/macosx/native/sun/font/CGGlyphImages.mFri Jun 20
>>>>> 10:15:30 2014 -0700
>>>>>
>>>>> +++ b/src/macosx/native/sun/font/ .mWed Jul 09 14:50:09 2014 +0400
>>>>>
>>>>> @@ -196,6 +196,8 @@
>>>>>
>>>>> #pragma mark --- Font Rendering Mode Descriptors ---
>>>>>
>>>>> +#undef __LITTLE_ENDIAN__
>>>>>
>>>>> +
>>>>>
>>>>> static inline void
>>>>>
>>>>> CGGI_CopyARGBPixelToRGBPixel(const UInt32 p, UInt8 *dst)
>>>>>
>>>>> {
>>>>>
>>>>> @@ -366,7 +368,8 @@
>>>>>
>>>>> canvas->context = CGBitmapContextCreate(canvas->image->data,
>>>>>
>>>>> width, height, 8, bytesPerRow,
>>>>>
>>>>> colorSpace,
>>>>>
>>>>> - kCGImageAlphaPremultipliedFirst);
>>>>>
>>>>> + kCGImageAlphaPremultipliedFirst
>>>>>
>>>>> + |
>>>>> kCGBitmapByteOrder32Host);
>>>>>
>>>>> CGContextSetRGBFillColor(canvas->context, 0.0f, 0.0f, 0.0f, 1.0f);
>>>>>
>>>>> CGContextSetFontSize(canvas->context, 1);
>>>>>
>>>>
>>>>
>>>> --
>>>> Best regards, Sergey.
>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20141010/8c867bfb/attachment.html>
More information about the 2d-dev
mailing list