Skip to main content

Performance regression in 6u10 b22

45 replies [Last post]
kirillcool
Offline
Joined: 2004-11-17

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

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
kirillcool
Offline
Joined: 2004-11-17

> Anyway, here are the results on my system (NVIDIA GF
> 7900GS, Pentium D 2.8Ghz, WinXP) - again the lower
> the better:
> d3d nod3d
> Nimbus 25838 36177
> Substance 59956 59349
> Windows L&F 20661 24170
> Ocean 16123 21659

Dmitri,

Would you mind rerunning the benchmark on the latest dev drop of Substance 5 [1]? I would be interested to see which scenarios are still significantly (>50%) slower under Substance as compared to Nimbus - on no-d3d rendering.

Thanks
Kirill

[1] https://substance.dev.java.net/servlets/ProjectDocumentList?folderID=9100

Dmitri Trembovetski

Hi Kirill,

I'm getting tons of these exceptions while running the benchmark:
Exception in thread "AWT-EventQueue-0" java.lang.IllegalArgumentException: Color likeness should be in 0.0-1.0 range
at org.jvnet.substance.utils.SubstanceColorUtilities.getInterpolatedRGB(SubstanceColorUtilities.java:306)
at org.jvnet.substance.utils.SubstanceColorUtilities.getInterpolatedColor(SubstanceColorUtilities.java:353)
at org.jvnet.substance.utils.SubstanceColorUtilities.getMidBorderColor(SubstanceColorUtilities.java:87)
at org.jvnet.substance.SubstanceImageCreator.paintSimpleBorder(SubstanceImageCreator.java:1195)
at org.jvnet.substance.SubstanceBorder.paintBorder(SubstanceBorder.java:197)
at org.jvnet.substance.SubstanceBorder.paintBorder(SubstanceBorder.java:215)
at javax.swing.border.CompoundBorder.paintBorder(Unknown Source)
at javax.swing.JComponent.paintBorder(Unknown Source)
at javax.swing.JComponent.paint(Unknown Source)
at TextAreaTest$CountTextArea.paint(TextAreaTest.java:98)
at javax.swing.JComponent.paintToOffscreen(Unknown Source)
...

My command line:
#> set CLASSPATH=".;c:/temp/subst50/lib/substance.jar;c:/temp/subst50/lib/swingx.jar;c:/temp/subst50/lib/substance-swingx.jar;"
#> java -Dswing.defaultlaf=org.jvnet.substance.skin.SubstanceAutumnLookAndFeel SwingMark -r 3 -q

Thanks,
Dmitri

java2d@JAVADESKTOP.ORG wrote:
>> Anyway, here are the results on my system (NVIDIA GF
>> 7900GS, Pentium D 2.8Ghz, WinXP) - again the lower
>> the better:
>> d3d nod3d
>> Nimbus 25838 36177
>> Substance 59956 59349
>> Windows L&F 20661 24170
>> Ocean 16123 21659
>
> Dmitri,
>
> Would you mind rerunning the benchmark on the latest dev drop of Substance 5 [1]? I would be interested to see which scenarios are still significantly (>50%) slower under Substance as compared to Nimbus - on no-d3d rendering.
>
> 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=275846
>
> ===========================================================================
> To unsubscribe, send email to listserv@java.sun.com and include in the body
> of the message "signoff JAVA2D-INTEREST". For general help, send email to
> listserv@java.sun.com and include in the body of the message "help".

===========================================================================
To unsubscribe, send email to listserv@java.sun.com and include in the body
of the message "signoff JAVA2D-INTEREST". For general help, send email to
listserv@java.sun.com and include in the body of the message "help".

kirillcool
Offline
Joined: 2004-11-17

:) Good thing that the check is there - it caught a logical bug in the painting code. Should be fixed now, at least for that particular code path.

Thanks
Kirill

Dmitri Trembovetski

OK, here are the results. (The numbers are subscores
from one of the runs, the lower the better,
Paint= is number of times paint was called
for those benchmarks that count it).

Substance With D3D:
**** Starting run 3****
Sub-Menus = 2790 (Paint = 0)
TextArea = 2369 (Paint = 790)
Sliders = 1481 (Paint = 508)
Lists = 904 (Paint = 759)
Table Rows = 3086 (Paint = 256)
Tree = 2525 (Paint = 831)
Score: 45309

Substance Without D3D:
**** Starting run 3****
Sub-Menus = 3413 (Paint = 0)
TextArea = 1262 (Paint = 787)
Sliders = 1310 (Paint = 508)
Lists = 795 (Paint = 755)
Table Rows = 2400 (Paint = 256)
Tree = 5143 (Paint = 830)
Score: 48177

Nimbus With D3D:
**** Starting run 3****
Sub-Menus = 2760 (Paint = 0)
TextArea = 1123 (Paint = 602)
Sliders = 623 (Paint = 502)
Lists = 515 (Paint = 493)
Table Rows = 1154 (Paint = 212)
Tree = 1809 (Paint = 787)
Score: 27646

Nimbus Without D3D:
**** Starting run 3****
Sub-Menus = 3569 (Paint = 0)
TextArea = 2010 (Paint = 602)
Sliders = 515 (Paint = 502)
Lists = 452 (Paint = 493)
Table Rows = 982 (Paint = 212)
Tree = 3850 (Paint = 787)
Score: 37969

Thanks,
Dmitri

===========================================================================
To unsubscribe, send email to listserv@java.sun.com and include in the body
of the message "signoff JAVA2D-INTEREST". For general help, send email to
listserv@java.sun.com and include in the body of the message "help".

kirillcool
Offline
Joined: 2004-11-17

Thanks, Dmitri

This is quite interesting. Would you mind providing a little bit more info on the "Table Rows" part? I have three separate scenarios, one for scrolling a 1000-row table to random non-consecutive locations, one for selecting a large number of rows and one for selecting a number of columns. My results show that Substance 5 is currently around 30-50% slower than Nimbus, and your benchmark has Substance slower by the factor of 2.5. I'd like to recreate such a scenario in my environment.

Another one - D3D painting of text areas is twice slower, and D3D painting of tables is around 30% slower (under Substance). This is interesting - what can be a possible reason for that?

Kirill

Dmitri Trembovetski

java2d@JAVADESKTOP.ORG wrote:
> Thanks, Dmitri
>
> This is quite interesting. Would you mind providing a little bit more info on the "Table Rows" part? I have three separate scenarios, one for scrolling a 1000-row table to random non-consecutive locations, one for selecting a large number of rows and one for selecting a number of columns. My results show that Substance 5 is currently around 30-50% slower than Nimbus, and your benchmark has Substance slower by the factor of 2.5. I'd like to recreate such a scenario in my environment.
>

That benchmark adds/removes a bunch of rows, selects rows/columns in different
combinations - multiple/single/single interval selection (making them the table scroll),
stuff like that..

> Another one - D3D painting of text areas is twice slower, and D3D painting of tables is around 30% slower (under Substance). This is interesting - what can be a possible reason for that?
>

LCD text is rendered using a shader, which requires reads from the destination surface
into a temp (also vram-based) surface. Depending on hardware this may be slower than
rendering to a BI. However I believe on this system pure text benchmarks
are faster with the d3d pipeline, so I don't know exactly why SwngMark benchmarks
are slower with d3d - it'd require some investigation.

Thanks,
Dmitri

===========================================================================
To unsubscribe, send email to listserv@java.sun.com and include in the body
of the message "signoff JAVA2D-INTEREST". For general help, send email to
listserv@java.sun.com and include in the body of the message "help".

kirillcool
Offline
Joined: 2004-11-17

> Substance 59956 59349

Dmitri,

Would you mind providing reference numbers for release 4.3 of Substance on the same benchmark?

Thanks
Kirill

Dmitri Trembovetski

java2d@JAVADESKTOP.ORG wrote:
>> Substance 59956 59349
> Would you mind providing reference numbers for release 4.3 of Substance on the same benchmark?

I got 93498 with d3d and 102026 w/o d3d, but it doesn't
use the same skin by default - the default with 4.3 looks
like Aqua. How do I chose Autumn skin on 4.3 from the command line?

Or, alternatively, how do I chose that aqua look on 5.0?

Thanks,
Dmitri

===========================================================================
To unsubscribe, send email to listserv@java.sun.com and include in the body
of the message "signoff JAVA2D-INTEREST". For general help, send email to
listserv@java.sun.com and include in the body of the message "help".

kirillcool
Offline
Joined: 2004-11-17

> I got 93498 with d3d and 102026 w/o d3d, but it
> doesn't use the same skin by default - the default with
> 4.3 looks like Aqua. How do I chose Autumn skin on 4.3 from
> the command line?

Dmitri,

It's the same as with 5.0 - org.jvnet.substance.skin.SubstanceAutumnLookAndFeel as the value for swing.defaultlaf VM flag.

Thanks for your time and help
Kirill

Dmitri Trembovetski

java2d@JAVADESKTOP.ORG wrote:
>> I got 93498 with d3d and 102026 w/o d3d, but it
>> doesn't use the same skin by default - the default with
>> 4.3 looks like Aqua. How do I chose Autumn skin on 4.3 from
>> the command line?
>
> Dmitri,
>
> It's the same as with 5.0 - org.jvnet.substance.skin.SubstanceAutumnLookAndFeel as the value for swing.defaultlaf VM flag.

D'oh!

OK, the results with AutumnL&F.
d3d: 117555
no d3d: 130214

So 5.0 is almost twice as fast.

Also, I got this exception once when running 4.3 with the default skin,
must be a race condition (it seems to access it from non-edt thread?):
Exception in thread "Laf-Widget fade tracker" java.lang.ArrayIndexOutOfBoundsException: 1 >= 1
at java.util.Vector.elementAt(Unknown Source)
at javax.swing.MenuSelectionManager.getSelectedPath(Unknown Source)
at org.jvnet.substance.utils.ComponentState.getState(ComponentState.java:267)
at org.jvnet.substance.utils.ComponentState.getState(ComponentState.java:230)
at org.jvnet.substance.SubstanceListUI.getCellState(SubstanceListUI.java:754)
at org.jvnet.substance.SubstanceListUI$CellRepaintCallback.fadePerformed(SubstanceListUI.java:360)
at org.jvnet.lafwidget.animation.FadeTracker.callbackCallFadePerformed(FadeTracker.java:450)
at org.jvnet.lafwidget.animation.FadeTracker.updateComponents(FadeTracker.java:381)
at org.jvnet.lafwidget.animation.FadeTracker.access$000(FadeTracker.java:47)
at org.jvnet.lafwidget.animation.FadeTracker$FadeTrackerThread.run(FadeTracker.java:205)

Thanks,
Dmitri

===========================================================================
To unsubscribe, send email to listserv@java.sun.com and include in the body
of the message "signoff JAVA2D-INTEREST". For general help, send email to
listserv@java.sun.com and include in the body of the message "help".

kirillcool
Offline
Joined: 2004-11-17

Hi, Dmitri

> OK, the results with AutumnL&F.
> d3d: 117555
> no d3d: 130214
> So 5.0 is almost twice as fast.

Sounds like a good start, but i would most certainly like to see it around (if not ahead of) Nimbus and Windows. I'll write my own dynamic benchmark and work on the scrolling / adding text / switching tabs / ... That'll most probably span beyond JavaOne.

> Also, I got this exception once when running 4.3
> with the default skin, must be a race condition (it seems to access it
> from non-edt thread?):

Yes, this has been already reported and should be fixed in the latest 4.3_06 release (to call MenuSelectionManager APIs from EDT). If this still happens under 4.3_06 or 5.0dev, it's a bug. You can see the Substance version stamp inside the manifest.mf of substance.jar.

Thanks
Kirill

Dmitri Trembovetski

java2d@JAVADESKTOP.ORG wrote:
> Hi, Dmitri
>
>> OK, the results with AutumnL&F.
>> d3d: 117555
>> no d3d: 130214
>> So 5.0 is almost twice as fast.
>
> Sounds like a good start, but i would most certainly like to see it around (if not ahead of) Nimbus and Windows. I'll write my own dynamic benchmark and work on the scrolling / adding text / switching tabs / ... That'll most probably span beyond JavaOne.
>

If you're around at Javaone I can show you the benchmark
so that you have a better idea of what it looks like.

>> Also, I got this exception once when running 4.3
>> with the default skin, must be a race condition (it seems to access it
>> from non-edt thread?):
>
> Yes, this has been already reported and should be fixed in the latest 4.3_06 release (to call MenuSelectionManager APIs from EDT). If this still happens under 4.3_06 or 5.0dev, it's a bug. You can see the Substance version stamp inside the manifest.mf of substance.jar.
>

I'll check the version tomorrow, but I downloaded it today from the project's
main page
https://substance.dev.java.net/servlets/ProjectDocumentList?folderID=8729

Thanks,
Dmitri

> Thanks
> Kirill
> [Message sent by forum member 'kirillcool' (kirillcool)]
>
> http://forums.java.net/jive/thread.jspa?messageID=272472
>
> ===========================================================================
> To unsubscribe, send email to listserv@java.sun.com and include in the body
> of the message "signoff JAVA2D-INTEREST". For general help, send email to
> listserv@java.sun.com and include in the body of the message "help".

===========================================================================
To unsubscribe, send email to listserv@java.sun.com and include in the body
of the message "signoff JAVA2D-INTEREST". For general help, send email to
listserv@java.sun.com and include in the body of the message "help".

kirillcool
Offline
Joined: 2004-11-17

> If you're around at Javaone I can show you the
> benchmark so that you have a better idea of what it looks
> like.

Sounds good. I'm going to most of the desktop sessions.

> I'll check the version tomorrow, but I downloaded
> it today from the project's main page

Will check this tomorrow to make sure that this method is not called outside EDT.

Thanks
Kirill

kirillcool
Offline
Joined: 2004-11-17

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.htm...
>
> This Java Client troubleshooting guide is quite useful, btw.

Excellent indeed. Thanks for the link.

Kirill

kirillcool
Offline
Joined: 2004-11-17

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 D3DFillRect
18 calls to sun.java2d.loops.DrawLine::DrawLine(AnyColor, SrcNoEa, AnyInt)
100 calls to sun.java2d.loops.FillRect::FillRect(AnyColor, SrcNoEa, AnyInt)
990 calls to sun.java2d.loops.MaskBlit::MaskBlit(IntArgbPre, AnyAlpha, IntArgbPre)
30 calls to sun.java2d.loops.MaskBlit$General::MaskBlit(Any, SrcNoEa, IntArgbPre)
190836 total calls to 46 different primitives

Running the benchmark on Substance with one cache using VolatileImages:

720 calls to D3DDrawLine
30 calls to sun.java2d.loops.MaskBlit::MaskBlit(IntArgb, AnyAlpha, IntArgbPre)
69 calls to sun.java2d.d3d.D3DSwToTextureBlit::Blit(IntArgbPre, SrcNoEa, "D3D Texture")
1 call to sun.java2d.loops.MaskBlit::MaskBlit(IntArgb, SrcOver, IntArgb)
30 calls to sun.java2d.loops.Blit$GeneralMaskBlit::Blit(Any, SrcNoEa, IntArgbPre)
1653 calls to sun.java2d.loops.MaskFill::MaskFill(AnyColor, SrcOver, IntArgbPre)
18 calls to sun.java2d.d3d.D3DSwToSurfaceBlit::Blit(IntArgb, AnyAlpha, "D3D Surface")
9342 calls to sun.java2d.d3d.D3DTextureToSurfaceBlit::Blit("D3D Texture", AnyAlpha, "D3D Surface")
4723 calls to sun.java2d.loops.Blit$GeneralMaskBlit::Blit(IntArgbPre, SrcOverNoEa, IntArgbPre)
90 calls to sun.java2d.loops.DrawGlyphList::DrawGlyphList(AnyColor, SrcNoEa, AnyInt)
56607 calls to sun.java2d.loops.Blit::Blit(IntRgb, SrcNoEa, IntArgbPre)
270 calls to D3DDrawRect
30 calls to sun.java2d.loops.MaskBlit$General::MaskBlit(Any, SrcNoEa, IntArgbPre)
18 calls to sun.java2d.d3d.D3DSwToTextureBlit::Blit(IntArgb, SrcNoEa, "D3D Texture")
1078 calls to sun.java2d.loops.MaskBlit::MaskBlit(IntArgbPre, AnyAlpha, IntArgbPre)
3 calls to sun.java2d.loops.Blit::Blit(ByteIndexedBm, SrcOverNoEa, IntRgb)
10 calls to sun.java2d.loops.DrawRect::DrawRect(AnyColor, SrcNoEa, AnyInt)
1988 calls to sun.java2d.loops.Blit$GeneralMaskBlit::Blit(IntArgbPre, SrcOver, IntArgbPre)
6868 calls to sun.java2d.loops.MaskBlit::MaskBlit(IntRgb, AnyAlpha, IntArgbPre)
1260 calls to sun.java2d.d3d.D3DMaskFill::MaskFill(GradientPaint, SrcOver, "D3D Surface")
1 call to sun.java2d.loops.Blit$GeneralMaskBlit::Blit(IntArgbPre, SrcOverNoEa, IntArgb)
2040 calls to sun.java2d.d3d.D3DRTTSurfaceToSurfaceBlit::Blit("D3D Surface (render-to-texture)", Any
Alpha, "D3D Surface")
3488 calls to sun.java2d.loops.MaskBlit::MaskBlit(IntArgb, SrcOver, IntArgbPre)
12 calls to sun.java2d.loops.FillSpans::FillSpans(AnyColor, SrcNoEa, AnyInt)
9630 calls to D3DFillSpans
258 calls to sun.java2d.loops.TransformHelper::TransformHelper(IntArgbPre, SrcNoEa, IntArgbPre)
1 call to sun.java2d.loops.Blit$GeneralMaskBlit::Blit(IntArgb, SrcOverNoEa, IntArgb)
1 call to sun.java2d.loops.MaskBlit::MaskBlit(IntArgbPre, SrcOver, IntArgb)
14190 calls to D3DDrawGlyphs
3699 calls to sun.java2d.d3d.D3DSwToSurfaceBlit::Blit(IntArgbPre, AnyAlpha, "D3D Surface")
6711 calls to sun.java2d.loops.MaskBlit::MaskBlit(IntArgbPre, SrcOver, IntArgbPre)
3 calls to sun.java2d.loops.ScaledBlit::ScaledBlit(ByteIndexedBm, SrcOverNoEa, IntRgb)
14456 calls to sun.java2d.loops.MaskFill::MaskFill(AnyColor, Src, IntArgbPre)
3488 calls to sun.java2d.loops.Blit$GeneralMaskBlit::Blit(IntArgb, SrcOverNoEa, IntArgbPre)
12360 calls to sun.java2d.d3d.D3DMaskFill::MaskFill(AnyColor, SrcOver, "D3D Surface")
1080 calls to D3DFillPath
27807 calls to D3DFillRect
30 calls to sun.java2d.d3d.D3DGeneralBlit::Blit(Any, AnyAlpha, "D3D Surface")
11274 calls to sun.java2d.d3d.D3DMaskFill::MaskFill(LinearGradientPaint, SrcOver, "D3D Surface")
18 calls to sun.java2d.loops.DrawLine::DrawLine(AnyColor, SrcNoEa, AnyInt)
30 calls to sun.java2d.loops.OpaqueCopyAnyToArgb::Blit(Any, SrcNoEa, IntArgb)
16 calls to sun.java2d.d3d.D3DSwToTextureBlit::Blit(ByteIndexed, SrcNoEa, "D3D Texture")
100 calls to sun.java2d.loops.FillRect::FillRect(AnyColor, SrcNoEa, AnyInt)
494 calls to sun.java2d.loops.Blit$GeneralMaskBlit::Blit(IntArgbPre, DstIn, IntArgbPre)
584 calls to sun.java2d.loops.Blit$GeneralMaskBlit::Blit(IntArgbPre, DstOut, IntArgbPre)
90 calls to sun.java2d.d3d.D3DSurfaceToSwBlit::Blit("D3D Surface", SrcNoEa, IntArgb)
16 calls to sun.java2d.d3d.D3DSwToSurfaceBlit::Blit(ByteIndexed, AnyAlpha, "D3D Surface")
196685 total calls to 47 different primitives

Dmitri Trembovetski

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 L&F and compare
with Nimbus and Ocean on my system.

Thanks,
Dmitri

java2d@JAVADESKTOP.ORG 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 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 D3DFillRect
> 18 calls to sun.java2d.loops.DrawLine::DrawLine(AnyColor, SrcNoEa, AnyInt)
> 100 calls to sun.java2d.loops.FillRect::FillRect(AnyColor, SrcNoEa, AnyInt)
> 990 calls to sun.java2d.loops.MaskBlit::MaskBlit(IntArgbPre, AnyAlpha, IntArgbPre)
> 30 calls to sun.java2d.loops.MaskBlit$General::MaskBlit(Any, SrcNoEa, IntArgbPre)
> 190836 total calls to 46 different primitives
>
> Running the benchmark on Substance with one cache using VolatileImages:
>
> 720 calls to D3DDrawLine
> 30 calls to sun.java2d.loops.MaskBlit::MaskBlit(IntArgb, AnyAlpha, IntArgbPre)
> 69 calls to sun.java2d.d3d.D3DSwToTextureBlit::Blit(IntArgbPre, SrcNoEa, "D3D Texture")
> 1 call to sun.java2d.loops.MaskBlit::MaskBlit(IntArgb, SrcOver, IntArgb)
> 30 calls to sun.java2d.loops.Blit$GeneralMaskBlit::Blit(Any, SrcNoEa, IntArgbPre)
> 1653 calls to sun.java2d.loops.MaskFill::MaskFill(AnyColor, SrcOver, IntArgbPre)
> 18 calls to sun.java2d.d3d.D3DSwToSurfaceBlit::Blit(IntArgb, AnyAlpha, "D3D Surface")
> 9342 calls to sun.java2d.d3d.D3DTextureToSurfaceBlit::Blit("D3D Texture", AnyAlpha, "D3D Surface")
> 4723 calls to sun.java2d.loops.Blit$GeneralMaskBlit::Blit(IntArgbPre, SrcOverNoEa, IntArgbPre)
> 90 calls to sun.java2d.loops.DrawGlyphList::DrawGlyphList(AnyColor, SrcNoEa, AnyInt)
> 56607 calls to sun.java2d.loops.Blit::Blit(IntRgb, SrcNoEa, IntArgbPre)
> 270 calls to D3DDrawRect
> 30 calls to sun.java2d.loops.MaskBlit$General::MaskBlit(Any, SrcNoEa, IntArgbPre)
> 18 calls to sun.java2d.d3d.D3DSwToTextureBlit::Blit(IntArgb, SrcNoEa, "D3D Texture")
> 1078 calls to sun.java2d.loops.MaskBlit::MaskBlit(IntArgbPre, AnyAlpha, IntArgbPre)
> 3 calls to sun.java2d.loops.Blit::Blit(ByteIndexedBm, SrcOverNoEa, IntRgb)
> 10 calls to sun.java2d.loops.DrawRect::DrawRect(AnyColor, SrcNoEa, AnyInt)
> 1988 calls to sun.java2d.loops.Blit$GeneralMaskBlit::Blit(IntArgbPre, SrcOver, IntArgbPre)
> 6868 calls to sun.java2d.loops.MaskBlit::MaskBlit(IntRgb, AnyAlpha, IntArgbPre)
> 1260 calls to sun.java2d.d3d.D3DMaskFill::MaskFill(GradientPaint, SrcOver, "D3D Surface")
> 1 call to sun.java2d.loops.Blit$GeneralMaskBlit::Blit(IntArgbPre, SrcOverNoEa, IntArgb)
> 2040 calls to sun.java2d.d3d.D3DRTTSurfaceToSurfaceBlit::Blit("D3D Surface (render-to-texture)", Any
> Alpha, "D3D Surface")
> 3488 calls to sun.java2d.loops.MaskBlit::MaskBlit(IntArgb, SrcOver, IntArgbPre)
> 12 calls to sun.java2d.loops.FillSpans::FillSpans(AnyColor, SrcNoEa, AnyInt)
> 9630 calls to D3DFillSpans
> 258 calls to sun.java2d.loops.TransformHelper::TransformHelper(IntArgbPre, SrcNoEa, IntArgbPre)
> 1 call to sun.java2d.loops.Blit$GeneralMaskBlit::Blit(IntArgb, SrcOverNoEa, IntArgb)
> 1 call to sun.java2d.loops.MaskBlit::MaskBlit(IntArgbPre, SrcOver, IntArgb)
> 14190 calls to D3DDrawGlyphs
> 3699 calls to sun.java2d.d3d.D3DSwToSurfaceBlit::Blit(IntArgbPre, AnyAlpha, "D3D Surface")
> 6711 calls to sun.java2d.loops.MaskBlit::MaskBlit(IntArgbPre, SrcOver, IntArgbPre)
> 3 calls to sun.java2d.loops.ScaledBlit::ScaledBlit(ByteIndexedBm, SrcOverNoEa, IntRgb)
> 14456 calls to sun.java2d.loops.MaskFill::MaskFill(AnyColor, Src, IntArgbPre)
> 3488 calls to sun.java2d.loops.Blit$GeneralMaskBlit::Blit(IntArgb, SrcOverNoEa, IntArgbPre)
> 12360 calls to sun.java2d.d3d.D3DMaskFill::MaskFill(AnyColor, SrcOver, "D3D Surface")
> 1080 calls to D3DFillPath
> 27807 calls to D3DFillRect
> 30 calls to sun.java2d.d3d.D3DGeneralBlit::Blit(Any, AnyAlpha, "D3D Surface")
> 11274 calls to sun.java2d.d3d.D3DMaskFill::MaskFill(LinearGradientPaint, SrcOver, "D3D Surface")
> 18 calls to sun.java2d.loops.DrawLine::DrawLine(AnyColor, SrcNoEa, AnyInt)
> 30 calls to sun.java2d.loops.OpaqueCopyAnyToArgb::Blit(Any, SrcNoEa, IntArgb)
> 16 calls to sun.java2d.d3d.D3DSwToTextureBlit::Blit(ByteIndexed, SrcNoEa, "D3D Texture")
> 100 calls to sun.java2d.loops.FillRect::FillRect(AnyColor, SrcNoEa, AnyInt)
> 494 calls to sun.java2d.loops.Blit$GeneralMaskBlit::Blit(IntArgbPre, DstIn, IntArgbPre)
> 584 calls to sun.java2d.loops.Blit$GeneralMaskBlit::Blit(IntArgbPre, DstOut, IntArgbPre)
> 90 calls to sun.java2d.d3d.D3DSurfaceToSwBlit::Blit("D3D Surface", SrcNoEa, IntArgb)
> 16 calls to sun.java2d.d3d.D3DSwToSurfaceBlit::Blit(ByteIndexed, AnyAlpha, "D3D Surface")
> 196685 total calls to 47 different primitives
> [Message sent by forum member 'kirillcool' (kirillcool)]
>
> http://forums.java.net/jive/thread.jspa?messageID=271126
>
> ===========================================================================
> To unsubscribe, send email to listserv@java.sun.com and include in the body
> of the message "signoff JAVA2D-INTEREST". For general help, send email to
> listserv@java.sun.com and include in the body of the message "help".

===========================================================================
To unsubscribe, send email to listserv@java.sun.com and include in the body
of the message "signoff JAVA2D-INTEREST". For general help, send email to
listserv@java.sun.com and include in the body of the message "help".

kirillcool
Offline
Joined: 2004-11-17

> 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

Dmitri Trembovetski

Hi Kirill,

I didn't have a chance to run the benchmark with
Substance LF as got sidetracked by some bugs and
JavaOne stuff.

java2d@JAVADESKTOP.ORG wrote:
>> 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?
>

I think this should be left to the developer. It's
hard for us to predict what exactly the user wants
to do.

> 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.

Without knowing what your benchmark does it's hard to tell.
There are some areas in the new pipeline which still need
some improvement, especially on smaller primitives.

The benchmark we have is a mock-up of an application which
uses a bunch of swing components, driven by injecting events,
as fast as possible. The score is the time it takes
to complete the scripted run. Typically it takes 10-15 seconds
per run (we use multiple runs).

It does a bunch of stuff like scrolling tables, lists,
adding/removing elements and such. Note that it's not
a pure graphics benchmark - it tests the
whole stack (swing+java2d). For pure graphics testing
we have J2DBench (available in openjdk's jdk repository)

This Swing benchmark is ran with different pipelines, text
anti-aliasing options (no aa, grayscale, lcd) and look and
feels (Ocean/Native/Nimbus).

As for the "real world" testing - I use Netbeans running on
the latest build as my development platforms (although I found
out that for some reason nb 6.1 disables the use of
hw accelerated pipeline by default - I'll need to get to the
bottom of this). Seems to work fine on my system - which is I
guess what most users want unless they have specific performance
issues with particular application.

It would be nice to have an automated test suite driving
applications like JEdit or Netbeans.

> 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)"?

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.

But in general, there's some information here:
http://java.sun.com/javase/6/webnotes/trouble/TSG-Desktop/html/gcrua.htm...

This Java Client troubleshooting guide is quite
useful, btw.

Thanks,
Dmitri

===========================================================================
To unsubscribe, send email to listserv@java.sun.com and include in the body
of the message "signoff JAVA2D-INTEREST". For general help, send email to
listserv@java.sun.com and include in the body of the message "help".

Dmitri Trembovetski

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 L&F 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 L&F, 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 listserv@java.sun.com and include in the body
of the message "signoff JAVA2D-INTEREST". For general help, send email to
listserv@java.sun.com and include in the body of the message "help".

kirillcool
Offline
Joined: 2004-11-17

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

Dmitri Trembovetski

Hmm. The 5.0 version doesn't work for me, it throws an
exception when trying to init the L&F:
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

java2d@JAVADESKTOP.ORG 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 listserv@java.sun.com and include in the body
> of the message "signoff JAVA2D-INTEREST". For general help, send email to
> listserv@java.sun.com and include in the body of the message "help".

===========================================================================
To unsubscribe, send email to listserv@java.sun.com and include in the body
of the message "signoff JAVA2D-INTEREST". For general help, send email to
listserv@java.sun.com and include in the body of the message "help".

kirillcool
Offline
Joined: 2004-11-17

> Hmm. The 5.0 version doesn't work for me, it
> throws an exception when trying to init the L&F:

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

Dmitri Trembovetski

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 2>&1 | 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

java2d@JAVADESKTOP.ORG wrote:
>> Hmm. The 5.0 version doesn't work for me, it
>> throws an exception when trying to init the L&F:
>
> 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 listserv@java.sun.com and include in the body
> of the message "signoff JAVA2D-INTEREST". For general help, send email to
> listserv@java.sun.com and include in the body of the message "help".

===========================================================================
To unsubscribe, send email to listserv@java.sun.com and include in the body
of the message "signoff JAVA2D-INTEREST". For general help, send email to
listserv@java.sun.com and include in the body of the message "help".

Dmitri Trembovetski

OK, success finally!

I had to add a bunch of other jar files to the
class path. Side note: I find it amusing that
substance-all.zip distribution doesn't seem to
include substance.jar

Also, isn't there some kind of way to reference the
jars you need from a single jar so you don't need to
specify them all in the class path?

I've also hacked the benchmark to check for null
menu and skip it.

Anyway, here are the results on my system (NVIDIA GF
7900GS, Pentium D 2.8Ghz, WinXP) - again the lower the
better:
d3d nod3d
Nimbus 25838 36177
Substance 59956 59349
Windows L&F 20661 24170
Ocean 16123 21659

The fact that Substance's score doesn't change a whole lot
no matter if the d3d pipeline is enabled or not suggests
that the rendering may not be the bottleneck.

One thing however I've noticed is that scrolling (text area,
table, tree) with Substance seems to be much slower (and the
benchmark does lots of that).

Thanks,
Dmitri

===========================================================================
To unsubscribe, send email to listserv@java.sun.com and include in the body
of the message "signoff JAVA2D-INTEREST". For general help, send email to
listserv@java.sun.com and include in the body of the message "help".

kirillcool
Offline
Joined: 2004-11-17

> OK, success finally!

:)

> I had to add a bunch of other jar files to the
> class path. Side note: I find it amusing that
> substance-all.zip distribution doesn't seem to
> include substance.jar

What other jars besides substance.jar did you have to add? The distribution file contains the build script, the sources and the documentation. This is by design and i don't really hear any complaints about this.

> Also, isn't there some kind of way to reference the
> jars you need from a single jar so you don't need to
> specify them all in the class path?

What jars did you have to add? substance.jar should be the only one required for an application that uses only core Swing components. If you're using SwingX, then you'd have to add substance-swingx.jar.

> I've also hacked the benchmark to check for null
> menu and skip it.

I think that it is a correct decision. Substance adds a JPanel to the menu bar, and this panel will show the menu search widget. The new default setting in 5.0 is to have the panel, but not show the widget.

> The fact that Substance's score doesn't change a
> whole lot no matter if the d3d pipeline is enabled or not
> suggests that the rendering may not be the bottleneck.

At this stage i'm quite reluctant to use VolatileImages instead of BufferedImages. I've already mentioned (in this thread) that even moving one of the caches to use VolatileImages adds 5% to the benchmark time. And Nimbus had actually worse performance on the d3d pipeline (it was twice faster than Substance on software-rendering only, but only about 20% faster on d3d pipeline).

> One thing however I've noticed is that scrolling
> (text area, table, tree) with Substance seems to be much slower
> (and the benchmark does lots of that).

I will look into this issue. Would be great, of course, to have access to your benchmark source code, but barring that - what exactly does it do? Is it driven by the Robot class (clicking in the scroll bar), is it scrolling the tables / trees programmatically with JScrollPane APIs, and what does it time? Is the main frame rendered to an offscreen image, and if not, how do you account for coalesced repaints? Or perhaps it's just counting how much time it takes to scroll the table.

Thanks
Kirill

Dmitri Trembovetski

java2d@JAVADESKTOP.ORG wrote:
>> I had to add a bunch of other jar files to the
>> class path. Side note: I find it amusing that
>> substance-all.zip distribution doesn't seem to
>> include substance.jar
>
> What other jars besides substance.jar did you have to add? The distribution file contains the build script, the sources and the documentation. This is by design and i don't really hear any complaints about this.

OK, it must be only be (well, and at least one other Java2D
team member) who got confused =)

>> Also, isn't there some kind of way to reference the
>> jars you need from a single jar so you don't need to
>> specify them all in the class path?
>
> What jars did you have to add? substance.jar should be the only one required for an application that uses only core Swing components. If you're using SwingX, then you'd have to add substance-swingx.jar.

With only swingmark.jar in the class path:
export CLASSPATH=".;c:/temp/subst50/lib/substance.jar"
java -Dswing.defaultlaf=org.jvnet.substance.skin.SubstanceAutumnLookAndFeel SwingMark

I get the following exception:
Exception in thread "AWT-EventQueue-0" java.lang.NoClassDefFoundError: org/jdesktop/beans/AbstractBean
at java.lang.ClassLoader.defineClass1(Native Method)
...
at java.lang.ClassLoader.loadClassInternal(Unknown Source)
at org.jvnet.substance.SubstanceImageCreator.getColorSchemeImage(SubstanceImageCreator.java:2846)
at org.jvnet.substance.painter.decoration.ImageWrapperDecorationPainter.getColorizedTile(ImageWrapperDecorationPainter.java:326)

And then a bunch of these:
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)

It works if I add lib/swingx.jar jar to the class path.

>> I've also hacked the benchmark to check for null
>> menu and skip it.
>
> I think that it is a correct decision. Substance adds a JPanel to the menu bar, and this panel will show the menu search widget. The new default setting in 5.0 is to have the panel, but not show the widget.

OK.

>> The fact that Substance's score doesn't change a
>> whole lot no matter if the d3d pipeline is enabled or not
>> suggests that the rendering may not be the bottleneck.
>
> At this stage i'm quite reluctant to use VolatileImages instead of BufferedImages. I've already mentioned (in this thread) that even moving one of the caches to use VolatileImages adds 5% to the benchmark time. And Nimbus had actually worse performance on the d3d pipeline (it was twice faster than Substance on software-rendering only, but only about 20% faster on d3d pipeline).

That's fine. The Windows L&F doesn't use volatile images
and is still quite fast. It does cache its rendering in
BufferedImages (which are rendered to by GDI).

I ran the benchmark with Substance L&F with trace=log
and it looks like most operations are accelerated
when the pipeline is enabled.

This again points out that the bottleneck
at least in this benchmark is not rendering since
the score doesn't change with the pipeline change.

Your benchmark (as you described it) seems to be testing
only the rendering part (you call paint to an offscreen surface)
and since it is rather short any minute variations show
huge percentage differences - these differences may
actually not be noticeable to the end user.

And this is fine if all you want to measure is rendering
performance, but from our benchmark it looks like
you need to look at the whole stack.

>> One thing however I've noticed is that scrolling
>> (text area, table, tree) with Substance seems to be much slower
>> (and the benchmark does lots of that).
>
> I will look into this issue. Would be great, of course, to have access to your benchmark source code, but barring that - what exactly does it do? Is it driven by the Robot class (clicking in the scroll bar), is it scrolling the tables / trees programmatically with JScrollPane APIs, and what does it time? Is the main frame rendered to an offscreen image, and if not, how do you account for coalesced repaints? Or perhaps it's just counting how much time it takes to scroll the table.

I will restart the discussion about open sourcing it,
or at least giving you access if you'd like that.

I'm not quite sure why we can't open it, it looks like
it was developed by our SQE and performance teams.
There were some talks about creating a new benchmark -
this one isn't perfect by any means.

The particular scrolling test seems to be rather simple -
it just calls table.scrollRectToVisible() on a large table
to simulate scrolling.

Anther test that seems to be slow is a test which adds a bunch
of lines to a text area. The tree test does something similar -
creates a large tree, selects different nodes, that kind of thing.

The test times how long does it take to complete a sequence.
The sequence may be - adding stuff to the tree, selecting
nodes, scrolling etc. Whatever rendering happens as this is being
done is included in the test - the frame is visible on the
screen all the time.

Thanks,
Dmitri

===========================================================================
To unsubscribe, send email to listserv@java.sun.com and include in the body
of the message "signoff JAVA2D-INTEREST". For general help, send email to
listserv@java.sun.com and include in the body of the message "help".

kirillcool
Offline
Joined: 2004-11-17

Hi, Dmitri

> It works if I add lib/swingx.jar jar to the class path.

That was my fault. Accidentally, one of the new classes in Substance had an unnecessary dependency on SwingX. This has been addressed and you shouldn't see this exception anymore when using substance.jar only.

> Your benchmark (as you described it) seems to be
> testing only the rendering part (you call paint to an
> offscreen surface) and since it is rather short any minute variations
> show huge percentage differences - these differences may
> actually not be noticeable to the end user.

Indeed this is correct. Currently it is only testing the rendering part.

> I will restart the discussion about open sourcing
> it, or at least giving you access if you'd like that.
> I'm not quite sure why we can't open it, it looks
> like it was developed by our SQE and performance teams.
> There were some talks about creating a new benchmark
> this one isn't perfect by any means.

That would be quite beneficial, especially if this is available to other LAF writers.

> The particular scrolling test seems to be rather
> simple - it just calls table.scrollRectToVisible() on a
> large table to simulate scrolling.
> Anther test that seems to be slow is a test which adds a bunch
> of lines to a text area. The tree test does something similar -
> creates a large tree, selects different nodes, that
> kind of thing. The test times how long does it take to complete a
> sequence. The sequence may be - adding stuff to the tree,
> selecting nodes, scrolling etc. Whatever rendering happens as
> this is being done is included in the test - the frame is visible
> on the screen all the time.

Thanks for the description. This will be the next thing to address in Substance 5, then :)
Kirill

linuxhippy
Offline
Joined: 2004-01-07

> 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

kirillcool
Offline
Joined: 2004-11-17

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

cowwoc
Offline
Joined: 2003-08-24

What I find amusing is that the integrated card yielded better performance than your NVidia card. Doesn't that sounds weird to anyone else?

Dmitri Trembovetski

java2d@JAVADESKTOP.ORG wrote:
> 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)]

That's because the d3d pipeline wasn't enabled on the integrated
chip.

I guess it would depend on the benchmark, in our internal Swing
benchmark the new pipeline is consistently faster (30-80%) than
previous release. That said, there are operations which are
indeed slower on some boards.

Thanks,
Dmitri

>
> http://forums.java.net/jive/thread.jspa?messageID=270988
>
> ===========================================================================
> To unsubscribe, send email to listserv@java.sun.com and include in the body
> of the message "signoff JAVA2D-INTEREST". For general help, send email to
> listserv@java.sun.com and include in the body of the message "help".

===========================================================================
To unsubscribe, send email to listserv@java.sun.com and include in the body
of the message "signoff JAVA2D-INTEREST". For general help, send email to
listserv@java.sun.com and include in the body of the message "help".

Phil Race

> 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:
> java2d@JAVADESKTOP.ORG wrote:
>> Hi, Dmitri
>>
>> The output of trace_level:
>>
>> [I] OS Version = OS_VISTA or newer
>> [E] D3DPPLM::CheckForBadHardware: found matching hardware:
>> VendorId=0x8086 DeviceId=0xffffffff
>> [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 listserv@java.sun.com and include in the body
of the message "signoff JAVA2D-INTEREST". For general help, send email to
listserv@java.sun.com and include in the body of the message "help".

Dmitri Trembovetski

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:
>> java2d@JAVADESKTOP.ORG wrote:
>>> Hi, Dmitri
>>>
>>> The output of trace_level:
>>>
>>> [I] OS Version = OS_VISTA or newer
>>> [E] D3DPPLM::CheckForBadHardware: found matching hardware:
>>> VendorId=0x8086 DeviceId=0xffffffff
>>> [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 listserv@java.sun.com and include in the body
> of the message "signoff JAVA2D-INTEREST". For general help, send email to
> listserv@java.sun.com and include in the body of the message "help".

===========================================================================
To unsubscribe, send email to listserv@java.sun.com and include in the body
of the message "signoff JAVA2D-INTEREST". For general help, send email to
listserv@java.sun.com and include in the body of the message "help".

kirillcool
Offline
Joined: 2004-11-17

> 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

Dmitri Trembovetski

Hi Kirill,

java2d@JAVADESKTOP.ORG 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 L&F 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 listserv@java.sun.com and include in the body
> of the message "signoff JAVA2D-INTEREST". For general help, send email to
> listserv@java.sun.com and include in the body of the message "help".

===========================================================================
To unsubscribe, send email to listserv@java.sun.com and include in the body
of the message "signoff JAVA2D-INTEREST". For general help, send email to
listserv@java.sun.com and include in the body of the message "help".

kirillcool
Offline
Joined: 2004-11-17

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 L&F 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

Dmitri Trembovetski

java2d@JAVADESKTOP.ORG 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 L&F 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 listserv@java.sun.com and include in the body
> of the message "signoff JAVA2D-INTEREST". For general help, send email to
> listserv@java.sun.com and include in the body of the message "help".

===========================================================================
To unsubscribe, send email to listserv@java.sun.com and include in the body
of the message "signoff JAVA2D-INTEREST". For general help, send email to
listserv@java.sun.com and include in the body of the message "help".

kirillcool
Offline
Joined: 2004-11-17

> 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

Dmitri Trembovetski

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

java2d@JAVADESKTOP.ORG 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 listserv@java.sun.com and include in the body
> of the message "signoff JAVA2D-INTEREST". For general help, send email to
> listserv@java.sun.com and include in the body of the message "help".

===========================================================================
To unsubscribe, send email to listserv@java.sun.com and include in the body
of the message "signoff JAVA2D-INTEREST". For general help, send email to
listserv@java.sun.com and include in the body of the message "help".

kirillcool
Offline
Joined: 2004-11-17

Will do in the evening.

Thanks
Kirill

Dmitri Trembovetski

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

java2d@JAVADESKTOP.ORG 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 listserv@java.sun.com and include in the body
> of the message "signoff JAVA2D-INTEREST". For general help, send email to
> listserv@java.sun.com and include in the body of the message "help".

===========================================================================
To unsubscribe, send email to listserv@java.sun.com and include in the body
of the message "signoff JAVA2D-INTEREST". For general help, send email to
listserv@java.sun.com and include in the body of the message "help".

kirillcool
Offline
Joined: 2004-11-17

Hi, Dmitri

The output of trace_level:

[I] OS Version = OS_VISTA or newer
[E] D3DPPLM::CheckForBadHardware: found matching hardware: VendorId=0x8086 DeviceId=0xffffffff
[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

Dmitri Trembovetski

java2d@JAVADESKTOP.ORG wrote:
> Hi, Dmitri
>
> The output of trace_level:
>
> [I] OS Version = OS_VISTA or newer
> [E] D3DPPLM::CheckForBadHardware: found matching hardware: VendorId=0x8086 DeviceId=0xffffffff
> [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 listserv@java.sun.com and include in the body
> of the message "signoff JAVA2D-INTEREST". For general help, send email to
> listserv@java.sun.com and include in the body of the message "help".

===========================================================================
To unsubscribe, send email to listserv@java.sun.com and include in the body
of the message "signoff JAVA2D-INTEREST". For general help, send email to
listserv@java.sun.com and include in the body of the message "help".

kirillcool
Offline
Joined: 2004-11-17

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

kirillcool
Offline
Joined: 2004-11-17

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

You can get the substance.jar and substance-tst.jar directly at [1]. The other three jars are part of substance-all.zip (from [1]) in the /lib folder.

[1] https://substance.dev.java.net/servlets/ProjectDocumentList?folderID=8729