Re: [OpenJDK 2D-Dev] Provide a way to make MultiResolutionImage screen compatible

)... ...jim On 3/27/15 3:48 AM, Hendrik Schreiber wrote: On Mar 26, 2015, at 22:52, Jim Graham james.gra...@oracle.com wrote: On 3/26/15 9:21 AM, Hendrik Schreiber wrote: Nevertheless, I wouldn't mind some feedback regarding converting ToolKitImages easily to something that can

Re: [OpenJDK 2D-Dev] Provide a way to make MultiResolutionImage screen compatible

On 3/27/15 3:48 AM, Hendrik Schreiber wrote: If my understanding of the current drawing pipeline is correct, RGBA without premultiplication is slow as premultiplication is done on-the-fly when drawing—at least for OS X and OpenGL, as pointed out in

Re: [OpenJDK 2D-Dev] Review request for 8029339 Custom MultiResolution image support on HiDPI displays

- the test for the BaseMultiResolutionImage is added Thanks, Alexandr. On 2/14/2015 3:23 AM, Jim Graham wrote: The second solution looks good. I'd make it standard practice (perhaps even mentioned in the documentation) to return unmodifiable lists from the getVariants() method. The Collections

Re: [OpenJDK 2D-Dev] Provide a way to make MultiResolutionImage screen compatible

On 3/26/15 9:21 AM, Hendrik Schreiber wrote: Nevertheless, I wouldn't mind some feedback regarding converting ToolKitImages easily to something that can be drawn faster (TYPE_INT_ARGB_PRE). Don't we all want that? Or asked the other way around: Why isn't TYPE_INT_ARGB_PRE the default? To be

Re: [OpenJDK 2D-Dev] Provide a way to make MultiResolutionImage screen compatible

Thanks Sergey, Have you been following the rest of this thread? Any thoughts on how much the lack of PRE pixel format in the PNG loader might be hurting us? ...jim On 3/27/15 5:31 PM, Sergey Bylokhov wrote: 28.03.15 0:50, Jim Graham wrote: On 3/27/15 3:48 AM

Re: [OpenJDK 2D-Dev] RFR: 8075942: ArrayIndexOutOfBoundsException in sun.java2d.pisces.Dasher.goTo

The fix looks good. +1 ...jim On 4/1/15 3:55 PM, Phil Race wrote: https://bugs.openjdk.java.net/browse/JDK-8075942 http://cr.openjdk.java.net/~prr/8075942/ It appears that the amount to grow the array is not taking into account that before the System.arraycopy we first store

Re: [OpenJDK 2D-Dev] [OpenJDK Rasterizer] Path2d needRoom very slow for huge paths

All of your comments are spot on (modulo the confusion over Pisces/Marlin vs Path2D). And you are right that 500 seems pretty lean to me. 800K path segments seems to be a pretty large outlier, though, do we really see paths that large other than via a test case? I think I'm good with the

Re: [OpenJDK 2D-Dev] [OpenJDK Rasterizer] Path2d needRoom very slow for huge paths

your pseudo-code; see expandPointTypes() and expandCoords() - added a new public trimToSize() method to Path2D implemented by both Path2D.Float and Path2D.Double classes Cheers, Laurent 2015-04-08 22:53 GMT+02:00 Jim Graham james.gra...@oracle.com mailto:james.gra...@oracle.com: Hi Laurent

Re: [OpenJDK 2D-Dev] [OpenJDK Rasterizer] Path2d needRoom very slow for huge paths

On 4/20/15 1:37 PM, Jim Graham wrote: In the needRoom() methods, there is one more potential overflow path. If the array grows to just under MAX_INT, then numCoords + newCoords may overflow to a negative number and the array would not be grown because the test in needRoom() would fail to trigger

Re: [OpenJDK 2D-Dev] AWT Dev [9] Review request for 8069361 SunGraphics2D.getDefaultTransform() does not include scale factor

The math looks fine to me. We'll need to coordinate this with changes for Windows HiDPI as well... ...jim On 4/20/15 4:48 AM, Alexander Scherbatiy wrote: Could you review the updated fix: http://cr.openjdk.java.net/~alexsch/8069361/webrev.01/ -

Re: [OpenJDK 2D-Dev] [OpenJDK Rasterizer] Path2d needRoom very slow for huge paths

value of the new overflow protection is not enough to further split this particular change down... ...jim On 4/20/15 1:09 PM, Jim Graham wrote: I've started the CCC process by creating a bug. One quick question - do we want to port these changes back to 8u60? If so

Re: [OpenJDK 2D-Dev] [OpenJDK Rasterizer] Path2d needRoom very slow for huge paths

Actually, one comment on the doc comment formatting. I'd use {@code Path2D} instead of tt/tt formatting. It gives the javadoc front end more control over the presentation... ...jim On 4/20/15 1:37 PM, Jim Graham wrote: Hi Laurent, The new doc comment and method looks good

Re: [OpenJDK 2D-Dev] [OpenJDK Rasterizer] Path2d needRoom very slow for huge paths

Hi Laurent, Rather than post-process the segments, is it easier to just change the way we generate the segments to account for the cap/join? For instance, when we get to capping a segment we have the first moveto in one half of the path which could be moved back by 1/2 lw and the other path

Re: [OpenJDK 2D-Dev] [OpenJDK Rasterizer] Path2d needRoom very slow for huge paths

trimToSize () methods. Le 21 avr. 2015 00:11, Jim Graham james.gra...@oracle.com mailto:james.gra...@oracle.com a écrit : To answer my own question - since we already have a changeset with just the new trim-on-copy stuff that is backwards compatible and since this change only adds the new trim method

Re: [OpenJDK 2D-Dev] [OpenJDK Rasterizer] Path2d needRoom very slow for huge paths

? ...jim On 4/17/15 3:09 AM, Laurent Bourgès wrote: Phil Jim, Do you have any feedback (CCC) on this Path2D patch ? http://cr.openjdk.java.net/~lbourges/path2D/Path2D_needRoom.1/ http://cr.openjdk.java.net/%7Elbourges/path2D/Path2D_needRoom.1/ Laurent Le 10 avr. 2015 20:51, Jim Graham

Re: [OpenJDK 2D-Dev] [OpenJDK Rasterizer] Path2d needRoom very slow for huge paths

For reference: https://bugs.openjdk.java.net/browse/JDK-8078192 ...jim On 4/20/15 1:09 PM, Jim Graham wrote: I've started the CCC process by creating a bug. One quick question - do we want to port these changes back to 8u60? If so, then we would not be able to port

Re: [OpenJDK 2D-Dev] [OpenJDK Rasterizer] Path2d needRoom very slow for huge paths

= 64.536282 ms. *... Le 21 avr. 2015 19:56, Jim Graham james.gra...@oracle.com mailto:james.gra...@oracle.com a écrit : Then it might make sense to make a new bug and target the existing patch at it by just removing the new method signature... Could you create the new bug and update

Re: [OpenJDK 2D-Dev] [OpenJDK Rasterizer] Path2d needRoom very slow for huge paths

Change something something blah blah blah? Phil may know better, but I believe that the original acronym that gave it its letters wasn't very accurate so they kept the CCC name and backed off from considering it to be an acronym, providing some back-filled words on occasion to those who ask.

Re: [OpenJDK 2D-Dev] [OpenJDK Rasterizer] Path2d needRoom very slow for huge paths

Hi Laurent, Yes, I'm working on getting it pushed to 9-dev and then getting backport approval to 8u60, but I've been foiled by not having updated my JDK build environment for a few months and am almost there. Meanwhile we have submitted the trim() method for CCC approval and hopefully that

Re: [OpenJDK 2D-Dev] [OpenJDK Rasterizer] Path2d needRoom very slow for huge paths

Hi Andrea, On 4/3/15 7:01 AM, Andrea Aime wrote: PS: GeoServer will clip and simplify the geometry before throwing it at java2d, exactly because we know java2d is not so good at handling this kind of complexity Do you have a fast and efficient polygon clipper in

Re: [OpenJDK 2D-Dev] [OpenJDK Rasterizer] Path2d needRoom very slow for huge paths

On 4/4/15 3:15 AM, Laurent Bourgès wrote: I may look at this implementation to get some idea or maybe I should just optimize openjdk's Area class that has also a clipping implementation but is known too be very slow as the shape complexity increases ! The Area class is mostly a red herring.

Re: [OpenJDK 2D-Dev] Review request for 8029339 Custom MultiResolution image support on HiDPI displays

/15 6:46 AM, Alexander Scherbatiy wrote: On 3/27/2015 12:48 AM, Jim Graham wrote: Hi Alexander, http://cr.openjdk.java.net/~alexsch/8029339/webrev.07/ I have updated the fix according to the comments except RenderingHints. RenderingHints are supposed to be set on Graphics2D

Re: [OpenJDK 2D-Dev] [OpenJDK Rasterizer] Path2d needRoom very slow for huge paths

The patch as it is will make things much better, but it may be worth doing it right as long as we are revisiting this algorithm and write it to deal better with the OOME/integer overflow cases. I looked at the ArrayList code and found a bit of voodoo there in the overflow code which troubled

Re: [OpenJDK 2D-Dev] [OpenJDK Rasterizer] Path2d needRoom very slow for huge paths

, Jim Graham james.gra...@oracle.com mailto:james.gra...@oracle.com wrote: We use this one for fast rectangular clipping: https://github.com/geotools/__geotools/blob/master/modules/__library/main/src/main/java/__org/geotools/geometry/jts/__GeometryClipper.java https

Re: [OpenJDK 2D-Dev] [OpenJDK Rasterizer] Path2d needRoom very slow for huge paths

to implement test for a general usage or in particular for pisces / marlin renderers. For 2 years, it remains in my TODO list ... as many applications already have their own (custom) solution. Please read my comments below: Le 7 avr. 2015 00:38, Jim Graham james.gra...@oracle.com mailto:james.gra

Re: [OpenJDK 2D-Dev] [OpenJDK Rasterizer] Path2d needRoom very slow for huge paths

; } } newsize = newsizemin + (newsize - newsizemin) / 2; } ...jim On 4/8/15 9:34 AM, Laurent Bourgès wrote: Jim, let's go back to concrete code: 2015-04-04 0:25 GMT+02:00 Jim Graham james.gra...@oracle.com mailto:james.gra...@oracle.com: The patch as it is will make things

Re: [OpenJDK 2D-Dev] RFR: 8u backport of 8076419: Path2D copy constructors and clone method propagate size of arrays from source path

+1! ...jim On 5/15/2015 1:00 PM, Phil Race wrote: I have prepared a direct 8u-dev backport of the JDK 9 fix for https://bugs.openjdk.java.net/browse/JDK-8076419 http://cr.openjdk.java.net/~prr/8076419.8u/ Please review. For reference the JDK 9 review was here

Re: [OpenJDK 2D-Dev] RFR: 8u backport of 8078464 : Path2D storage growth algorithms should be less linear

+1... ...jim On 5/20/2015 10:40 AM, Phil Race wrote: I have prepared a direct 8u-dev backport of the JDK 9 fix for https://bugs.openjdk.java.net/browse/JDK-8078464 http://cr.openjdk.java.net/~prr/8078464.8u/ Please review. For reference the JDK 9 review was here :

Re: [OpenJDK 2D-Dev] Review Request for bug (JDK-8080287): The image of BufferedImage.TYPE_INT_ARGB and BufferedImage.TYPE_INT_ARGB_PRE is blank

following your comments. Please find the modified webrev: http://cr.openjdk.java.net/~psadhukhan/8080287/webrev.02/ Could you please review this? Regards Prasanta On 6/23/2015 2:03 AM, Jim Graham wrote: In reading through this I notice that at line 349 the filter code can permanently change

Re: [OpenJDK 2D-Dev] [9] Review Request: 7188942 Remove support of pbuffers in OGL Java2d pipeline

Hi Sergey, CGLGC.java: In createCompatVM() I dislike separated tests for here is early rejection of the list of things that I can handle followed by a list of tests for things it can handle. For one thing we have to test the type more than once. But mainly it just seems like the two tests

Re: [OpenJDK 2D-Dev] [9] Review Request: 8080847 Copying of overlapping memory should be improved in java2d

the data ordering issue we should do it for all blits... ...jim On 5/28/2015 12:58 AM, Andrew Haley wrote: On 28/05/15 01:06, Jim Graham wrote: Where do you see evidence that it can crash? It's what the language specification says. Undefined behaviour is unconstrained: it can do

Re: [OpenJDK 2D-Dev] [9] Review Request: 8080847 Copying of overlapping memory should be improved in java2d

affects part of one implementation... ...jim On 5/27/2015 3:36 AM, Sergey Bylokhov wrote: On 26.05.15 21:27, Jim Graham wrote: Undefined doesn't mean may crash in this case, it means that the contents of memory may not match what you would expect if the regions overlap

Re: [OpenJDK 2D-Dev] [9] Review Request: 8080847 Copying of overlapping memory should be improved in java2d

Where do you see evidence that it can crash? ...jim On 5/27/2015 3:54 AM, Andrew Haley wrote: On 05/27/2015 11:36 AM, Sergey Bylokhov wrote: On 26.05.15 21:27, Jim Graham wrote: Undefined doesn't mean may crash in this case, it means that the contents of memory may not match

Re: [OpenJDK 2D-Dev] [9] Review request for 8076545 Text size is twice bigger under Windows LF on Win 8.1 with HiDPI display

I'll let someone familiar with how the AWT/Swing use all of those metrics respond on whether you've scaled all the right ones, but I wanted to make a minor comment about how the scaling is done. If you inverted it so that scale was 96f/dpi then you could use multiplication everywhere instead

Re: [OpenJDK 2D-Dev] [9] Review Request: 7188942 Remove support of pbuffers in OGL Java2d pipeline

On 6/29/2015 10:35 AM, Sergey Bylokhov wrote: Hi, Jim. Thanks for review! Thew new version of the fix: http://cr.openjdk.java.net/~serb/7188942/webrev.02 Comments about pbuffer were changed. CGLGC.java: In createCompatVM() I dislike separated tests for here is early rejection of the list of

Re: [OpenJDK 2D-Dev] [9] Review Request: 7188942 Remove support of pbuffers in OGL Java2d pipeline

One last thing. The old test in the SurfaceManagers used to only require FB_OBJECT for translucent types, the new test requires FB_OBJECT for all types. Is that intentional? ...jim On 7/2/15 1:04 PM, Sergey Bylokhov wrote: On 18.06.15 9:30, Jim Graham wrote

Re: [OpenJDK 2D-Dev] [9] Review Request: 7188942 Remove support of pbuffers in OGL Java2d pipeline

not accelerated BITMASK - not accelerated TRANSLUCENT - use FB if available, otherwise not accelerated If that is the new proper support matrix then the changes look good... ...jim On 7/2/15 3:13 PM, Sergey Bylokhov wrote: On 03.07.15 0:55, Jim Graham wrote: One last thing

Re: [OpenJDK 2D-Dev] [9] Review Request: 8080847 Copying of overlapping memory should be improved in java2d

I don't recall if we ever promised that this case would work without aliasing issues. I know that we went out of our way in the copyArea method to prevent the aliasing issue, doing the blits piecemeal so that they don't interfere with each other. Further, while it may be easy enough to just

Re: [OpenJDK 2D-Dev] [9] Review Request: 8080847 Copying of overlapping memory should be improved in java2d

What crash in memcpy? The issue you pointed to is about dealing with overlapping memory. memcpy does not crash on overlapping memory copies, it just duplicates data oddly in a way that most uses probably don't want. Also, the fix you gave only fixed the problem for the horizontal direction,

Re: [OpenJDK 2D-Dev] [9] Review Request: 8061831 [OGL] java.lang.InternalError: not implemented yet during the blit of VI to VI in xor mode

Please use the same indentation as the surrounding constructions: 62 OGLSurfaceToSwBlit blitSurfaceToIntArgbPre = NN new OGLSurfaceToSwBlit(SurfaceType.IntArgbPre, NNOGLSurfaceData.PF_INT_ARGB_PRE); I'm curious about bufferClip in

Re: [OpenJDK 2D-Dev] [9] Review Request: 8080847 Copying of overlapping memory should be improved in java2d

blits, etc. If you are not prepared to do all of that, then we should drop this attempt to fix a bug that is really code working as (un)expected and focus instead on silencing the warning... ...jim On 5/26/2015 4:34 AM, Sergey Bylokhov wrote: On 26.05.15 13:43, Jim

Re: [OpenJDK 2D-Dev] [9] Review Request: 8080847 Copying of overlapping memory should be improved in java2d

Compilers have also gotten really really good at recognizing memory copy loops and applying the same optimizations automatically depending on the optimization level. I'd really prefer to just leave this code alone and maybe find a way to tag the line to silence the warnings from the tool. If

Re: [OpenJDK 2D-Dev] Review Request for bug (JDK-8080287): The image of BufferedImage.TYPE_INT_ARGB and BufferedImage.TYPE_INT_ARGB_PRE is blank

On 7/31/15 4:24 PM, Jim Graham wrote: I'm guessing that you are trying to change the alpha of all colors to 0xff? Then this is the proper loop: int alpha = 0xff 24; for (int cy=0; cy dst.getHeight(); cy++) { for (int cx=0; cx dst.getWidth(); cx++) { int

Re: [OpenJDK 2D-Dev] Review Request for bug (JDK-8080287): The image of BufferedImage.TYPE_INT_ARGB and BufferedImage.TYPE_INT_ARGB_PRE is blank

not find in the spec if that is what we should do). So, I changed to int[] bands = new int[numSrcColorComp]; Regards Prasanta On 6/25/2015 3:17 AM, Jim Graham wrote: Hi Prasanta, I just realized that this method uses filter(Raster, Raster) to do its work and so some of these changes may affect how

Re: [OpenJDK 2D-Dev] Review request for 8029339 Custom MultiResolution image support on HiDPI displays

custom GraphicsConfiguration and SurfaceData On 7/23/2015 8:25 PM, Jim Graham wrote: Hi Alexandr, On 7/21/15 7:41 AM, Alexander Scherbatiy wrote: Hello Jim, Thank your for the review. Could you review the updated fix there the suggested comments are updated: http

Re: [OpenJDK 2D-Dev] Review Request for bug (JDK-8080287): The image of BufferedImage.TYPE_INT_ARGB and BufferedImage.TYPE_INT_ARGB_PRE is blank

be replacing them with unscaled copies of the original... ...jim On 6/30/15 3:38 PM, Jim Graham wrote: The backup code if ImagingLib does not do the work is to forward the request to the filter(Raster, Raster) method which again tests length and requires

Re: [OpenJDK 2D-Dev] Review Request for bug (JDK-8080287): The image of BufferedImage.TYPE_INT_ARGB and BufferedImage.TYPE_INT_ARGB_PRE is blank

Prasanta On 8/1/2015 4:54 AM, Jim Graham wrote: Hi Prasanta, Check your new code for trailing white space - I found quite a bit of extra spaces at the ends of lines. I just realized that I never really looked closely at the loop that copies alpha. It doesn't appear to do anything. In particular

Re: [OpenJDK 2D-Dev] Review Request for bug (JDK-8080287): The image of BufferedImage.TYPE_INT_ARGB and BufferedImage.TYPE_INT_ARGB_PRE is blank

by examining the pixel values in the result... ...jim On 7/29/15 11:21 AM, prasanta sadhukhan wrote: Hi Jim, Thanks for your comments. My observations inline.. On 7/29/2015 9:22 AM, Jim Graham wrote: Hi Prasant, Can you check what the ImagingLib call at line 401 will do

Re: [OpenJDK 2D-Dev] Review Request for bug (JDK-8080287): The image of BufferedImage.TYPE_INT_ARGB and BufferedImage.TYPE_INT_ARGB_PRE is blank

, is there anything I am missing? Here's the modified webrev: http://cr.openjdk.java.net/~psadhukhan/8080287/webrev.06/ Regards Prasanta On 8/4/2015 1:38 AM, Jim Graham wrote: I agree with this. I think this applies for both test cases (src has alpha and src does not). Also, the println() statements should

Re: [OpenJDK 2D-Dev] Review request for 8029339 Custom MultiResolution image support on HiDPI displays

:36 AM, Jim Graham wrote: AbstractMRI - getGraphics() should include getGraphics() not supported on Multi-Resolution Images as the exception description text. AbstractMRI - the getGraphics() description string contains an embedded '\n' and an embedded '\', are those typos? BaseMRI - class

Re: [OpenJDK 2D-Dev] Review request for 8029339 Custom MultiResolution image support on HiDPI displays

is added Thanks, Alexandr. On 4/7/2015 1:02 PM, Jim Graham wrote: This is an interesting suggestion that would let us keep the implementation of the various hints centralized and simplify the interface to the part of the mechanism that is most tied in to the implementation specifics

Re: [OpenJDK 2D-Dev] [9] Review request for 8073320 Windows HiDPI Graphics support

Note that I still have outstanding comments in my other review email on webrev.01 - the comments below were only about the indicated changes you did for Sergey... ...jim On 10/22/15 5:34 PM, Jim Graham wrote: The changes look fine to me. I'm OK with deferring

Re: [OpenJDK 2D-Dev] [9] Review request for 8073320 Windows HiDPI Graphics support

s are used for configs caching in BIGC - scale factors intialized from properties are moved to the static block in Win32GD On 10/10/2015 3:14 AM, Jim Graham wrote: Hi Alexandr, Just 2 potential issues I found: SG2D.java - getResolutionVariant() doesn't take a transform so it can't take in

Re: [OpenJDK 2D-Dev] [9] Review request for 8137571 Linux HiDPI Graphics support

On 10/22/15 7:03 AM, Alexander Scherbatiy wrote: On 10/10/2015 3:16 AM, Jim Graham wrote: Hi Alexandr, Is it possible to create a diff of this without the fixes from 8073320 mixed in? This bug is really just focused on the Linux support of that other framework, right? Here is the webrev which

Re: [OpenJDK 2D-Dev] [9] Review request for 8073320 Windows HiDPI Graphics support

are made final in BufImgSurfaceData - two arrays are used for configs caching in BIGC - scale factors intialized from properties are moved to the static block in Win32GD On 10/10/2015 3:14 AM, Jim Graham wrote: Hi Alexandr, Just 2 potential issues I found: SG2D.java - getResolutionV

Re: [OpenJDK 2D-Dev] [9] Review request for 8073320 Windows HiDPI Graphics support

s are used for configs caching in BIGC - scale factors intialized from properties are moved to the static block in Win32GD On 10/10/2015 3:14 AM, Jim Graham wrote: Hi Alexandr, Just 2 potential issues I found: SG2D.java - getResolutionVariant() doesn't take a transform so it can't take in

Re: [OpenJDK 2D-Dev] [9] Review request for 8137571 Linux HiDPI Graphics support

On 10/22/2015 5:07 PM, Jim Graham wrote: I'm guessing that 6356322 has been fixed? In XComponentPeer we shouldn't be scaling a region, we should have created the region in a scaled coordinate system... In XDragSourceContextPeer, should the scaledown try to do rounding? Also, XMouseInfoPeer

Re: [OpenJDK 2D-Dev] [9] Review request for 8073320 Windows HiDPI Graphics support

Hi Hendrik, The comment I was making was on the format of the command line arguments we use to override DPI scaling and has nothing to do with image loading. You are correct that we don't really deal with the EXIF tags currently, but I am not sure that they represent something we should be

Re: [OpenJDK 2D-Dev] [9] Review request for 8137571 Linux HiDPI Graphics support

On 11/10/15 5:07 AM, Alexander Scherbatiy wrote: On 11/6/15 2:00 AM, Alexander Scherbatiy wrote: Could you review the updated fix: http://cr.openjdk.java.net/~alexsch/8137571/webrev.03/ - pixbuf is freed in the awt_Robot.c - screenWidth/Height is rescaled in the

Re: [OpenJDK 2D-Dev] [9] Review request for 8073320 Windows HiDPI Graphics support

intialized from properties are moved to the static block in Win32GD On 10/10/2015 3:14 AM, Jim Graham wrote: Hi Alexandr, Just 2 potential issues I found: SG2D.java - getResolutionVariant() doesn't take a transform so it can't take into account the scaling in the transform handed to drawImage(img

Re: [OpenJDK 2D-Dev] [9] Review request for 8073320 Windows HiDPI Graphics support

Hi Alexandr, On 11/11/15 3:08 AM, Alexander Scherbatiy wrote: On 11/10/2015 10:41 PM, Jim Graham wrote: In drawHiDPIImage, in the VolatileImage case you ignore the transform, but I suppose that is OK because you pass it through to the scaleImage() case. However if it came in with a transform

Re: [OpenJDK 2D-Dev] Review Request: Small tweak in the DrawImage.java

Hi Sergey, On 11/12/2015 1:54 PM, Sergey Bylokhov wrote: On 12.11.15 23:46, Jim Graham wrote: Hi Sergey, I think the added logic is fine, but I would hesitate removing all of those lines with comments simply because: - In terms of code generated it is no more efficient to do the tests up

Re: [OpenJDK 2D-Dev] Review Request: Small tweak in the DrawImage.java

Hi Sergey, I think the added logic is fine, but I would hesitate removing all of those lines with comments simply because: - In terms of code generated it is no more efficient to do the tests up above or down below. - Your question below does not indicate enough investigation to remove

Re: [OpenJDK 2D-Dev] Review Request: Small tweak in the DrawImage.java

Looks good! ...jim On 11/13/2015 12:12 PM, Sergey Bylokhov wrote: On 13.11.15 1:50, Jim Graham wrote: I can add a comment that this code is for performance, what do you think? I'd like to see that, was there an updated diff? In either case, I don't think we should

Re: [OpenJDK 2D-Dev] [9] Review request for 8076545 Text size is twice bigger under Windows L on Win 8.1 with HiDPI display

/webrev.02 - round is used instead of ceil - inverted scales are used Thanks, Alexandr. On 10/30/2015 10:40 PM, Jim Graham wrote: In this case round may be better. ceil() is more for cases where you needed "at least X amount of room", but I don't think a font size is an "

Re: [OpenJDK 2D-Dev] [9] Review request for 8073320 Windows HiDPI Graphics support

where MRI can contains VolatileImage Thanks, Alexandr. On 11/12/2015 2:33 AM, Jim Graham wrote: Hi Alexandr, On 11/11/15 3:08 AM, Alexander Scherbatiy wrote: On 11/10/2015 10:41 PM, Jim Graham wrote: In drawHiDPIImage, in the VolatileImage case you ignore the transform, but I suppose

Re: [OpenJDK 2D-Dev] [9] Review request for 8076545 Text size is twice bigger under Windows L on Win 8.1 with HiDPI display

ut) in 8.1... ...jim On 11/16/15 6:07 AM, Alexander Scherbatiy wrote: Hello, Could you review the updated fix: http://cr.openjdk.java.net/~alexsch/8076545/webrev.02 - round is used instead of ceil - inverted scales are used Thanks, Alexandr. On 10/30/2015 10:40 PM,

Re: [OpenJDK 2D-Dev] [9] Review request for 8073320 Windows HiDPI Graphics support

ing any copy at all unless the scale was 1. It was not throwing that error for the test case in the bug report, though... ...jim On 11/16/2015 3:05 PM, Jim Graham wrote: I ran SwingSet2 and JDK-8069348 immediately jumped out as being broken to the point where SwingS

Re: [OpenJDK 2D-Dev] [9] Review request for 8073320 Windows HiDPI Graphics support

On 11/11/15 3:08 AM, Alexander Scherbatiy wrote: For some reasons the link to the latest webrev and comments are not mentioned in this email. I found it. I view this mailing list in threaded form and that email on 11/5 did not associate itself with the existing email thread...

Re: [OpenJDK 2D-Dev] [9] Review request for 8076545 Text size is twice bigger under Windows L on Win 8.1 with HiDPI display

In this case round may be better. ceil() is more for cases where you needed "at least X amount of room", but I don't think a font size is an "at least this much" kind of case. Also, I've been toying with the idea that use of ceil() and floor() in any DPI-adjustment equations should really be

Re: [OpenJDK 2D-Dev] [9] RFR JDK-8072682: getBounds call on graphics.getDeviceConfiguration() returning cached information

2:02 AM, Jim Graham wrote: +1 for the fix and removing the fields. ...jim On 10/9/15 8:37 AM, Sergey Bylokhov wrote: Hi, Prasanta. It seems that width fields are not used after the fix and can be removed. On 08.10.15 11:12, prasanta sadhukhan wrote: Hi All, Please review a fix

Re: [OpenJDK 2D-Dev] Question: Area changes order of points

Hi Steve, Area simplifies the shape into a normalized version that defines the same interior area. It does not care what the original ordering of the points was as it internalizes the shape, all it cares about is which areas are geometrically inside vs. outside and it creates a path

Re: [OpenJDK 2D-Dev] [9] Review request for 8137571 Linux HiDPI Graphics support

Hi Alexandr, Is it possible to create a diff of this without the fixes from 8073320 mixed in? This bug is really just focused on the Linux support of that other framework, right? ...jim On 10/5/15 7:01 AM, Alexander Scherbatiy wrote: Hello, Could you review the

Re: [OpenJDK 2D-Dev] [9] RFR JDK-8072682: getBounds call on graphics.getDeviceConfiguration() returning cached information

+1 for the fix and removing the fields. ...jim On 10/9/15 8:37 AM, Sergey Bylokhov wrote: Hi, Prasanta. It seems that width fields are not used after the fix and can be removed. On 08.10.15 11:12, prasanta sadhukhan wrote: Hi All, Please review a fix for jdk9 Bug:

Re: [OpenJDK 2D-Dev] Review request for 8029339 Custom MultiResolution image support on HiDPI displays

Is MRI intended to be implemented only by classes that extend java.awt.Image? I think that's the only place we look for it. If so, then we should state that. Perhaps: - This interface is designed to be an optional additional API supported by some implementations of {java.awt.Image}

Re: [OpenJDK 2D-Dev] RFR: [9] JDK-8040689 Fonts antialiasing artifacts appear when using translucent composited images

Hi Prasanta, I want Phil to evaluate this as well since we are now using a different and potentially slower or less capable pipeline in what may be a common case. Have you measured the performance difference before and after this change? With respect to the code, please maintain the "{" on

Re: [OpenJDK 2D-Dev] AWT Dev Review request for 8029339 Custom MultiResolution image support on HiDPI displays

Scherbatiy wrote: Could you review the updated fix: http://cr.openjdk.java.net/~alexsch/8029339/webrev.13 - The javadoc for MultiResolutionImage interface is updated. On 8/26/2015 1:45 AM, Phil Race wrote: On 08/25/2015 02:26 PM, Jim Graham wrote: Is MRI intended to be implemented only

Re: [OpenJDK 2D-Dev] RFR: 8144526: Remove Marlin logging use of deleted internal API

+1 - and file a follow-on bug to restore it with the new API later... ...jim On 12/2/15 10:38 AM, Phil Race wrote: https://bugs.openjdk.java.net/browse/JDK-8144526 MarlinUtils uses internal API that has been deleted as part of the new StackWalker. I need to integrate

Re: [OpenJDK 2D-Dev] [9] RFR: JDK-8140530, , Creating a VolatileImage with size 0, 0 results in no longer working g2d.drawStri

Hi Prasanta, (On a practical note, in the HTML version of your message, the text said "webrev.01", but the link in the href pointed to "webrev.00" so I sat there wondering why the changes you noted weren't there until I realized that I was still looking at webrev.00 and had to manually enter

Re: [OpenJDK 2D-Dev] RFR: 8076529: Marlin antialiasing renderer integration

Here is a bugid for this issue: https://bugs.openjdk.java.net/browse/JDK-816 Please start a new review thread referencing that bug id (see the various "RFR" threads in the 2d-dev archives for a template). We should discuss all new work on Marlin under separate threads with bugids...

Re: [OpenJDK 2D-Dev] RFR: 8076529: Marlin antialiasing renderer integration

I don't know of any way of providing that requirement in a test case - Phil? Sergey? If the machine doesn't have that much memory, I'm guessing that most of the OS's have some system of virtual memory that will get used, but it will add to the time the test takes due to paging. Is 2G/3G

Re: [OpenJDK 2D-Dev] [9] RFR: JDK-8140530, , Creating a VolatileImage with size 0, 0 results in no longer working g2d.drawStri

+1 ...jim On 12/3/15 10:17 PM, prasanta sadhukhan wrote: ok. Thanks Jim . Please review the modified webrev http://cr.openjdk.java.net/~psadhukhan/8140530/webrev.02/ Regards Prasanta On 12/4/2015 6:45 AM, Jim Graham wrote: I think it makes sense to catch it at a higher level

Re: [OpenJDK 2D-Dev] RFR 8144446: Automate the Marlin crash test

Looks good to me. Are jigsaw issues good Phil? ...jim On 12/3/15 12:58 PM, Laurent Bourgès wrote: Phil, If you were to run this on a jigsaw EA build it would fail due to accessing sun.java2d.pipe.RenderingEngine. I know this is "pre-existing" but

Re: [OpenJDK 2D-Dev] [9] RFR: JDK-8140530, , Creating a VolatileImage with size 0, 0 results in no longer working g2d.drawStri

bug on the X11 pipeline. We'll find out right away that we need an alternate solution for X11... ...jim On 04.12.15 12:39, Jim Graham wrote: +1 ...jim On 12/3/15 10:17 PM, prasanta sadhukhan wrote: ok. Thanks Jim . Please review the modified webrev http

Re: [OpenJDK 2D-Dev] CFV: New 2D Group Member: Sergey Bylokhov

Vote: yes ...jim

Re: [OpenJDK 2D-Dev] RFR 8144446: Automate the Marlin crash test

~ 120s (x4 typical time). Laurent Le 8 déc. 2015 03:17, "Jim Graham" <james.gra...@oracle.com <mailto:james.gra...@oracle.com>> a écrit : Prior to pushing it I ran the test and it takes over 30 seconds to complete. Is this something we want to make a manual test?

Re: [OpenJDK 2D-Dev] RFR 8144828: Marlin renderer causes unaligned write accesses

With the submission of JDK-8144938 as a follow-on bug, this fix looks fine now... ...jim On 12/7/15 5:13 PM, Jim Graham wrote: Do we make sure that the subpixel coords don't overflow an integer somewhere? ...jim On 12/7/15 1:52 PM, Laurent Bourgès wrote

Re: [OpenJDK 2D-Dev] RFR 8144654: Improve Marlin logging

Perhaps "isLoggingEnabled()"? This turns a bunch of constants from having compile-time values to run-time values so the javac compiler will no longer be able to compile the code out of the classfiles. On the other hand, the fields are still final so the Hotspot compiler should still be able

Re: [OpenJDK 2D-Dev] RFR 8144630: Use PrivilegedAction to create Thread in Marlin RendererStats

Looks good... ...jim On 12/3/15 1:37 PM, Laurent Bourgès wrote: https://bugs.openjdk.java.net/browse/JDK-8144630 Please review this simple webrev that fixes the Thread creation in RendererStats: http://cr.openjdk.java.net/~lbourges/marlin/marlin-8144630.0/ Regards,

Re: [OpenJDK 2D-Dev] RFR 8144445: Maximum size checking in Marlin ArrayCache utility methods is not optimal

ArrayCache.java line 214 - was that supposed to be size or needSize on that line? Stroker.java line 1276 - "numCurves >= curveTypes.length" would also work...? In the test cases that expect an exception, if no exception is thrown then you pass the test. Is that right?

Re: [OpenJDK 2D-Dev] RFR 8144718: Pisces / Marlin Strokers may generate invalid curves with huge coordinates and round joins

I'd make the test >= 0.5 since 0.5 generates a flat curve as well. And it couldn't hurt to mention that we are worried about round off error since someone coming along might wonder why we're worried that a cos() is > 1: // check round off errors producing cos(ext) > 1 and a NaN below //

Re: [OpenJDK 2D-Dev] [9] RFR: JDK-8140530, , Creating a VolatileImage with size 0, 0 results in no longer working g2d.drawStri

of this fix that you already have and to add an explicit check and throw IAE to SunVolatileImage for completeness and guaranteed consistency... ...jim On 12/2/15 11:18 PM, prasanta sadhukhan wrote: Hi Jim, On 12/3/2015 12:38 AM, Jim Graham wrote: Hi Prasanta

Re: [OpenJDK 2D-Dev] RFR 8144446: Automate the Marlin crash test

Prior to pushing it I ran the test and it takes over 30 seconds to complete. Is this something we want to make a manual test? ...jim On 12/4/15 2:57 PM, Phil Race wrote: Looks good. -phil. On 12/04/2015 02:55 PM, Jim Graham wrote: Looks good to me. Are jigsaw

Re: [OpenJDK 2D-Dev] RFR 8144828: Marlin renderer causes unaligned write accesses

pos and needSize are longs. px_bbox1 and px0 are positive ints with px_bbox1 known to be greater than px0 so the subtraction should not be able to overflow an int. But, now that we are adding 3, is it possible for that calculation to overflow? Would it be better to protect against that by

Re: [OpenJDK 2D-Dev] RFR 8144654: Improve Marlin logging

http://cr.openjdk.java.net/~lbourges/marlin/marlin-8144654.1/ Changes: - isEnableLogs() renamed to isLoggingEnabled(); I used the convention "is" even if it is not english ! - restored doMonitors to false (as it reduces the bytecode count for inlining) Comments below: 2015-12-05 0:05

Re: [OpenJDK 2D-Dev] RFR 8144828: Marlin renderer causes unaligned write accesses

b row = px_bbox1 - px0 ! That's only possible if you allocate an image with a single row (MAX_INT) and the shape covers that full range ! Do you really want me to fix that impossible case ? using 3L (and -4L). Laurent Le 7 déc. 2015 22:15, "Jim Graham" <james.gra...@oracle.com <ma

Re: [OpenJDK 2D-Dev] RFR 8144445: Maximum size checking in Marlin ArrayCache utility methods is not optimal

Hi Laurent, On 12/7/15 2:17 AM, Laurent Bourgès wrote: http://cr.openjdk.java.net/~lbourges/marlin/marlin-815.1/ See my comments below: Le 5 déc. 2015 00:13, "Jim Graham" <james.gra...@oracle.com <mailto:james.gra...@oracle.com>> a écrit : Ar

Re: [OpenJDK 2D-Dev] RFR 8144828: Marlin renderer causes unaligned write accesses

On 12/8/15, 3:17 PM, Jim Graham wrote: With the submission of JDK-8144938 as a follow-on bug, this fix looks fine now... ...jim On 12/7/15 5:13 PM, Jim Graham wrote: Do we make sure that the subpixel coords don't overflow an integer somewhere? ...jim On 12/7/15

Re: [OpenJDK 2D-Dev] RFR 8144446: Automate the Marlin crash test

-filled ! I will work on this issue ASAP and propose a fix within the same bug. Maybe we should defer this fix as I agree it can be made faster ~ 12s now vs 52s before on my laptop. Laurent 2015-12-09 22:31 GMT+01:00 Jim Graham <james.gra...@oracle.com <mailto:james.gra...@oracle.com>&

Re: [OpenJDK 2D-Dev] RFR 8144446: Automate the Marlin crash test

Hi Laurent, One clarification - there are levels of automation. On 12/9/15 6:35 AM, Laurent Bourgès wrote: Agreed it is possible but then the bug JDK-816 becomes invalid. Prior to this fix, jtreg wouldn't even see the test since it did

<    1   2   3   4   5   6   7   >