swingmark also shows double improvement on the retina.
On 25.06.15 13:40, Andrew Brygin wrote:
Hello Sergey,
24/06/15 22:45, Sergey Bylokhov wrote:
Hi, Andrew.
Thanks for this report. As far as I understand it in case of retina
the lcd text is drawing faster after the fix than aa before the f
I think that is a reasonable compromise. Miminis 8ux risk but let's get
some exposure in 9 ..
So approved.
Still, very interesting what Andrew notes about D3D being so much faster ..
seems like a subject for further study at some point.
-phil.
On 7/8/15 9:02 AM, Sergey Bylokhov wrote:
HI, An
HI, Andrew.
The fix looks fine, but in my opinion we can add this ifdef to jdk8 fix
to skip possible regression, but in jdk9 it is better to avoid this
ifdef for two reasons:
- This will increase a coverage of a new code not only on osx but also
on other platforms and drivers.
- It should be
Roughly speaking, the rendering of lcd text with d3d pipeline is 10-20 times
faster that with ogl:
http://cr.openjdk.java.net/~bae/8087201/9/perf/windows/ogl-d3d-hg5700.txt
http://cr.openjdk.java.net/~bae/8087201/9/perf/windows/ogl-d3d-nvs5400.txt
On windows, the suggested fix gives mixed results
Ok, here's a comparison; jdk9 b70 on the left, apple's jdk 1.6 on the right;
https://dl.dropboxusercontent.com/u/6299520/Screen%20Shot%202015-06-28%20at%2012.51.45%20pm.png
The non-subpixel AA font is noticeable thinner for jdk9. This has been
an issue brought up at various forums about jdk7/8's
On 06/25/2015 03:33 AM, Andrew Brygin wrote:
Given that it is a unified driver it sounds like we may be want
to disable this code path when on windows at least for NV but I guess we
may also want to validate that on some other cards - from Nvidia - to
see if it is a driver or h/w limitation.
Pr
Hello Sergey,
24/06/15 22:45, Sergey Bylokhov wrote:
Hi, Andrew.
Thanks for this report. As far as I understand it in case of retina
the lcd text is drawing faster after the fix than aa before the fix,
which means that we will not get a new regressions. So the fix looks fine.
But on non reti
24/06/15 21:40, Phil Race wrote:
On 6/24/15 8:18 AM, Andrew Brygin wrote:
Hello Phil,
please see my comments inline.
23/06/15 21:29, Phil Race wrote:
Hi Andrew,
Overall the fix looks good. A few questions.
1. Regarding translucent surfaces, do you know when Swing
has a translucent backbuf
Hi, Andrew.
Thanks for this report. As far as I understand it in case of retina the
lcd text is drawing faster after the fix than aa before the fix, which
means that we will not get a new regressions. So the fix looks fine.
But on non retina our results still not so good, lcd text is slow:
48
On 6/24/15 8:18 AM, Andrew Brygin wrote:
Hello Phil,
please see my comments inline.
23/06/15 21:29, Phil Race wrote:
Hi Andrew,
Overall the fix looks good. A few questions.
1. Regarding translucent surfaces, do you know when Swing
has a translucent backbuffer and when it does not ?
It has b
Hello Phil,
please see my comments inline.
23/06/15 21:29, Phil Race wrote:
Hi Andrew,
Overall the fix looks good. A few questions.
1. Regarding translucent surfaces, do you know when Swing
has a translucent backbuffer and when it does not ?
It has been noted that we now have LCD text in som
Hi Andrew,
Overall the fix looks good. A few questions.
1. Regarding translucent surfaces, do you know when Swing
has a translucent backbuffer and when it does not ?
It has been noted that we now have LCD text in some cases
in SS2 but apparently still not in NB ..
2. Where are we likely to find
Hello Torgeir,
thanks a lot for trying the fix with netbeans. According to the
benchmarks,
the fix should provide some improvement on system with modern Intel
graphics
boards.
Unfortunately, the effect of the fix highly depends on graphics hardware
capabilities: on some system the price
Hello Sergey,
the only part of the fix affects the performance of AA case: the cache
cell size.
In a case of retina, 13pt and 20pt glyphs do not fit the 16x16 cache
cells,
so these benchmarks show better performance:
13pt: 40-80 times faster
20pt: 7-13 times faster
6pt shows the same re
Hi, Andrew.
Can you additionally provide the bench data about aa(before/after the
fix) vs new lcd lcd?
Probably it well be more obvious if the code in OGLTextRenderer
1007 if (OGLC_IS_CAP_PRESENT(oglc, CAPS_EXT_TEXBARRIER) &&
1008 dstOps->textureTarget == GL_TEXTURE_2D)
Will be mov
This patch dramatically speeds up subpixel font rendering on OSX in
netbeans! It even makes netbeans usable on intel integrated graphics
on retina screens! Excellent work!
It also makes netbeans scrolling butter smooth when not using subpixel
rendering.
I saw one glitch when trying it out with in
Bug: https://bugs.openjdk.java.net/browse/JDK-8087201
Webrev: http://cr.openjdk.java.net/~bae/8087201/9/webrev.00/
Thanks,
Andrew
18/06/15 17:39, Andrew Brygin пишет:
Hello,
could you please review a fix for 8087201?
The root of the problem is that we have to supply a content of
destinat
Hello,
could you please review a fix for 8087201?
The root of the problem is that we have to supply a content of
destination surface to lcd shader to compose the lcd glyph correctly.
In order to do this, we have to copy a sub-image from destination
buffer to an intermediate texture using gl
18 matches
Mail list logo