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 <[email protected]> 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 <[email protected]> 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 <[email protected]> >>>>> 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. >>>>>> >>>>> >>>> >>> >> >
