I am still unable to get subpixel antialiasing to work for netbeans
with this patch. Are there circumstances (eg. certain surface
configuration or double buffering), where subpixel antialising will be
disabled?
On 27 May 2015 at 15:21, Torgeir Veimo torgeir.ve...@gmail.com wrote:
This looks
OK .. it's a step forward, so approved, although there is more to be done.
I do ask that you however restore this comment until you actually remove the
constraint :
405 * - and the destination is opaque
-phil.
On 05/21/2015 07:23 AM, Andrew Brygin wrote:
Hello Phil,
I have changed
Hello Phil,
I have changed the default reverse gamma to 180:
http://cr.openjdk.java.net/~bae/8023794/9/webrev.10/
I also did some experiments with the lcd contrast, and found that
value 160 decreases the discrepancy a bit: 21 instead of 29 with
the default lcd contrast value (140).
Hi,
So 1.79 is essentially 1.8 which is what Mac historically used as gamma.
So I'd pick 180 instead of 179
Since that value minimises the discrepancy it's looking positive but
there's still a discrepancy.
Before we 'live with it', I'd be interested to know what happens if you
set your
Hello Phil,
please take a look to updated version of the fix:
http://cr.openjdk.java.net/~bae/8023794/9/webrev.09/
The main difference is in glyph generation. I have implemented 'reverse
gamma correction'
approach instead of 'glyph blending'. By default we use gamma value
which provides
Hello Phil,
please see my comments inline.
On 4/23/2015 11:15 PM, Phil Race wrote:
373 fontHints.put(RenderingHints.KEY_ANTIALIASING,
RenderingHints.VALUE_ANTIALIAS_ON);
Why do we need this ? Historically in the (non-OSX) code this would
slow things down by making
text rendering
Hi Andrew,
373 fontHints.put(RenderingHints.KEY_ANTIALIASING,
RenderingHints.VALUE_ANTIALIAS_ON);
Why do we need this ? Historically in the (non-OSX) code this would slow things
down by making
text rendering go via ductus rendering.
If this really is a 'fontsHint' map, it seems it
The fix looks fine to me. It will be good if an SQE team will port this
test to the jdk ws.
On 27.03.15 17:50, Andrew Brygin wrote:
There is a minor update in the fix: it does not worth to blend
black-on-white
and white-on-black glyphs for the case of AA glyphs, because it makes
no
There is a minor update in the fix: it does not worth to blend
black-on-white
and white-on-black glyphs for the case of AA glyphs, because it makes no
difference.
CGGlyphImages.m, lines 294 - 325, 755 - 763, and 787 - 794:
http://cr.openjdk.java.net/~bae/8023794/9/webrev.08
I have also
Hello Phil,
could you please take a look to updated version of the fix?
http://cr.openjdk.java.net/~bae/8023794/9/webrev.06/
* CGGlyphImages.m
The main part of the recent changes is related to generation of LCD
glyph images.
With previous version of the fix we produced lcd glyphs which
Hi Andrew,
That's a good find re: pow(). In the comment at lines 277-283 I
mentioned that there was only a scalar variant of pow(). I wonder if
that was a limitation in some early version of GLSL I was using or
perhaps some driver bug/restriction. According to all the docs I can
find the
Hello Phil,
at the moment, I failed to get acceptable results for rendering to
translucent destination.
I am playing with an idea to fall back to grayscale AA on non-opaque
pixels (or pixels with
opacity less than a certain threshold) directly in the lcd shader program.
For now, there is
Hi Andrew,
I have added an OpenGL view in the project just to illustrate that OpenGL
provides exactly the same results.
I also wrote a simple test the results are below
http://i.imgur.com/cEt6HYo.png http://i.imgur.com/cEt6HYo.png
The letters are written with the same font and the same size
Hi Andrew,
I have noticed an issue with quartz (at list with our way to use it).
This is a simple project that allows to illustrate the issue with a pure Quartz
and Cocoa.
https://github.com/denis-fokin/OffscreenVsQuartzFontRendering
Hello,
please take a look to updated version of the fix:
http://cr.openjdk.java.net/~bae/8023794/9/webrev.03/
TODOs were removed:
* CGLSurfaceData.java
the condition for lcd rendering is inherited from OGL surface
data, but
here we have to remove the check for the transparency,
On 10/24/2014 10:56 AM, Andrew Brygin wrote:
Hello,
please take a look to updated version of the fix:
http://cr.openjdk.java.net/~bae/8023794/9/webrev.03/
TODOs were removed:
* CGLSurfaceData.java
the condition for lcd rendering is inherited from OGL surface
data, but
here we
Hi, Phil.
I guess that on osx defaults were changed to something more modern long time
ago. Including all types of rendering. In jdk6 it was done in the graphics
itself, but during macport the decision not to change SG2D was made, but use
DesktopProperty instead.
It demanded changes in Aqua
Hello Phil,
please see my comments inline.
On 10/13/2014 12:05 AM, Phil Race wrote:
373 fontHints.put(RenderingHints.KEY_ANTIALIASING,
RenderingHints.VALUE_ANTIALIAS_ON);
374 fontHints.put(RenderingHints.KEY_TEXT_ANTIALIASING,
RenderingHints.VALUE_TEXT_ANTIALIAS_LCD_HBGR);
On 10/13/2014 05:41 AM, Andrew Brygin wrote:
Hello Phil,
please see my comments inline.
On 10/13/2014 12:05 AM, Phil Race wrote:
373 fontHints.put(RenderingHints.KEY_ANTIALIASING,
RenderingHints.VALUE_ANTIALIAS_ON);
374 fontHints.put(RenderingHints.KEY_TEXT_ANTIALIASING,
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
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
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.r...@oracle.com wrote:
I don't have my head around all these changes but a lot of it seems to
imply we
Hello Phil,
changes in SunGraphics2D and SurfaceData were made in order to
implement an approach 'LCD instead of greyscale AA if possible'.
Without this part of change, we get results according to the hints:
greyscale for TEXT_ANTIALIAS_ON, and subpixels for lcd hints:
On 10/10/14 11:05 AM, Andrew Brygin wrote:
Hello Phil,
changes in SunGraphics2D and SurfaceData were made in order to
implement an approach 'LCD instead of greyscale AA if possible'.
Without this part of change, we get results according to the hints:
greyscale for TEXT_ANTIALIAS_ON, and
Hello Phil,
please see my comments inline.
On 10/11/2014 12:49 AM, Phil Race wrote:
On 10/10/14 11:05 AM, Andrew Brygin wrote:
Hello Phil,
changes in SunGraphics2D and SurfaceData were made in order to
implement an approach 'LCD instead of greyscale AA if possible'.
Without this part of
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
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
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
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
29 matches
Mail list logo
