[OpenJDK 2D-Dev] [9] Review request for 8023794: [macosx] LCD Rendering hints seems not working without FRACTIONALMETRICS=ON
Denis Fokin
denis.fokin at gmail.com
Fri Oct 10 17:35:25 UTC 2014
Hi Phill,
I think this was commented out because the implementation did not work without kCGBitmapByteOrder32Host mask.
Thank you,
Denis.
On 10 Oct 2014, at 20:54, Phil Race <philip.race at oracle.com> wrote:
> I don't have my head around all these changes but a lot of it seems to
> imply we really weren't asking for LCDon Mac when we could/should.
>
> The change in the shared SurfaceData.javais something I want to
> ask about as you have commented out as follows ..
> ;
> 749
> 750 // TODO: we have to take into account aaHint on macosx
> 751 //case SunHints.INTVAL_TEXT_ANTIALIAS_ON:
> 752 // return aaTextRenderer;
>
> ...
>
> that looks like the case where the application code has *explicitly*
> specified greyscale (ON==greyscale) so I don't see why you need
> to go check the fontinfo in this case ?
>
> -phil.
>
> On 10/10/2014 07:34 AM, Andrew Brygin wrote:
>> 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 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> 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
>>>>>
>>>>> void IntRgbDrawGlyphListLCD(/*…*/){
>>>>> 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> 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/85f6f2c8/attachment.html>
More information about the 2d-dev
mailing list