Re: [JAVA2D] Performance regression in 6u10 b22
Hmm. The 5.0 version doesn't work for me, it throws an exception when trying to init the LF: java.lang.InstantiationException: org.jvnet.substance.SubstanceLookAndFeel at java.lang.Class.newInstance0(Class.java:340) at java.lang.Class.newInstance(Class.java:308) at javax.swing.UIManager.setLookAndFeel(UIManager.java:585) at javax.swing.UIManager.initializeDefaultLAF(UIManager.java:1343) at javax.swing.UIManager.initialize(UIManager.java:1434) at javax.swing.UIManager.maybeInitialize(UIManager.java:1422) at javax.swing.UIManager.getUI(UIManager.java:1007) The 4.3 version starts fine (up the NPE I described above). Thanks, Dmitri [EMAIL PROTECTED] wrote: Dmitri, Thanks for testing this benchmark under Substance. The exception you're seeing under Substance 4.3 is due to the search menu widget that is being added to the menu bar once there are more than a certain number of menus / menu items. You can take the latest dev version of Substance 5.0 from [1]. It already has about 25% improvement running under software loops, and doesn't add that search menu widget by default. Thanks Kirill [1] https://substance.dev.java.net/servlets/ProjectDocumentList?folderID=9100 [Message sent by forum member 'kirillcool' (kirillcool)] http://forums.java.net/jive/thread.jspa?messageID=272345 === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help. === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help.
Re: [JAVA2D] Performance regression in 6u10 b22
Hmm. The 5.0 version doesn't work for me, it throws an exception when trying to init the LF: Dmitri, As described in the roadmap of Substance 5 [1], the SubstanceLookAndFeel class is now abstract. You can use one of the skin-based derived classes instead. You can run any one of the following with -Dswing.defaultlaf: * org.jvnet.substance.skin.SubstanceAutumnLookAndFeel * org.jvnet.substance.skin.SubstanceBusinessLookAndFeel * org.jvnet.substance.skin.SubstanceBusinessBlackSteelLookAndFeel * org.jvnet.substance.skin.SubstanceCremeLookAndFeel * org.jvnet.substance.skin.SubstanceNebulaLookAndFeel The performance of the latest dev drop of 5.0 should be even better than before (3-3.7 faster in my own benchmark). Thanks Kirill [1] http://www.pushing-pixels.org/?p=295 [Message sent by forum member 'kirillcool' (kirillcool)] http://forums.java.net/jive/thread.jspa?messageID=272404 === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help.
Re: [JAVA2D] Performance regression in 6u10 b22
OK, missed that, thanks. New issue, I'm getting these exceptions: Exception in thread AWT-EventQueue-0 java.lang.NoClassDefFoundError: org/jvnet/substance/utils/ColorSchemeFilter at org.jvnet.substance.SubstanceImageCreator.getColorSchemeImage(SubstanceImageCreator.java:2846) at org.jvnet.substance.painter.decoration.ImageWrapperDecorationPainter.getColorizedTile(ImageWrapperDecorationPainter.java:326) Which is weird because the class is in the jar file: #jar vtf c:/temp/subst/substance.jar 21 | grep ColorSchemeFilter 4583 Wed Apr 30 23:04:04 PDT 2008 org/jvnet/substance/utils/ColorSchemeFilter.class Here's my launch command line: export CLASSPATH=.;c:/temp/subst/substance.jar java -Dswing.defaultlaf=org.jvnet.substance.skin.SubstanceAutumnLookAndFeel SwingMark I'm also still getting the NPE from the menubar stuff - same as with 4.3. I guess I can hack the benchmark to check for null there but it would be nice to get this resolved since it's possible that other apps may run into this. Thanks, Dmitri [EMAIL PROTECTED] wrote: Hmm. The 5.0 version doesn't work for me, it throws an exception when trying to init the LF: Dmitri, As described in the roadmap of Substance 5 [1], the SubstanceLookAndFeel class is now abstract. You can use one of the skin-based derived classes instead. You can run any one of the following with -Dswing.defaultlaf: * org.jvnet.substance.skin.SubstanceAutumnLookAndFeel * org.jvnet.substance.skin.SubstanceBusinessLookAndFeel * org.jvnet.substance.skin.SubstanceBusinessBlackSteelLookAndFeel * org.jvnet.substance.skin.SubstanceCremeLookAndFeel * org.jvnet.substance.skin.SubstanceNebulaLookAndFeel The performance of the latest dev drop of 5.0 should be even better than before (3-3.7 faster in my own benchmark). Thanks Kirill [1] http://www.pushing-pixels.org/?p=295 [Message sent by forum member 'kirillcool' (kirillcool)] http://forums.java.net/jive/thread.jspa?messageID=272404 === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help. === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help.
Re: [JAVA2D] Performance regression in 6u10 b22
Dmitri Trembovetski wrote: I didn't have a chance to run the benchmark with Substance LF as got sidetracked by some bugs and JavaOne stuff. Just re-ran the benchmark for Nimbus LF on 6u10 with and w/o the D3D pipeline (time to complete benchmark in seconds, the lower the better): w/o d3d: 36253 with d3d: 25822 Unfortunately I've ran into a snag when trying to run with the Substance LF, it throws an NPE in the benchmark code in early stages of the benchmark =( I haven't looked at it in details yet, but it looks like a menu bar returns null from getMenu(i) call, where it's not supposed to: JMenu currentmenu = jmenubar.getMenu(i); int currentmenuMnem = currentmenu.getMnemonic(); The benchmark adds a bunch of menus to the menu bar, then drives them by sending the events. Will take a look at this later if I have time. Thanks, Dmitri === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help.
Re: [JAVA2D] Performance regression in 6u10 b22
Dmitri, Thanks for testing this benchmark under Substance. The exception you're seeing under Substance 4.3 is due to the search menu widget that is being added to the menu bar once there are more than a certain number of menus / menu items. You can take the latest dev version of Substance 5.0 from [1]. It already has about 25% improvement running under software loops, and doesn't add that search menu widget by default. Thanks Kirill [1] https://substance.dev.java.net/servlets/ProjectDocumentList?folderID=9100 [Message sent by forum member 'kirillcool' (kirillcool)] http://forums.java.net/jive/thread.jspa?messageID=272345 === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help.
Re: [JAVA2D] Performance regression in 6u10 b22
Hi, Dmitri You can probably figure out for yourself by inserting printouts in your rendering methods (doing fill with gradient, issuing drawImage etc), and specifying -Dsun.java2d.trace=log option which traces rendering primitives on the fly (as opposed to =count, which counts them and prints out the summary at the end). Then you'll see exactly what tracing lines correspond to your commands. Thanks for the advice. But in general, there's some information here: http://java.sun.com/javase/6/webnotes/trouble/TSG-Desktop/html/gcrua.html#gcrus This Java Client troubleshooting guide is quite useful, btw. Excellent indeed. Thanks for the link. Kirill [Message sent by forum member 'kirillcool' (kirillcool)] http://forums.java.net/jive/thread.jspa?messageID=272346 === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help.
Re: [JAVA2D] Performance regression in 6u10 b22
There still seems to be a fair number of unaccelerated calls, like MaskFills (fills of antialiased shapes), MaskBlits (AA shape filled with gradient), and BI to BI blits. Hi, Dmitri Thanks for looking into this. The advice on not setting AA mode prior to using operations that don't care about it (such as filling a rectangle, shape or gradient) is a very valuable one. Is this mentioned anywhere in the tutorials / javadoc? Is this implementation detail for Sun VM? Can this be handled in the core by ignoring the AA mode on operations that produce exactly the same results with or without AA turned on? In addition, i wonder what your thoughts are on Nimbus performance on my specific card (the one with acceleration). While in pure software Nimbus is twice as fast as Substance, on that card the usage of volatile images and accelerated loops seems to hurt Nimbus rather badly (instead of boosting it by 30-80% as your internal benchmark suggests). What does your internal benchmark do? Does it just run a sequence of Java2D operations, or is it a real app being tested? I would suggest such a heavy app as Netbeans or IntelliJ IDEA for a real test of performance gains on D3D pipeline. The last question - how can i look at the output of sun.java2d.trace=count and understand how it maps back to the Java2D APIs on Graphics and Graphics2D? How do i read something like sun.java2d.loops.Blit::Blit(IntRgb, SrcNoEa, IntArgbPre) or sun.java2d.loops.MaskBlit::MaskBlit(IntArgbPre, SrcOver, IntArgbPre)? Thanks for your help Kirill [Message sent by forum member 'kirillcool' (kirillcool)] http://forums.java.net/jive/thread.jspa?messageID=271749 === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help.
Re: [JAVA2D] Performance regression in 6u10 b22
Thanks, Kirill. There still seems to be a fair number of unaccelerated calls, like MaskFills (fills of antialiased shapes), MaskBlits (AA shape filled with gradient), and BI to BI blits. I know that Nimus does lots of caching in VolatileImages, and they can even use the cached copies for rendering different sizes of the same component by doing scaling. Since it's just a texture mapping operation, it is typically very fast. We have a Swing performance benchmark in house. It pains me to no end that we can't open source it or give you access to it. But I'll see if I can run it with Substance LF and compare with Nimbus and Ocean on my system. Thanks, Dmitri [EMAIL PROTECTED] wrote: Results of running this benchmark under Nimbus (6u10, b22): 810 calls to D3DDrawLine 19290 calls to sun.java2d.d3d.D3DRTTSurfaceToSurfaceBlit::Blit(D3D Surface (render-to-texture), An yAlpha, D3D Surface) 90 calls to sun.java2d.d3d.D3DSurfaceToSwBlit::Blit(D3D Surface, SrcNoEa, IntArgb) 25050 calls to sun.java2d.d3d.D3DRTTSurfaceToSurfaceTransform::TransformBlit(D3D Surface (render-to -texture), AnyAlpha, D3D Surface) 104 calls to sun.java2d.loops.MaskBlit::MaskBlit(IntArgbPre, SrcOver, IntArgbPre) 13290 calls to D3DDrawGlyphs 7626 calls to sun.java2d.d3d.D3DMaskFill::MaskFill(LinearGradientPaint, SrcOver, D3D Surface) 12 calls to sun.java2d.loops.MaskBlit::MaskBlit(IntRgb, AnyAlpha, IntArgbPre) 16 calls to sun.java2d.d3d.D3DSwToSurfaceBlit::Blit(ByteIndexed, AnyAlpha, D3D Surface) 16 calls to sun.java2d.d3d.D3DSwToTextureBlit::Blit(ByteIndexed, SrcNoEa, D3D Texture) 17 calls to sun.java2d.d3d.D3DSwToTextureBlit::Blit(IntArgb, SrcNoEa, D3D Texture) 34 calls to sun.java2d.loops.MaskFill::MaskFill(AnyColor, SrcOver, IntArgbPre) 11180 calls to D3DFillRect 83034 calls to sun.java2d.d3d.D3DMaskFill::MaskFill(AnyColor, SrcOver, D3D Surface) 8 calls to sun.java2d.loops.FillRect::FillRect(AnyColor, SrcNoEa, AnyInt) 104 calls to sun.java2d.loops.Blit$GeneralMaskBlit::Blit(IntArgbPre, SrcOverNoEa, IntArgbPre) 868 calls to sun.java2d.d3d.D3DSwToSurfaceBlit::Blit(IntRgb, AnyAlpha, D3D Surface) 2877 calls to sun.java2d.d3d.D3DTextureToSurfaceBlit::Blit(D3D Texture, AnyAlpha, D3D Surface) 2378 calls to sun.java2d.d3d.D3DMaskBlit::MaskBlit(IntRgb, SrcNoEa, D3D Surface) 17 calls to sun.java2d.d3d.D3DSwToSurfaceBlit::Blit(IntArgb, AnyAlpha, D3D Surface) 166821 total calls to 20 different primitives Result of running the benchmark on Substance with BufferedImages only: 30 calls to sun.java2d.d3d.D3DGeneralBlit::Blit(Any, AnyAlpha, D3D Surface) 720 calls to D3DDrawLine 16 calls to sun.java2d.d3d.D3DSwToTextureBlit::Blit(ByteIndexed, SrcNoEa, D3D Texture) 13976 calls to sun.java2d.loops.MaskFill::MaskFill(AnyColor, Src, IntArgbPre) 1653 calls to sun.java2d.loops.MaskFill::MaskFill(AnyColor, SrcOver, IntArgbPre) 55000 calls to sun.java2d.loops.Blit::Blit(IntRgb, SrcNoEa, IntArgbPre) 1 call to sun.java2d.loops.Blit$GeneralMaskBlit::Blit(IntArgb, SrcOverNoEa, IntArgb) 3 calls to sun.java2d.loops.ScaledBlit::ScaledBlit(ByteIndexedBm, SrcOverNoEa, IntRgb) 18 calls to sun.java2d.d3d.D3DSwToTextureBlit::Blit(IntArgb, SrcNoEa, D3D Texture) 12360 calls to sun.java2d.d3d.D3DMaskFill::MaskFill(AnyColor, SrcOver, D3D Surface) 10980 calls to sun.java2d.d3d.D3DMaskFill::MaskFill(LinearGradientPaint, SrcOver, D3D Surface) 1 call to sun.java2d.loops.MaskBlit::MaskBlit(IntArgb, SrcOver, IntArgb) 5155 calls to sun.java2d.loops.Blit$GeneralMaskBlit::Blit(IntArgbPre, SrcOverNoEa, IntArgbPre) 270 calls to D3DDrawRect 1260 calls to sun.java2d.d3d.D3DMaskFill::MaskFill(GradientPaint, SrcOver, D3D Surface) 10 calls to sun.java2d.loops.DrawRect::DrawRect(AnyColor, SrcNoEa, AnyInt) 30 calls to sun.java2d.loops.MaskBlit::MaskBlit(IntArgb, AnyAlpha, IntArgbPre) 2198 calls to sun.java2d.loops.Blit$GeneralMaskBlit::Blit(IntArgbPre, SrcOver, IntArgbPre) 4019 calls to sun.java2d.d3d.D3DSwToSurfaceBlit::Blit(IntArgbPre, AnyAlpha, D3D Surface) 3 calls to sun.java2d.loops.Blit::Blit(ByteIndexedBm, SrcOverNoEa, IntRgb) 3397 calls to sun.java2d.loops.MaskBlit::MaskBlit(IntArgb, SrcOver, IntArgbPre) 12 calls to sun.java2d.loops.FillSpans::FillSpans(AnyColor, SrcNoEa, AnyInt) 16 calls to sun.java2d.d3d.D3DSwToSurfaceBlit::Blit(ByteIndexed, AnyAlpha, D3D Surface) 30 calls to sun.java2d.loops.OpaqueCopyAnyToArgb::Blit(Any, SrcNoEa, IntArgb) 9630 calls to D3DFillSpans 18 calls to sun.java2d.d3d.D3DSwToSurfaceBlit::Blit(IntArgb, AnyAlpha, D3D Surface) 259 calls to sun.java2d.loops.TransformHelper::TransformHelper(IntArgbPre, SrcNoEa, IntArgbPre) 14190 calls to D3DDrawGlyphs 7353 calls to sun.java2d.loops.MaskBlit::MaskBlit(IntArgbPre, SrcOver, IntArgbPre) 450 calls to sun.java2d.loops.Blit$GeneralMaskBlit::Blit(IntArgbPre, DstIn, IntArgbPre) 1 call to sun.java2d.loops.MaskBlit::MaskBlit(IntArgbPre, SrcOver, IntArgb) 30 calls to sun.java2d.loops.Blit$GeneralMaskBlit::Blit(Any, SrcNoEa, IntArgbPre) 90 calls to
Re: [JAVA2D] Performance regression in 6u10 b22
Something even more interesting. I've ran the same performance suite on two machines, one having integrated Intel card, and another with NVidia card (from my previous reply). Both have Vista SP1 installed, both have dual-core CPU. Running the suite on integrated card takes 140ms on Substance and 71ms on Nimbus. Running the suite on NVidia card takes 500ms on Substance and 417ms on Nimbus. This is under the b22 of 6u10. The first machine has dual-core Intel 1.66GHz with 2GB RAM, the second machine has dual-core AMD 1.80GHz with 1GB RAM. Shouldn't i see a bigger difference favoring Nimbus in the second scenario? Kirill [Message sent by forum member 'kirillcool' (kirillcool)] http://forums.java.net/jive/thread.jspa?messageID=270889 === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help.
Re: [JAVA2D] Performance regression in 6u10 b22
What I find amusing is that the integrated card yielded better performance than your NVidia card. Doesn't that sounds weird to anyone else? [Message sent by forum member 'cowwoc' (cowwoc)] http://forums.java.net/jive/thread.jspa?messageID=270988 === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help.
Re: [JAVA2D] Performance regression in 6u10 b22
Could you run the benchmark on the same system with nvidia
with and w/o your fix, with -Dsun.java2d.trace=count parameter
and post the results?
Thanks,
Dmitri
[EMAIL PROTECTED] wrote:
Then in theory it should be fast once the cache is
filled since images can be cached in textures- but
according to the primitives log there's lots of unaccelerated
rendering going on - may be the benchmark basically only catches the
cache fill phase?
Dmitri,
The benchmark should catch only the cache hit phase. Following your advice, i
moved one of the image caches to use VolatileImages that get validated before every use.
While it takes the same time to run on unaccelerated pipeline, it takes about 5% more to
run on an NVidia card. Here is the output of J2D_TRACE_LEVEL=4:
[I] OS Version = OS_VISTA or newer
[I] CheckAdaptersInfo
[I] --
[I] Adapter Ordinal : 0
[I] Adapter Handle : 0x10001
[I] Description : NVIDIA MCP67M
[I] GDI Name, Driver : \\.\DISPLAY1, nvd3dum.dll
[I] Vendor Id: 0x10de
[I] Device Id: 0x0531
[I] SubSys Id: 0x30cf103c
[I] Driver Version : 7.15.11.147
[I] GUID : {D7B71E3E-4671-11CF-1F73-C41002C2CA35}
[I] D3DPPLM::CheckDeviceCaps: adapter 0: Passed
[I] --
[I] D3DGD_getDeviceCapsNative
[I] D3DContext::InitContext device 0
[I] D3DContext::ConfigureContext device 0
[V] dwBehaviorFlags=D3DCREATE_FPU_PRESERVE|D3DCREATE_HARDWARE_VERTEXPROCESSING
[I] D3DContext::ConfigureContext: successfully created device: 0
[I] D3DContext::InitDevice: device 0
[I] D3DContext::InitDefice: successfully initialized device 0
[V] | CAPS_DEVICE_OK
[V] | CAPS_RT_PLAIN_ALPHA
[V] | CAPS_RT_TEXTURE_ALPHA
[V] | CAPS_RT_TEXTURE_OPAQUE
[V] | CAPS_LCD_SHADER | CAPS_BIOP_SHADER | CAPS_PS20
[V] | CAPS_PS30
[V] | CAPS_MULTITEXTURE
[V] | CAPS_TEXNONPOW2
[V] | CAPS_TEXNONSQUARE
This is what i did to validate the VolatileImage after fetching it from a cache:
existing.validate(GraphicsEnvironment.getLocalGraphicsEnvironment()
.getDefaultScreenDevice().getDefaultConfiguration());
and the code for creating a new volatile image:
GraphicsEnvironment e = GraphicsEnvironment
.getLocalGraphicsEnvironment();
GraphicsDevice d = e.getDefaultScreenDevice();
GraphicsConfiguration c = d.getDefaultConfiguration();
VolatileImage compatibleImage = c.createCompatibleVolatileImage(width,
height, Transparency.TRANSLUCENT);
return compatibleImage;
Thanks
Kirill
[Message sent by forum member 'kirillcool' (kirillcool)]
http://forums.java.net/jive/thread.jspa?messageID=270882
===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST. For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.
===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST. For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.
Re: [JAVA2D] Performance regression in 6u10 b22
Will do in the evening. Thanks Kirill [Message sent by forum member 'kirillcool' (kirillcool)] http://forums.java.net/jive/thread.jspa?messageID=271046 === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help.
Re: [JAVA2D] Performance regression in 6u10 b22
What I find amusing is that the integrated card yielded better performance than your NVidia card. Doesn't that sounds weird to anyone else? On Linux thats a usual case for 2D. Drivers available are quite poor, and also the frameworks for 2D accaleration are not that well tuned, so you get really good performance from integrated chipsets because software-fallbacks are really cheap. For discrete cards a software-fallback means a large and costly bus-tranfer, for the integrated just some memcpy in the worst case. lg Clemens [Message sent by forum member 'linuxhippy' (linuxhippy)] http://forums.java.net/jive/thread.jspa?messageID=271084 === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help.
Re: [JAVA2D] Performance regression in 6u10 b22
Results of running this benchmark under Nimbus (6u10, b22): 810 calls to D3DDrawLine 19290 calls to sun.java2d.d3d.D3DRTTSurfaceToSurfaceBlit::Blit(D3D Surface (render-to-texture), An yAlpha, D3D Surface) 90 calls to sun.java2d.d3d.D3DSurfaceToSwBlit::Blit(D3D Surface, SrcNoEa, IntArgb) 25050 calls to sun.java2d.d3d.D3DRTTSurfaceToSurfaceTransform::TransformBlit(D3D Surface (render-to -texture), AnyAlpha, D3D Surface) 104 calls to sun.java2d.loops.MaskBlit::MaskBlit(IntArgbPre, SrcOver, IntArgbPre) 13290 calls to D3DDrawGlyphs 7626 calls to sun.java2d.d3d.D3DMaskFill::MaskFill(LinearGradientPaint, SrcOver, D3D Surface) 12 calls to sun.java2d.loops.MaskBlit::MaskBlit(IntRgb, AnyAlpha, IntArgbPre) 16 calls to sun.java2d.d3d.D3DSwToSurfaceBlit::Blit(ByteIndexed, AnyAlpha, D3D Surface) 16 calls to sun.java2d.d3d.D3DSwToTextureBlit::Blit(ByteIndexed, SrcNoEa, D3D Texture) 17 calls to sun.java2d.d3d.D3DSwToTextureBlit::Blit(IntArgb, SrcNoEa, D3D Texture) 34 calls to sun.java2d.loops.MaskFill::MaskFill(AnyColor, SrcOver, IntArgbPre) 11180 calls to D3DFillRect 83034 calls to sun.java2d.d3d.D3DMaskFill::MaskFill(AnyColor, SrcOver, D3D Surface) 8 calls to sun.java2d.loops.FillRect::FillRect(AnyColor, SrcNoEa, AnyInt) 104 calls to sun.java2d.loops.Blit$GeneralMaskBlit::Blit(IntArgbPre, SrcOverNoEa, IntArgbPre) 868 calls to sun.java2d.d3d.D3DSwToSurfaceBlit::Blit(IntRgb, AnyAlpha, D3D Surface) 2877 calls to sun.java2d.d3d.D3DTextureToSurfaceBlit::Blit(D3D Texture, AnyAlpha, D3D Surface) 2378 calls to sun.java2d.d3d.D3DMaskBlit::MaskBlit(IntRgb, SrcNoEa, D3D Surface) 17 calls to sun.java2d.d3d.D3DSwToSurfaceBlit::Blit(IntArgb, AnyAlpha, D3D Surface) 166821 total calls to 20 different primitives Result of running the benchmark on Substance with BufferedImages only: 30 calls to sun.java2d.d3d.D3DGeneralBlit::Blit(Any, AnyAlpha, D3D Surface) 720 calls to D3DDrawLine 16 calls to sun.java2d.d3d.D3DSwToTextureBlit::Blit(ByteIndexed, SrcNoEa, D3D Texture) 13976 calls to sun.java2d.loops.MaskFill::MaskFill(AnyColor, Src, IntArgbPre) 1653 calls to sun.java2d.loops.MaskFill::MaskFill(AnyColor, SrcOver, IntArgbPre) 55000 calls to sun.java2d.loops.Blit::Blit(IntRgb, SrcNoEa, IntArgbPre) 1 call to sun.java2d.loops.Blit$GeneralMaskBlit::Blit(IntArgb, SrcOverNoEa, IntArgb) 3 calls to sun.java2d.loops.ScaledBlit::ScaledBlit(ByteIndexedBm, SrcOverNoEa, IntRgb) 18 calls to sun.java2d.d3d.D3DSwToTextureBlit::Blit(IntArgb, SrcNoEa, D3D Texture) 12360 calls to sun.java2d.d3d.D3DMaskFill::MaskFill(AnyColor, SrcOver, D3D Surface) 10980 calls to sun.java2d.d3d.D3DMaskFill::MaskFill(LinearGradientPaint, SrcOver, D3D Surface) 1 call to sun.java2d.loops.MaskBlit::MaskBlit(IntArgb, SrcOver, IntArgb) 5155 calls to sun.java2d.loops.Blit$GeneralMaskBlit::Blit(IntArgbPre, SrcOverNoEa, IntArgbPre) 270 calls to D3DDrawRect 1260 calls to sun.java2d.d3d.D3DMaskFill::MaskFill(GradientPaint, SrcOver, D3D Surface) 10 calls to sun.java2d.loops.DrawRect::DrawRect(AnyColor, SrcNoEa, AnyInt) 30 calls to sun.java2d.loops.MaskBlit::MaskBlit(IntArgb, AnyAlpha, IntArgbPre) 2198 calls to sun.java2d.loops.Blit$GeneralMaskBlit::Blit(IntArgbPre, SrcOver, IntArgbPre) 4019 calls to sun.java2d.d3d.D3DSwToSurfaceBlit::Blit(IntArgbPre, AnyAlpha, D3D Surface) 3 calls to sun.java2d.loops.Blit::Blit(ByteIndexedBm, SrcOverNoEa, IntRgb) 3397 calls to sun.java2d.loops.MaskBlit::MaskBlit(IntArgb, SrcOver, IntArgbPre) 12 calls to sun.java2d.loops.FillSpans::FillSpans(AnyColor, SrcNoEa, AnyInt) 16 calls to sun.java2d.d3d.D3DSwToSurfaceBlit::Blit(ByteIndexed, AnyAlpha, D3D Surface) 30 calls to sun.java2d.loops.OpaqueCopyAnyToArgb::Blit(Any, SrcNoEa, IntArgb) 9630 calls to D3DFillSpans 18 calls to sun.java2d.d3d.D3DSwToSurfaceBlit::Blit(IntArgb, AnyAlpha, D3D Surface) 259 calls to sun.java2d.loops.TransformHelper::TransformHelper(IntArgbPre, SrcNoEa, IntArgbPre) 14190 calls to D3DDrawGlyphs 7353 calls to sun.java2d.loops.MaskBlit::MaskBlit(IntArgbPre, SrcOver, IntArgbPre) 450 calls to sun.java2d.loops.Blit$GeneralMaskBlit::Blit(IntArgbPre, DstIn, IntArgbPre) 1 call to sun.java2d.loops.MaskBlit::MaskBlit(IntArgbPre, SrcOver, IntArgb) 30 calls to sun.java2d.loops.Blit$GeneralMaskBlit::Blit(Any, SrcNoEa, IntArgbPre) 90 calls to sun.java2d.d3d.D3DSurfaceToSwBlit::Blit(D3D Surface, SrcNoEa, IntArgb) 10287 calls to sun.java2d.d3d.D3DTextureToSurfaceBlit::Blit(D3D Texture, AnyAlpha, D3D Surface) 7046 calls to sun.java2d.loops.MaskBlit::MaskBlit(IntRgb, AnyAlpha, IntArgbPre) 3397 calls to sun.java2d.loops.Blit$GeneralMaskBlit::Blit(IntArgb, SrcOverNoEa, IntArgbPre) 76 calls to sun.java2d.d3d.D3DSwToTextureBlit::Blit(IntArgbPre, SrcNoEa, D3D Texture) 90 calls to sun.java2d.loops.DrawGlyphList::DrawGlyphList(AnyColor, SrcNoEa, AnyInt) 1080 calls to D3DFillPath 1 call to sun.java2d.loops.Blit$GeneralMaskBlit::Blit(IntArgbPre, SrcOverNoEa, IntArgb) 540 calls to sun.java2d.loops.Blit$GeneralMaskBlit::Blit(IntArgbPre, DstOut, IntArgbPre) 24002 calls to
Re: [JAVA2D] Performance regression in 6u10 b22
Then it is likely caused by this fix, although I don't quote see how http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6679308 We did a bit of testing and one necessary correctness change in this bug fix was made in SrcOver software blit and fill loops. ie I know exactly which line of code makes the performance change come and go in your app, but its not something we can undo. The strange part of it is that the change is just a compile time macro so that for opaque destinations, there should be no runtime cost. ie logically if anything it should lead to less work, not more. And for non-opaque destinations, it should be exactly as it was before. Not sure why it affects your app - we couldn't make it show up any of the tests in J2DBench2. Either the Microsoft compiler is doing something that adversely affects the generated code, or perhaps the different results in the opaque dest case cause more work to be needed, but it seemed likely you were hitting the first case. -phil. Dmitri Trembovetski wrote: [EMAIL PROTECTED] wrote: Hi, Dmitri The output of trace_level: [I] OS Version = OS_VISTA or newer [E] D3DPPLM::CheckForBadHardware: found matching hardware: VendorId=0x8086 DeviceId=0x [E] D3DPPLM::CheckForBadHardware: bad hardware found, device disabled [E] D3DPPLM::GDICheckForBadHardware: no suitable devices found OK, you have an Intel chip. The d3d pipeline is disabled for all Intel boards so the regression is probably not related to the d3d changes in this build. Then it is likely caused by this fix, although I don't quote see how http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6679308 Does your code render to translucent images much? === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help.
Re: [JAVA2D] Performance regression in 6u10 b22
Another observation we have made is that it appears that Substance Look and Feel does lots of unaccelerated rendering - meaning, rendering to un-accelerated destinations. Unfortunately this affects performance negatively when the D3D pipeline is enabled: first, we do most of the rendering into BufferedImages, then they are blitted into the accelerated destination (Swing back buffer). This last operation is known not to perform well on most boards (see another thread in this forum). I would suggest to reduce the number of operations you do to BufferedImages. If you use some temp. buffered images for rendering, consider changing them to translucent volatile images (assuming you don't need access to pixels). This will not affect performance when these are not accelerated but will help when they are. Thanks, Dmitri Phil Race wrote: Then it is likely caused by this fix, although I don't quote see how http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6679308 We did a bit of testing and one necessary correctness change in this bug fix was made in SrcOver software blit and fill loops. ie I know exactly which line of code makes the performance change come and go in your app, but its not something we can undo. The strange part of it is that the change is just a compile time macro so that for opaque destinations, there should be no runtime cost. ie logically if anything it should lead to less work, not more. And for non-opaque destinations, it should be exactly as it was before. Not sure why it affects your app - we couldn't make it show up any of the tests in J2DBench2. Either the Microsoft compiler is doing something that adversely affects the generated code, or perhaps the different results in the opaque dest case cause more work to be needed, but it seemed likely you were hitting the first case. -phil. Dmitri Trembovetski wrote: [EMAIL PROTECTED] wrote: Hi, Dmitri The output of trace_level: [I] OS Version = OS_VISTA or newer [E] D3DPPLM::CheckForBadHardware: found matching hardware: VendorId=0x8086 DeviceId=0x [E] D3DPPLM::CheckForBadHardware: bad hardware found, device disabled [E] D3DPPLM::GDICheckForBadHardware: no suitable devices found OK, you have an Intel chip. The d3d pipeline is disabled for all Intel boards so the regression is probably not related to the d3d changes in this build. Then it is likely caused by this fix, although I don't quote see how http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6679308 Does your code render to translucent images much? === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help. === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help.
Re: [JAVA2D] Performance regression in 6u10 b22
I would suggest to reduce the number of operations you do to BufferedImages. If you use some temp. buffered images for rendering, consider changing them to translucent volatile images (assuming you don't need access to pixels). This will not affect performance when these are not accelerated but will help when they are. Dmitri, I did not see any change (on unaccelerated pipeline) between these two ways to create an offscreen image: [code] BufferedImage image = new BufferedImage(width, height, BufferedImage.TYPE_INT_ARGB); Graphics2D graphics = (Graphics2D) image.getGraphics().create(); graphics.setColor(new Color(0, 0, 0, 0)); graphics.setComposite(AlphaComposite.Src); graphics.fillRect(0, 0, width, height); graphics.dispose(); return image; [/code] and [code] GraphicsEnvironment e = GraphicsEnvironment .getLocalGraphicsEnvironment(); GraphicsDevice d = e.getDefaultScreenDevice(); GraphicsConfiguration c = d.getDefaultConfiguration(); BufferedImage compatibleImage = c.createCompatibleImage(width, height, Transparency.TRANSLUCENT); return compatibleImage; [/code] Substance uses image caches to speed up the painting. So the two code samples above play a very central role in the Substance painting pipeline. Release 4.3 uses the first approach. Should i use the second one, and if not, what is the correct way to create translucent volatile images that can be cached and rendered multiple times? Thanks for looking into this. Kirill [Message sent by forum member 'kirillcool' (kirillcool)] http://forums.java.net/jive/thread.jspa?messageID=270836 === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help.
Re: [JAVA2D] Performance regression in 6u10 b22
Hi Kirill, [EMAIL PROTECTED] wrote: Dmitri, I did not see any change (on unaccelerated pipeline) between these two ways to create an offscreen image: [code] BufferedImage image = new BufferedImage(width, height, BufferedImage.TYPE_INT_ARGB); Graphics2D graphics = (Graphics2D) image.getGraphics().create(); graphics.setColor(new Color(0, 0, 0, 0)); graphics.setComposite(AlphaComposite.Src); graphics.fillRect(0, 0, width, height); graphics.dispose(); return image; [/code] and [code] GraphicsEnvironment e = GraphicsEnvironment .getLocalGraphicsEnvironment(); GraphicsDevice d = e.getDefaultScreenDevice(); GraphicsConfiguration c = d.getDefaultConfiguration(); BufferedImage compatibleImage = c.createCompatibleImage(width, height, Transparency.TRANSLUCENT); return compatibleImage; [/code] Substance uses image caches to speed up the painting. So the two code examples above play a very central role in the Substance painting pipeline. Release 4.3 uses the first approach. Should i use the second one, and if not, what is the correct way to create translucent volatile images that can be cached and rendered multiple times? In both cases above you create a BufferedImage, not a Volatile one. To create VolatileImage, you'd need to use GC.createCompatibleVolatileImage(). (you'd need to add some extra code to validate them before you use them though, but for testing purposes, just validate them once when you create) And even if you switch to VIs, for un-accelerated case (like on your Intel system) there will be no difference. Nimbus LF uses VIs for caching, and they saw pretty good performance improvement from that with the d3d pipeline enabled. Caching makes sense if you don't change the contents of the cache much. Does your code update the cached images often? If you run your benchmark on hw-accel pipeline with -Dsun.java2d.trace=count, you'll see that out of about 500.000 calls more than half were rendered into a buffered image. One perf.-related suggestion: make sure you don't clear the background (fillRect) with antialiasing enabled (a common mistake). So if your components need to clear the bg first, unset the AA, clear, then set it back. Thanks, Dmitri Thanks for looking into this. Kirill [Message sent by forum member 'kirillcool' (kirillcool)] http://forums.java.net/jive/thread.jspa?messageID=270836 === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help. === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help.
Re: [JAVA2D] Performance regression in 6u10 b22
Hi, Dmitri In both cases above you create a BufferedImage, not a Volatile one. To create VolatileImage, you'd need to use GC.createCompatibleVolatileImage(). (you'd need to add some extra code to validate them before you use them though, but for testing purposes, just validate them once when you create) Correct me if i'm wrong, but shouldn't i be validating a cached volatile image befoer every use? Nimbus LF uses VIs for caching, and they saw pretty good performance improvement from that with the d3d pipeline enabled. I don't believe that we have access to sources of 6u10 in general, and of Nimbus in particular. Caching makes sense if you don't change the contents of the cache much. Does your code update the cached images often? Once the image gets into the cache, its contents are never touched. One perf.-related suggestion: make sure you don't clear the background (fillRect) with antialiasing enabled (a common mistake). So if your components need to clear the bg first, unset the AA, clear, then set it back. I will look at the code to make sure that i don't do that. Thanks for the tips. Kirill [Message sent by forum member 'kirillcool' (kirillcool)] http://forums.java.net/jive/thread.jspa?messageID=270840 === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help.
Re: [JAVA2D] Performance regression in 6u10 b22
[EMAIL PROTECTED] wrote: Hi, Dmitri In both cases above you create a BufferedImage, not a Volatile one. To create VolatileImage, you'd need to use GC.createCompatibleVolatileImage(). (you'd need to add some extra code to validate them before you use them though, but for testing purposes, just validate them once when you create) Correct me if i'm wrong, but shouldn't i be validating a cached volatile image befoer every use? Yes, VI should be validated before every use. I'm just saying that for a quick test you don't need to do that. Nimbus LF uses VIs for caching, and they saw pretty good performance improvement from that with the d3d pipeline enabled. I don't believe that we have access to sources of 6u10 in general, and of Nimbus in particular. I understand - I was just pointing out that it is beneficial to use hw acceleration if available - we have a success story to prove it =) Caching makes sense if you don't change the contents of the cache much. Does your code update the cached images often? Once the image gets into the cache, its contents are never touched. Then in theory it should be fast once the cache is filled since images can be cached in textures- but according to the primitives log there's lots of unaccelerated rendering going on - may be the benchmark basically only catches the cache fill phase? One good thing about VolatileImages is that they don't increase the footprint of the application (if they reside in vram). One perf.-related suggestion: make sure you don't clear the background (fillRect) with antialiasing enabled (a common mistake). So if your components need to clear the bg first, unset the AA, clear, then set it back. I will look at the code to make sure that i don't do that. Thanks for the tips. Kirill [Message sent by forum member 'kirillcool' (kirillcool)] http://forums.java.net/jive/thread.jspa?messageID=270840 === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help. === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help.
Re: [JAVA2D] Performance regression in 6u10 b22
Then in theory it should be fast once the cache is
filled since images can be cached in textures- but
according to the primitives log there's lots of unaccelerated
rendering going on - may be the benchmark basically only catches the
cache fill phase?
Dmitri,
The benchmark should catch only the cache hit phase. Following your advice, i
moved one of the image caches to use VolatileImages that get validated before
every use. While it takes the same time to run on unaccelerated pipeline, it
takes about 5% more to run on an NVidia card. Here is the output of
J2D_TRACE_LEVEL=4:
[I] OS Version = OS_VISTA or newer
[I] CheckAdaptersInfo
[I] --
[I] Adapter Ordinal : 0
[I] Adapter Handle : 0x10001
[I] Description : NVIDIA MCP67M
[I] GDI Name, Driver : \\.\DISPLAY1, nvd3dum.dll
[I] Vendor Id: 0x10de
[I] Device Id: 0x0531
[I] SubSys Id: 0x30cf103c
[I] Driver Version : 7.15.11.147
[I] GUID : {D7B71E3E-4671-11CF-1F73-C41002C2CA35}
[I] D3DPPLM::CheckDeviceCaps: adapter 0: Passed
[I] --
[I] D3DGD_getDeviceCapsNative
[I] D3DContext::InitContext device 0
[I] D3DContext::ConfigureContext device 0
[V] dwBehaviorFlags=D3DCREATE_FPU_PRESERVE|D3DCREATE_HARDWARE_VERTEXPROCESSING
[I] D3DContext::ConfigureContext: successfully created device: 0
[I] D3DContext::InitDevice: device 0
[I] D3DContext::InitDefice: successfully initialized device 0
[V] | CAPS_DEVICE_OK
[V] | CAPS_RT_PLAIN_ALPHA
[V] | CAPS_RT_TEXTURE_ALPHA
[V] | CAPS_RT_TEXTURE_OPAQUE
[V] | CAPS_LCD_SHADER | CAPS_BIOP_SHADER | CAPS_PS20
[V] | CAPS_PS30
[V] | CAPS_MULTITEXTURE
[V] | CAPS_TEXNONPOW2
[V] | CAPS_TEXNONSQUARE
This is what i did to validate the VolatileImage after fetching it from a cache:
existing.validate(GraphicsEnvironment.getLocalGraphicsEnvironment()
.getDefaultScreenDevice().getDefaultConfiguration());
and the code for creating a new volatile image:
GraphicsEnvironment e = GraphicsEnvironment
.getLocalGraphicsEnvironment();
GraphicsDevice d = e.getDefaultScreenDevice();
GraphicsConfiguration c = d.getDefaultConfiguration();
VolatileImage compatibleImage = c.createCompatibleVolatileImage(width,
height, Transparency.TRANSLUCENT);
return compatibleImage;
Thanks
Kirill
[Message sent by forum member 'kirillcool' (kirillcool)]
http://forums.java.net/jive/thread.jspa?messageID=270882
===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST. For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.
Re: [JAVA2D] Performance regression in 6u10 b22
Thanks for the report, Kirill. Could you run your app with J2D_TRACE_LEVEL=4 env. variable set on those machines and post the output? Also, could you run with -Dsun.java2d.d3d=false on both b21 and b22 and see if you still see a difference? There were a couple of fixes which could have caused this - one is d3d-related, another is text rendering loops fix. Thanks, Dmitri Java2D Team [EMAIL PROTECTED] wrote: After installing b22 on two Windows machines i see a performance regression of about 15-20% on the same internal benchmark that i'm running. The benchmark is just stressing Substance look-and-feel on different control types and includes a lot of Java2D operations, composites, translucencies, text painting, gradients etc. The code is the same between b21 and b22 and it's not something that i can post in the forum. To reproduce you would need to download the Substance distribution and run the test.perf.PerformanceSuite. It has a warmup stage when it's repainting the same frame 10 times, and then paints it once again, timing the painting time. It does so on three tabs and just prints out the average painting time. The code is the same, the OS is the same, but the 6u10 build is different. Kirill [Message sent by forum member 'kirillcool' (kirillcool)] http://forums.java.net/jive/thread.jspa?messageID=270098 === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help. === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help.
Re: [JAVA2D] Performance regression in 6u10 b22
Hi, Dmitri The output of trace_level: [I] OS Version = OS_VISTA or newer [E] D3DPPLM::CheckForBadHardware: found matching hardware: VendorId=0x8086 DeviceId=0x [E] D3DPPLM::CheckForBadHardware: bad hardware found, device disabled [E] D3DPPLM::GDICheckForBadHardware: no suitable devices found I'll try to install b21 tomorrow and run with that d3d flag. Thanks Kirill [Message sent by forum member 'kirillcool' (kirillcool)] http://forums.java.net/jive/thread.jspa?messageID=270144 === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help.
Re: [JAVA2D] Performance regression in 6u10 b22
[EMAIL PROTECTED] wrote: Hi, Dmitri The output of trace_level: [I] OS Version = OS_VISTA or newer [E] D3DPPLM::CheckForBadHardware: found matching hardware: VendorId=0x8086 DeviceId=0x [E] D3DPPLM::CheckForBadHardware: bad hardware found, device disabled [E] D3DPPLM::GDICheckForBadHardware: no suitable devices found OK, you have an Intel chip. The d3d pipeline is disabled for all Intel boards so the regression is probably not related to the d3d changes in this build. Then it is likely caused by this fix, although I don't quote see how http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6679308 Does your code render to translucent images much? I'll try to install b21 tomorrow and run with that d3d flag. The flag won't do anything because the d3d pipeline isn't enabled on your system anyway. BTW, you can save the current build (just copy the jdk dir somewhere) before reinstalling, so that you can compare them side by side. We'll try your benchmark inhouse as well. Thanks, Dmitri Thanks Kirill [Message sent by forum member 'kirillcool' (kirillcool)] http://forums.java.net/jive/thread.jspa?messageID=270144 === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help. === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help.
Re: [JAVA2D] Performance regression in 6u10 b22
Just forgot to mention - the main class expects two parameters. The first is the look-and-feel class name, and the second is the number of paint iterations. This is how i run it: C:\Program Files\Java\jdk1.6.0_10\bin\java -cp drop/substance.jar;drop/substance-tst.jar;lib/swingx.jar;lib/forms-1.1.0.jar;lib/substance-swingx.jar test.perf.PerformanceSuite org.jvnet.substance.skin.SubstanceAutumnLookAndFeel 20 [Message sent by forum member 'kirillcool' (kirillcool)] http://forums.java.net/jive/thread.jspa?messageID=270218 === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help.
Re: [JAVA2D] Performance regression in 6u10 b22
Running the benchmark on b21, i have results of 132, 132 and 134 ms. Running the benchmark on b22, i have results of 145, 146 and 145 ms. On another machine, the regression is from around 330ms to around 390ms. Thanks Kirill [Message sent by forum member 'kirillcool' (kirillcool)] http://forums.java.net/jive/thread.jspa?messageID=270217 === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help.
