Re: [OpenJDK 2D-Dev] Making the OpenGL-Queue-Flusher work concurrently with AWT threads possible? (... the future of the opengl pipeline)

Hi Sergey, It is quite interesting! But it would be good to check what code was > affected by this parallelization. I meant we cannot draw much-much faster > than OGL draw its primitives, so even w/o parallelization if we will call > flush after each fillRect/etc(mimics the in-place rendering on t

Re: [OpenJDK 2D-Dev] Making the OpenGL-Queue-Flusher work concurrently with AWT threads possible? (... the future of the opengl pipeline)

Hi Laurent, Thanks for your interest in tuning the pipelines and all the work you did in this regard with Marlin. > I read again the source code and wanted to add metrics like wait_ratio and make some new heuristics to auto tune the buffer capacity. > I was also tempted to rewrite the buffer over

Re: [OpenJDK 2D-Dev] Making the OpenGL-Queue-Flusher work concurrently with AWT threads possible? (... the future of the opengl pipeline)

Hi Sergey, > The design is a little bit different, the XRender pipeline: > - Many threads which call draw operations and sends them to the XServer > - The XSerever decode the the draw operation and push the commands to the "opengl buffer" > - Some video driver code which decode the ogl buffe

[OpenJDK 2D-Dev] Making the OpenGL-Queue-Flusher work concurrently with AWT threads possible? (... the future of the opengl pipeline)

Hi, With solid OpenGL support on Linux being ubiquitous these days and the XRender pipeline being a bit of a dead-end (works quite well except MaskBlit/MaskFill/BufferedImageOps), I was looking a bit into the state/performance of the OpenGL pipeline. Specifically why it performs sometimes worse co

Re: [OpenJDK 2D-Dev] Fix for 8235904 "Infinite loop when rendering huge lines"

Hi Phil, > Is there a regression test ? > I don't see a noreg- label. Sorry I forgot to mention, the regression test is in the "main" directory of the bugfix: http://cr.openjdk.java.net/~ceisserer/8235904/ Thanks and best regards, Clemens

[OpenJDK 2D-Dev] Fix for 8235904 "Infinite loop when rendering huge lines"

Hi, Please review the fix for bug 8235904 "Infinite loop when rendering huge lines": http://cr.openjdk.java.net/~ceisserer/8235904/webrev.01/ The issue was caused by integer overflow during clipping: While the original native code used int or long depending on the coordinate range, the java-port

Re: [OpenJDK 2D-Dev] RFR: 8198991: Move Java2D demo to the open repository

Hi, > This moves the Java 2D demo from "closed" to "open". > It is now called "J2Ddemo" to avoid any trademark questions. > This has already been reviewed internally and the images here are OK to > keep. This is awesome news :) Java2Demo is such a handy tool to visually check various features pro

Re: [OpenJDK 2D-Dev] Initial implementation for batched AA-mask upload for xrender

Hi Sergey, > Thank you for contribution! If there is a chance to implement it soon(at an > early test stage) then it is possible to push this to jdk11 and enable it by > default to expose all possible issues. If no issues will be found, then we > can release it as-is, otherwise we can disable it b

Re: [OpenJDK 2D-Dev] Initial implementation for batched AA-mask upload for xrender

Hi everybody, I finally got my hands on a 10-year old NVidia GPU (8800GTS) and can confirm Laurent's findings. The proprietary nvidia driver is awesome for the MaskBlit workload, for x11perf -shmput10 it is 32x faster than my kaveri APU solution (despite it has to copy data via PCIe). > Finally,

Re: [OpenJDK 2D-Dev] [11] Upgrade to Marlin renderer 0.9.1

HI, > As previously mentioned, I increased the RenderQueue buffer (see patchs at > the end) to 4M (instead of 32K) and d3d & opengl get boosted. It is great to see the tile-size improvements reach the other backends too :) In case of the buffer size - I wonder is 4M really needed or was it an ar

Re: [OpenJDK 2D-Dev] Initial implementation for batched AA-mask upload for xrender

Hi Laurent, Thanks a lot for taking the time to test the deferred xrender pipeline. Especially since the proprietary nvdia driver is the only one of the accelerated xrender implementations I didnt test / benchmark against. > On my linux laptop (i7 + nvidia quadro), xrender is already faster than

[OpenJDK 2D-Dev] Initial implementation for batched AA-mask upload for xrender

Hi, After achieving huge speedups with Marlin Laurent Bourgès recently proposed increasing the AA tile size of MaskBlit/MaskFill operations. The 128x64 tiles size should help the Xrender pipeline a lot for larger aa shapes. For smaller xrender stays rather slow. To solve this issue am currently w

[OpenJDK 2D-Dev] Proposal: improved AA tile upload for xrender

Re: [OpenJDK 2D-Dev] [10] RFR JDK-8176795: Wrong color drawn when painting translucent colors on volatile images using XRender.

Hi, >>> 1) When we call Graphics2D.setColor() it uses ArgbPre PixelConverter >>> based on SurfaceData(here it is XRenderPixMap ArgbPre surface) and converts >>> the color to pre-multiplied values. Sorry for the dumb question, but what is the most recent 2d-dev repo, which includes this change. I

Re: [OpenJDK 2D-Dev] [10] RFR JDK-8176795: Wrong color drawn when painting translucent colors on volatile images using XRender.

Hi Jay, > 1) When we call Graphics2D.setColor() it uses ArgbPre PixelConverter based on > SurfaceData(here it is XRenderPixMap ArgbPre surface) and converts the color > to pre-multiplied values. Thanks a lot for identifying the issue and working on it. The fix itself looks fine and low-risk. T

Re: [OpenJDK 2D-Dev] Different rounding applied by ProcessPath and ShapeSpanIterator

Hi Jim, > They do operate differently. They aren't meant to be mixed and matched. Thanks a lot for the detailed description of the relationship between SSI and ProcessPath. I did some further digging as to why the xrender pipeline has issues with the test attached to the mentioned bug report - b

Re: [OpenJDK 2D-Dev] Request for Review: JDK-8162591 All existing gradient paint implementations have issues with coordinates/sizes larger than Short.MAX_VALUE (exactly) on any Linux systems

HI Jim, > All of those conditions are optimized equivalents to getting the > determinant. > > invert() is a destructive call, but since getTransform is documented to > return a copy, that is fine - but getDeterminant() will involve less math to > check the condition... Thanks for the clarificatio

Re: [OpenJDK 2D-Dev] Request for Review: JDK-8162591 All existing gradient paint implementations have issues with coordinates/sizes larger than Short.MAX_VALUE (exactly) on any Linux systems

Hi Sergey > I guess you can use "getDeterminant()==0" to determine if this transform has > no inverse? Initially I had the same idea, but looking at the implementation of invert(), I found several different conditions leading to an NoninvertibleTransformException. So I decided to keep the call to

Re: [OpenJDK 2D-Dev] Request for Review: JDK-8162591 All existing gradient paint implementations have issues with coordinates/sizes larger than Short.MAX_VALUE (exactly) on any Linux systems

Hello again, > OK .. should be part of the patch tho' Just noticed the reg tests are also open-source, until now I thought they are integrated into some Oracle-only internal test collection. Cool! Please find the current version of the patch at: http://93.83.133.214/8162591/webrev.03/ It incorpor

Re: [OpenJDK 2D-Dev] Request for Review: JDK-8162591 All existing gradient paint implementations have issues with coordinates/sizes larger than Short.MAX_VALUE (exactly) on any Linux systems

Thanks a lot for the feedback. > The fix seems fine .. is there a possibility to have a regression test? > Perhaps based on the code in the bug ? Please find an automated regression test at: http://93.83.133.214/8162591/HugeGradientTest.java > Should we also check the transform? > I guess we alr

[OpenJDK 2D-Dev] Request for Review: JDK-8162591 All existing gradient paint implementations have issues with coordinates/sizes larger than Short.MAX_VALUE (exactly) on any Linux systems

Hello, The cause of JDK-8162591 is Java2D's gradient implementation allowing for coordinates to be specified using floating point values, whereas XRender is limited to a 16.16 fixed point format - which can therefor easily overflow. This patch checks whether the supplied coordinates can be repres

[OpenJDK 2D-Dev] Different rounding applied by ProcessPath and ShapeSpanIterator

Hi, I recently tried to track down JDK-8156100 (xrender: Subpixel drawing bug in Java 8) - under some circumstances paths do not align with fills when subpixel coordinates are used. The issue seems to be caused by ProcessPath and ShapeSpanIterator behaving differently with regards to rounding. I

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

Hi Jim, > If there is no way to silence the tool, then I'd recommend hard-coding our > own "dumb copy loop" instead so that the behavior continues to match what > memcpy should have been doing. Isn't performance/throughput a concern for this case? Mamcpy is usually highly tuned with hand-optimize

Re: [OpenJDK 2D-Dev] Review Request for bug (JDK-8039345) Strange behaviour of per-pixel translucency on linux

Hi Prasanta, Thanks for taking a look at this issue, indeed when writing that code I have forgotten about the translucent window case :/ Please note that Transparency.OPAQUE is also passed to the super constructor of XRWindowSurfaceData. I don't know if this is what causes Phil's issue, but at lea

Re: [OpenJDK 2D-Dev] JDK-8068529 XSync when xrender is turned off

Hi Sergey, > Is there a reason why AWT doesn't explicitly flush and whythe >> flush-after-blit approach was chosen? >> > If a sync will be implemented in a Swing, then will be necessary to add a > sync to all places where we paint an images to the screen, and this is > equivalent of current solut

Re: [OpenJDK 2D-Dev] JDK-8068529 XSync when xrender is turned off

Hi Sergey, Actually it will do this for any blits to the window, because the swing > can use different paint strategy(w/ or w/o buffer) or the user can draw > something to the window directly via BufferStrategy. > Thanks for the clarification. Is there a reason why AWT doesn't explicitly flush

Re: [OpenJDK 2D-Dev] JDK-8068529 XSync when xrender is turned off

Hi Jeroen, I'm the submitter of JDK-8068529 > and I'd like to > respond to the comments of this bug > Thanks for reporting this issue. > In reply to the comments of 2015-01-12: without xrender, XSync is indeed > called in X11SurfaceData.c, in f

Re: [OpenJDK 2D-Dev] Review request for first part of 8049757

Hi Phil, > Do you want me to commit this ? > We'd then need a new bug for the next chunk > of course .. Please. I'll provide a seperate patch for removing the unused methods you mentioned earlier. Thanks & best regards, Clemens

Re: [OpenJDK 2D-Dev] Review request for JDK-8054638 xrender: text drawn after setColor(Color.white) is actually black

> It needs the GPL license (copied from another test to get the right one) > and there's one typo : wether -> whether Header added, thanks for finding the typo: http://cr.openjdk.java.net/~ceisserer/8054638/WhiteTextColorTest.java > Otherwise looks fine. In case no other issues pop up and a sec

Re: [OpenJDK 2D-Dev] Review request for JDK-8054638 xrender: text drawn after setColor(Color.white) is actually black

Hi Phil, Please find the regression test at: http://cr.openjdk.java.net/~ceisserer/8054638/WhiteTextColorTest.java Thanks, Clemens

Re: [OpenJDK 2D-Dev] Review request for JDK-8054638 xrender: text drawn after setColor(Color.white) is actually black

Hi Phil, > Fix looks good. Is there a way you can check in a regression test along-side > the fix > else you'll need to add a 'noreg-' label on the JBS bug. Thanks for the review - I'll write a regression test today. - Clemens

Re: [OpenJDK 2D-Dev] Review request for JDK-8054638 xrender: text drawn after setColor(Color.white) is actually black

Sorry, forgot to include the link to the webrev: http://cr.openjdk.java.net/~ceisserer/8054638/webrev.00/ 2014-08-13 7:32 GMT+02:00 Clemens Eisserer : > Hello, > > Please review my fix for JDK-8054638 xrender: text drawn after > setColor(Color.white) is actually black. > >

[OpenJDK 2D-Dev] Review request for JDK-8054638 xrender: text drawn after setColor(Color.white) is actually black

Hello, Please review my fix for JDK-8054638 xrender: text drawn after setColor(Color.white) is actually black. The XRSolidSrcPict manages a small 1x1 pixmap which is used as source surface for some operations. To avoid redundant fillRect operations when setting it's color, the currently set pixe

Re: [OpenJDK 2D-Dev] Graphics2D.drawLine() seems to ignore BasicStroke.getEndCap()

Hi Julien, Mageia Linux' bug tracker most likely isn't the best place to file this bug - most distributors simply package OpenJDK and aren't involved in it's development (with redhat being one of the noteworthy exceptions) > This bug is reproducible only with the XRender pipeline. In your bug rep

[OpenJDK 2D-Dev] Review request for first part of 8049757

Hello, Please review my changes for the first patch of a series to come to cleanup the Xrender Java2D pipeline. http://cr.openjdk.java.net/~ceisserer/8049757/webrev.00/ This patch removes support for the Jules rasterizer backend, which relied on a modified version of the native Cairo library. It

Re: [OpenJDK 2D-Dev] Merging marlin & pisces rendering engines

Hi, I would like to add that, beside higher performance for rasterization, Marlin's capability to produce tiles larger than 32x32px also improves the performance with the XRender pipeline für larger antialiased shapes a lot. For modern drivers uploading 32x32 small coverage masks is more expensive

Re: [OpenJDK 2D-Dev] [PATCH] JDK-4627340 : RFE: A way to improve text printing performance for postscript devices (Improved proposal)

Hi Alex, > now that my OCA has been processed I would like to bring to attention a > proposal that > I posted earlier this year to this group. > And below a repost of the most recent version of the patch. Glad to hear the OCA process did work out for you :) > I don't know if anyone remembers bu

Re: [OpenJDK 2D-Dev] RFR: 8029628: Large amount of graphic artifacts

Hi Vadim, I experience similar issues with the D3D-pipeline on older AMD GPUs. A customer reported he experienced applet corruption with XOR rendering directly to screen on his Radeon 7570M with drivers from 05-2013 and JDK7u45: https://bugs.openjdk.java.net/browse/JDK-8029041 Later driver versio

Re: [OpenJDK 2D-Dev] request for review: JDK-8028722: XRender: Drawing strings with exactly 254 glyphs causes hangs

Hi Phil, Thanks for the review. > Not that it impacts us now but I think the tricky question is can we ever > remove the workaround? > ie how will we ever know when we are using a fixed xrender lib. > I'd like to see core Xrender add a "GetVersion()" API so we can figure this > stuff out at runt

[OpenJDK 2D-Dev] request for review: JDK-8028722: XRender: Drawing strings with exactly 254 glyphs causes hangs

Hi, Please review my fix for JDK-8028722: "XRender: Drawing strings with exactly 254 glyphs causes hangs" available at http://cr.openjdk.java.net/~ceisserer/8028722/webrev.00/ A test is available at: http://cr.openjdk.java.net/~ceisserer/8028722/XRenderElt254TextTest.java Problem description: Whe

Re: [OpenJDK 2D-Dev] RFR: Fix for 8027541: Fully transparent jframe becomes black.

Hi Phil, > http://cr.openjdk.java.net/~prr/8027541/ > > In the case where there is an alpha color on the window, the > X11 pipeline looks at the color model of the GraphicsConfiguration > and upgrades the surface to one with alpha. This makes the Xrender > pipeline do the same. SQE test failure, s

Re: [OpenJDK 2D-Dev] Resurrecting Lauren'ts work on speeding up Pisces

Hi, One wish regarding pisces came into my mind: Currently all AA tile generators feed 32x32 coverage tiles to the pipelines. While this might be a good idea for software-only pipelines due to good cache locality, it is a huge issue for at least the xrender pipeline. Each tile has to be uploaded

Re: [OpenJDK 2D-Dev] [8] Review request for 8011059 [macosx] Make JDK demos look perfect on retina displays

Hi, > PLEASE, PLEASE don't make us wait until JDK9 for something that worked really > well in Apple's JDK6. An internal API doesn't mean you can't use it with JDK8, only that it is not part of the default API (which is more or less the same as with Apple's JDK6). However wouldn't it better to wa

Re: [OpenJDK 2D-Dev] [8] Review request for 8011059 [macosx] Make JDK demos look perfect on retina displays

Hi Jim, > We should be looking to obsolete and delete getScaledInstance(), not giving > it a new lease on life with new capabilities... Marking it deprecated would probably be a good idea, at least the JDK7 javadocs don't warn developers in any way about the implications of using getScaledInstanc

Re: [OpenJDK 2D-Dev] [8] Review request for 8011059 [macosx] Make JDK demos look perfect on retina displays

Hi Sergey, > Well during draw of the image we should request appropriate scale image from > the user, who possible know better how its image can be scaled. > What can be better, than a method which "Creates a scaled version of this > image."? getScaledImage() returns a scaled "reference" (not a c

Re: [OpenJDK 2D-Dev] Request for review: Additional fix for JDK-7159455

> I think I had that backwards. I was referring to the other case which does > not call xrMgr.getExtraAlphaMask(): > > 312 // For quadrant-transformed blits geometry is not > stored inside the mask > 313 // therefore we can use a repeating 1x1 mask for > applying

Re: [OpenJDK 2D-Dev] Request for review: Additional fix for JDK-7159455

Hi Jim, Thanks for taking the time to review this in-depth. > I guess that also explains why the source coordinates were multiplied by the > scale, though that seems a rather odd way to handle these issues. Indeed, the offsets could be also stored as part of the transformation (as it is done for

Re: [OpenJDK 2D-Dev] Request for review: Additional fix for JDK-7159455

Hi Jim, > I sincerely apologize for not seeing this sooner, my email sorting is a > little primitive, > but I should check these alternate folders more often. Never mind :) > The one thing I am concerned about here is the rounding that is going on for > scaled images. You removed a comment abou

Re: [OpenJDK 2D-Dev] Review request for 8024767: [TEST] need test to cover JDK-7189452

Hi Alexander, > Please see the updated webrev: > http://cr.openjdk.java.net/~bae/8024767/webrev.01/ The fix looks fine to me. Thanks for creating the test-case :) - Clemens

Re: [OpenJDK 2D-Dev] request for review: xrender pipeline ignores center-coordinates of RadialGradient

Hi, Ok, this starts to become embarrassing ... sorry for the review request spam recently. I was stressed that my changes would be submitted too late, so I submitted as soon as I had a fix for an isolated issue. During extensive testing I've found a few other issues within the xrender pipeline pai

Re: [OpenJDK 2D-Dev] request for review: xrender pipeline ignores center-coordinates of RadialGradient

Please wait with the commit, there are a few other issues hidden in the horrors of the xrender pipeline's gradient support. 2013/10/19 Andrew Brygin : > Hello Clemens, > > the fix looks fine to me. > > Thanks, > Andrew > > > On 10/18/2013 8:59 PM, Clemens Eisserer

Re: [OpenJDK 2D-Dev] request for review: xrender pipeline ignores center-coordinates of RadialGradient

Please find a more extensive fix at: http://cr.openjdk.java.net/~ceisserer/fix13/webrev.02/ In addition to the fixes in webrev.00, this one also fixes the TexturePaint issues reported by Phil. With this patch the TransformedPaintTest is rendered correctly. The problem with TexturePaint was basica

[OpenJDK 2D-Dev] request for review: xrender pipeline ignores center-coordinates of RadialGradient

Hi, Please review my fix for the issue described below at: http://cr.openjdk.java.net/~ceisserer/fix13/webrev.00/ Problem description: Phil found an issue with TransformedPaintTest, where the center point of radial gradients was stuck at (0,0) with the xrender-pipeline enabled. The center-point w

Re: [OpenJDK 2D-Dev] Request for review: Additional fix for JDK-7159455

Another revision was required, available at: http://cr.openjdk.java.net/~ceisserer/fix12/webrev.04/ When the destination-area is quadratic, no geometry is stored inside the mask and therefore the composition-window is used for clipping and it's size has to be rounded properly. In cases where it is

Re: [OpenJDK 2D-Dev] request for review: JDK-7082809 : xrender artifacts caused by different interpretation of SRC operator

Hi Andrew, > a copyright header is missed in the new file XRSolidSrcPict.java. > Could you please add it? Done. Please find the updated webrev at: http://cr.openjdk.java.net/~ceisserer/7082809/webrev.06/ Thanks, Clemens

[OpenJDK 2D-Dev] request for review: JDK-7082809 : xrender artifacts caused by different interpretation of SRC operator

Please review my fix for bug "JDK-7082809 : xrender artifacts caused by different interpretation of SRC operator" located at: http://cr.openjdk.java.net/~ceisserer/7082809/webrev.05/ A manual test-case is available at: http://cr.openjdk.java.net/~ceisserer/7082809/CompositeTest.java Problem descri

Re: [OpenJDK 2D-Dev] Request for review: Additional fix for JDK-7159455

As usual, seconds after sending a review request I somewhere find another issue - sorry. Please instead of webrev.01, review http://cr.openjdk.java.net/~ceisserer/fix12/webrev.02/ In the previous version, I assumed not using a mask means a quadrant-rotated transform, which is not correct as the ma

Re: [OpenJDK 2D-Dev] Request for review: Additional fix for JDK-7159455

Hi, Please find an updated webrev with your suggestions at: http://cr.openjdk.java.net/~ceisserer/fix12/webrev.01/ > Am I reading this right. You are saying that it is used in a mixture of > cases and some of those will support full transforms? Exactly. > What I was suggesting is that the adjus

[OpenJDK 2D-Dev] Request for review: Additional fix for JDK-7159455

Hi, As Jim pointed out, my earlier fix for bug JDK-7159455 wasn't entirely correct as it allowed some shear-transformations to pass a check for a fast-path although they should have been rejected. He proposed a way of using the capabilities already provided by AffineTransform, which is correct, sh

Re: [OpenJDK 2D-Dev] Fix suggestion: Black boxes arround glyphs with SrcIn and Src/SrcIn+EA [OGL, D3D]

Hi Jim, > You should be able to use the same code as SRC for CLEAR, but you are > rejecting that operation. And, if the destination is opaque then SRC_IN is > identical to SRC, but you are rejecting that as well. > > Perhaps the lower layers are ignoring ISCOPY and seeing the SRC_IN or CLEAR > an

Re: [OpenJDK 2D-Dev] Request for review: JDK-7159455 : Nimbus scrollbar rendering glitch with xrender enabled on i945GM

Hi Jim, > Apologies as this is an old bug, but I just looked at the fix and it seems > to me that it will allow shearing transforms to pass because the tests are > incomplete. The 0or180 flag only tests if the horizontal lines stay > horizontal, but they could shift relative to each other in incr

[OpenJDK 2D-Dev] Fix suggestion: Black boxes arround glyphs with SrcIn and Src/SrcIn+EA [OGL, D3D]

Hi, Please review my fix-suggestion for the problem described below available at: http://cr.openjdk.java.net/~ceisserer/fix11/webrev.03/ A testcase is available at: http://cr.openjdk.java.net/~ceisserer/fix11/TextCompTest.java Problem description: When rendering Text with AlphaComposite.SrcIn and

Re: [OpenJDK 2D-Dev] RFR: 8024343: Change different color with the "The XOR alternation color" combobox, the color of the image can not shown immediately.

Hi Vadim, The fix itself looks fine to me - thanks for taking care about this. - Clemens PS: what is the reason for this bug is confidential? > Please review a fix for this bug: > https://bugs.openjdk.java.net/browse/JDK-8024343

Re: [OpenJDK 2D-Dev] request for review: JDK-8007386 On physical machine (video card is Intel Q45)the case of text is blank.

Hi Johnny, > Should: > if(major <= 3 && minor < 5) > > be changed to: > if (major < 3 || (major == 3 && minor < 5)) Thanks for taking such a close look - seems I forgot about the 2.x-kernels still out there. Please find the corrected webref at: http://cr.openjdk.java.net/~ceisserer/8007386/webrev

[OpenJDK 2D-Dev] Handling of premultication in the D3D & OGL pipelines

Hi, I am currently testing compatibility of the xrender pipeline with different composition operations, and I noticed for AlphaComposite.SRC the D3D and OGL pipelines store pre-multiplied colors in surfaces without an alpha-channel. For example the following code results in a black rectangle, ins

Re: [OpenJDK 2D-Dev] How to fall back to a software-primitive manually?

Hi again, I was able to work arround the issue by deciding inside DrawImage whether to handle the request in the pipeline or fall back to loops. Sorry for the spam ... - Clemens

Re: [OpenJDK 2D-Dev] request for review: JDK-8007386 On physical machine (video card is Intel Q45)the case of text is blank.

Hi Phil, > Shouldn't most of this be inside an "ifdef _linux_ ? > Solaris & (currently) even MacOS will compile this code. Thanks for the pointer, I completely forgot about OSX (solaris should work as-is). Please find an updated version at: http://cr.openjdk.java.net/~ceisserer/8007386/webrev.02/

Re: [OpenJDK 2D-Dev] request for review: JDK-7179526 : xrender : closed/sun/java2d/volatileImage/LineClipTest.java failed since jdk8b36

Hi Phil, Thanks for the review ... Just went through xrender-bugs at bugs.sun.com and this fix also fixes the RFE 7161406. Thanks, Clemens

[OpenJDK 2D-Dev] request for review: JDK-8007386 On physical machine (video card is Intel Q45)the case of text is blank.

Hi, Please review my fix for "JDK-8007386 On physical machine (video card is Intel Q45)the case of text is blank." at: http://cr.openjdk.java.net/~ceisserer/8007386/webrev.01/ Problem description: There has been a number of bug reports by users enabling the xrender pipeline on outdated systems (o

[OpenJDK 2D-Dev] How to fall back to a software-primitive manually?

Hi, There are some cases in the xrender pipeline which can only be accelerated under certain conditions, for example XRPMTransformedBlit will not work correctly with composite-operator=SRC. For text-rendering or maskfill I can control wether to fallback in validatePipe, however blits are registere

Re: [OpenJDK 2D-Dev] request for review: JDK-7179526 : xrender : closed/sun/java2d/volatileImage/LineClipTest.java failed since jdk8b36

seperate patch if it would help. Thanks, Clemens 2013/8/24 Clemens Eisserer : > Hello, > > Please review my fix for: JDK-7179526 : xrender : > closed/sun/java2d/volatileImage/LineClipTest.java failed since jdk8b36 > at http://cr.openjdk.java.net/~ceisserer/7179526/webrev.00/ > >

Re: [OpenJDK 2D-Dev] Review request for http://cr.openjdk.java.net/~ceisserer/fix10/

Hi Phil, > the webrev and test need a little clean-up : adding the @test and @bug tag + > GPL Please find a corrected version at http://cr.openjdk.java.net/~ceisserer/8024895/webrev.01/ along with a (hopefully) jtreg conformant testcase at http://cr.openjdk.java.net/~ceisserer/8024895/EABlitTest.

[OpenJDK 2D-Dev] Review request for http://cr.openjdk.java.net/~ceisserer/fix10/

Hi, Please review my fix at http://cr.openjdk.java.net/~ceisserer/fix10/ I haven't created a an official bug-id, because due to the migration to JIRA those user reports don't seem to be directly useable anyway. Problem description: For transformed blits the xrender pipeline uses caching-logic to

[OpenJDK 2D-Dev] request for review: 9006475: xrender: improve performance of small fillRect operations

Hi, Please review my patch for 9006475 at: http://cr.openjdk.java.net/~ceisserer/9006475/webrev.00/ Before this patch we were calling the native method XRenderRectanglesNative() even in the case that there was only single rectangle to be rendered (which is the case for Graphics.fillRect). As XRen

Re: [OpenJDK 2D-Dev] Request for review: JDK-7159455 : Nimbus scrollbar rendering glitch with xrender enabled on i945GM

> > the fix looks fine to me. > Thanks. Please commit. Regards, Clemens

Re: [OpenJDK 2D-Dev] Please review patch for bug 7189452

Thanks for the reviews. the fix looks fine to me. > Please commit it then. Thanks, Clemens

[OpenJDK 2D-Dev] Request for review: JDK-7159455 : Nimbus scrollbar rendering glitch with xrender enabled on i945GM

Hi, Please review my fix for: JDK-7159455 : Nimbus scrollbar rendering glitch with xrender enabled on i945GM available at: http://cr.openjdk.java.net/~ceisserer/7159455/webrev.00/ Problem description: Because of low coordinate precision on intel 945GM (gen3), nimbus scrollbares where rendered wit

[OpenJDK 2D-Dev] request for review: JDK-7179526 : xrender : closed/sun/java2d/volatileImage/LineClipTest.java failed since jdk8b36

Hello, Please review my fix for: JDK-7179526 : xrender : closed/sun/java2d/volatileImage/LineClipTest.java failed since jdk8b36 at http://cr.openjdk.java.net/~ceisserer/7179526/webrev.00/ Problem description: Lines weren't rendered in a consistent way when they were clipped. The issue originated

Re: [OpenJDK 2D-Dev] Defect 7032904(XRender: Java2Demo) remains

Hi Andrew, Thanks for your feedback. > Do you know which versions of libXrender are supported? We can check the > version > at configure time: > > $ pkg-config --modversion renderproto > 0.11.1 > > and disable the extension at compile-time. This is especially true with 6 > where, > IIRC, it's

Re: [OpenJDK 2D-Dev] Defect 7032904(XRender: Java2Demo) remains

Hi Frank, > Recently our team discovered defect 7032904(XRender: Java2Demo : Infinite > loop in Java_sun_java2d_loops_MaskBlit_MaskBlit on OEL 5.6 x64) still exists > in latest JDK (7u21) on SLES10SP4. It can be easily reproduced by running > SwingSet2 with Nimbus LAF. The issue is also seen i

Re: [OpenJDK 2D-Dev] sun.java2D.Pisces renderer Performance and Memory enhancements

Hi Laurent, thanks for having some interest for my efforts ! > As I got almost no feedback, I felt quite disappointed and was thinking > that improving pisces was not important ... > Glad to see work is ongoing to improve pisces's performance :) I had a look at the patch just to be curious (I do

Re: [OpenJDK 2D-Dev] Please review patch for 7105461

Hi, > Looks good to go. Thanks =) It would be great if somebody could commit the patch, please. > And it would be good to file the performance issue for > small numbers of rectangles in Jira... Has Jira been opened to the "public" already? Thanks, Clemens

[OpenJDK 2D-Dev] D3D pipeline not working with latest intel-drivers on sandy bridge

Hi, While performance testing to compare the different pipelines I noticed the D3D pipeline doesn't work ("Couldn't enable D3D pipeline") with Intel's latest drivers on Sandy Bridge running Windows7. As modern intel GPUs are feature-wise quite on par with "real" discrete graphic cards, and I am ab

Re: [OpenJDK 2D-Dev] Please review patch for 7105461

Hi Jim, > One comment on code style - "if" is not a function call so the style > guidelines specify a space before the parentheses with the conditional test > (line 128 and 135). Done. Will keep style guidlines in mind next time. > The logic looks fine, but I'll point out that width/height can ne

Re: [OpenJDK 2D-Dev] Please review patch for 7105461

Hi Jim, A new version of the patch is available at: http://cr.openjdk.java.net/~ceisserer/7105461/webrev.05/ > If x or y are > MAX_SHORT then you should probably just reject the operation > immediately, otherwise you end up with a bunch of math that should end up > doing a NOP, but it is tenuous

Re: [OpenJDK 2D-Dev] Please review patch for 7105461

Hi Jim, Thanks for your patience, sorry this bugfix review consumed so much time. Please find the latest webrev at http://cr.openjdk.java.net/~ceisserer/7105461/webrev.04/ The following changes were incooperated: - Grab AWT lock consistently before entering the try/catch block. - Clamp X/Y to S

Re: [OpenJDK 2D-Dev] Please review patch for 7105461

new methods in Math for unsigned results and exact > non-overflowing integer results as well, but that would complicate any > backports to JDK7...) > > ...jim > > > On 4/13/12 9:46 AM, Clemens Eisserer wrote: >> >> Hi, >>

Re: [OpenJDK 2D-Dev] request for review: 7188093

Hi, > Automated test will require taking screenshot and comparing results, I'm not > sure if this mechanism works good. It should be possible to render to a VolatileImage, which allows direct readback without taking a screenshot. - Clemens

Re: [OpenJDK 2D-Dev] request for review: 7188093

#x27; the regression test that identified > this bug. > > -phi. > > > On 9/18/2012 10:37 AM, Jim Graham wrote: >> >> This looks good. OpenGL and D3D punt under the same circumstances... >> >> ...jim >> >> On 9/18/2012 1:16 AM, Clem

[OpenJDK 2D-Dev] request for review: 7188093

Hello, Please review my fix for bug 7188093, located at: http://cr.openjdk.java.net/~ceisserer/7188093/webrev.01/ Billinear interpolation is the highest quality interpolation supported by xrender, so the xrender-pipeline has to fall back software loops in case bicubic interpolation is requested.

Re: [OpenJDK 2D-Dev] Xrender bicubic interpolation

Hi, Unfourtunatly the situation is worse than I expected, currently xrender doesn't seem to support anything better than billiniar interpolation. Because alias-names where used by the pipeline it didn't turn up sooner (as they are guaranteed to be available, whereas the concrete filter-implementat

[OpenJDK 2D-Dev] Please review patch for bug 7189452

Hi, During playing with bug 7082809 (which will require some more time to fix), I discovered another bug: 7189452 When rendering text with an xrender-surface as source (texturepaint, gradientpaint), the pipeline doesn't adjust the offset of the source-surface relative to the glyph list. This leads

Re: [OpenJDK 2D-Dev] Please review patch for 7105461

Hi, > Looks OK to me. I'd like Jim can take a look too .. Thanks for taking a look. After Jim's comment for 7154083, I think it might be better to make the bounding-box clipping unconditional in this case, as the checks are probably more expensive than the whole clipping. I'll prepare a second we

[OpenJDK 2D-Dev] Please review patch for 7150134

Hi Jim, > I don't understand.  You are checking to see if the line is inside the clip, > but your test will think that something is inside the clip when it is not so > the "fast path" code will be used for lines outside the clip.  If the case > can handle lines outside the clip then why test at al

Re: [OpenJDK 2D-Dev] Please review patch for 7105461

Hi Phil, Thanks for taking a look. > Fix looks reasonable and good to have a fix for this! > I do think it would be safer to be better than the X11 pipeline if possible I reworked the original patch a bit and put the checks at a higher level, based on the following two assumptions: - Clippin

[OpenJDK 2D-Dev] Please review patch for 7105461

Hi, Please take a look at the patch for bug 7105461, located at http://cr.openjdk.java.net/~ceisserer/7105461/webrev.00/ The problem was caused by Swing calling drawLine/fillRect with coordinates outside the valid X11 coordinate space. I took the same approach of the original X11 pipeline to simp

Re: [OpenJDK 2D-Dev] Please review patch for 7150134

Hi Jim, > For a complex clip it is not enough to test the two endpoints so I don't > think this fix will work for a line that spans between two portions of a > non-rectangular clip over a region that is outside the clip... This case is handled by the native clip, so it would just be a missed opti

Re: [OpenJDK 2D-Dev] Please review patch for 7150134

> > > On 4/5/2012 5:49 AM, Clemens Eisserer wrote: >> >> Hi, >> >> Please take a look at the patch for bug 7150134, located at >> http://cr.openjdk.java.net/~ceisserer/7150134/ >> >> The problem was caused by a fast-path in drawLine() which didn't

Re: [OpenJDK 2D-Dev] Please review patch for 7150134

Hi Mario, > The patch looks good to me. Thanks for taking a look. > Just wondering what is the impact of those two checks: > > +        if (compClip.contains(transX1, transY1) > +                && compClip.contains(transX2, transY2)) { > > for the most common cases? I wasn't able to measure any

[OpenJDK 2D-Dev] Please review patch for 7150134

Hi, Please take a look at the patch for bug 7150134, located at http://cr.openjdk.java.net/~ceisserer/7150134/ The problem was caused by a fast-path in drawLine() which didn't take clipping into account, therefor huge lines that would have been clipped away caused OOMs in xrender's bresenham code

  1   2   3   >