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
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
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)
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):
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
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
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
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
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
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
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-
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
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
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
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
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
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
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)
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
[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,
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
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,
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
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
[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]
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
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)]
27 matches
Mail list logo
