Hi Phil,
Please find the updated webrev
http://cr.openjdk.java.net/~psadhukhan/8138749/webrev.01/
which do away with the change in ServiceUI.
Regards
Prasanta
On 1/21/2016 2:59 AM, Phil Race wrote:
The changes in ServiceUI seem like they can cause the spec. to be
contradicted.
It says
* @p
Hi,
Please review the following fix in JDK9:
Bug : https://bugs.openjdk.java.net/browse/JDK-8022640
Webrev : http://cr.openjdk.java.net/~jdv/8022640/webrev.00/
Issue : ServiceRegistry (used by ImageIO) lack synchronization.
Root cause : Service Provider API's are not synchroni
On 21/01/16 00:57, Phil Race wrote:
It seems like the expectation was that BASE could be drawn by the old
imaging path.
which would be lower overhead.
The BASE rendering hint check was used in the initial fix 8011059 to
fall down to the main image and had the problem with the SurfaceManager
Hi, Alexander.
I curious where we differentiate Windows and OSX behavior for a
default_hint? (dpi_scale vs size-scale). Also it seems that a small
optimizations is possible if the image is subclass of
AbstractMultiResolutionImage, then we can get base image directly via
getBaseImage.
On 21/0
On 19/01/16 14:30, Semyon Sadetsky wrote:
We are getting error because of incorrect fudge factor added to the "to"
line coordinates (for line from - to).
See the updated version of the fix in which test should work on OS X:
http://cr.openjdk.java.net/~ssadetsky/8146042/webrev.02/
Test fails on my
Hi,
With a recent change to layout code in OpenJDK [1], I have started to get new
build warnings in layout code when building with gcc (5.3.1) on linux:
> /home/omajid/devel/jdk8u-jdk8u/jdk/src/share/native/sun/font/layout/IndicRearrangementProcessor.cpp:
> In member function ‘void IndicRearrang
Approved. Please send a request to commit this change to the 8u-dev list.
-phil.
On 01/20/2016 10:20 PM, Jayathirth D V wrote:
Hi,
This is backport of the fix that is already merged into JDK9.
_Please review the fix in JDK8u:_
Bug : https://bugs.openjdk.java.net/browse/JDK-8041501
Webrev :
> public synchronized void finalize() {
Whilst probably harmless, I can't think of a reason to make finalize()
synchronized in this case.
Normally it is called by the VM when the object is unreachable so there
can't
be contention.
If app. code calls it directly then you already synchronized t
I don't think this is a problem in practice as we also have this test ..
> if (currGlyph < 0 || currGlyph >= glyphStorage.getGlyphCount()) {
Arguably the test could be removed but I would prefer to leave it in
and change the code it so it is actually tested.
-fno-strict-overflow is just too comp
BASE essentially just means to draw the 1:1 image. The problem is that
returning null is not the way to achieve that. Returning null means
"MRI doesn't apply here, just use the original image", but in the case
of BASE we have to make sure it isn't an MRI first otherwise the caller
will get an
Hi,
* Phil Race [2016-01-21 14:15]:
> I don't think this is a problem in practice as we also have this test ..
> > if (currGlyph < 0 || currGlyph >= glyphStorage.getGlyphCount()) {
But the compiler won't optimize this one away completely, will it? Both
parts of this check can be true or false. T
On 01/21/2016 01:50 PM, Omair Majid wrote:
Hi,
* Phil Race [2016-01-21 14:15]:
I don't think this is a problem in practice as we also have this test ..
if (currGlyph < 0 || currGlyph >= glyphStorage.getGlyphCount()) {
But the compiler won't optimize this one away completely, will it? Both
That is definitely better .. although I wonder if it would be even better
if you found when there is an 'active' window that you tried to
position the dialog such that it is near the upper-left corner of that
window ?
Please experiment and see how that looks compared to what other apps are
doing
On 19/01/16 19:17, Alexander Stepanov wrote:
Hello Sergey,
please find the updated webrev:
http://cr.openjdk.java.net/~avstepan/8146881/webrev.01/index.html
Looks fine, please update JDK-8147448 that the this test should be
updated after the fix.
Regards,
Alexander
On 1/18/2016 5:12 PM,
Looks good to me.
--Semyon
On 1/19/2016 7:17 PM, Alexander Stepanov wrote:
Hello Sergey,
please find the updated webrev:
http://cr.openjdk.java.net/~avstepan/8146881/webrev.01/index.html
Regards,
Alexander
On 1/18/2016 5:12 PM, Sergey Bylokhov wrote:
On 15/01/16 15:27, Alexander Stepanov wr
Hi Phil,
I checked with NATIVE print dialog and with other app print dialog, they
are positioning the dialog a little ahead of top-left corner (not at
1/3rd of the window as we are doing now)
so I did the same and positioned the dialog in consistent with our
NATIVE print dialog.
Please find t
16 matches
Mail list logo
