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.bry...@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.bylok...@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. >>> >> >