Hi Mike,
which java release were you using?
Also, what OS?
jdk5 and jdk6 especially have better performance
over high-latency remote connections.
Thanks,
Dmitri
On Fri, Nov 03, 2006 at 04:12:04PM -0500, Nidel, Mike wrote:
We have a simple app that just has a few panels,
Hi Mike,
On Fri, Nov 03, 2006 at 05:10:03PM -0500, Nidel, Mike wrote:
Try running on 5.0 with the XAWT instead
the motif toolkit:
AWT_TOOLKIT=XToolkit java YourApp
(or you can set a -D property for the default toolkit).
I don't quite follow how I invoke my app, can i
Hi Mik,
the crash happened in hotspot (on their compiler thread), not in the
libraries, so it's hard to say what could be wrong.
Could you try your applicaion on jdk6?
Thanks,
Dmitri
On Wed, Nov 22, 2006 at 01:06:07PM +0100, Michele Puccini wrote:
Hello,
I'm getting the
Hi Anthony,
what OS is this?
[EMAIL PROTECTED] wrote:
Hi!
I am developing a game. So I need fast drawing of images. I draw images to
BufferStrategy. I have to use JDK5!
If I read an image from a jpg file, drawing it takes about 0 milliseconds. I
assume it is hardware accelerated. If I
Hello,
what application you're seeing this with?
Can you reproduce this with the jdk demos (like SwingSet2)?
Do you have any non-default flags/properties set (like any
of sun.java2d.* properties)?
Thanks,
Dmitri
Java2D Team
On Tue, Jan 16, 2007 at 01:09:51PM -0800, [EMAIL
Hello,
thanks for the info.
Could you try running your app with
1. -Dswing.bufferPerWindow=false
2. -Dsun.java2d.noddraw=true
See if any of these flags help.
Also, here's a desktop java troubleshooting guide:
I've filed this bug a while ago:
6489540: The Disposer thread could cause memory leaks in user
applications
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6489540
Unfortunately without some changes in another area
it can not be fully fixed, so I filed this bug:
6501120:
Hello,
yes, 17 seconds seems to be very excessive.
Here is a couple of suggestions:
1. instead of using raster when when creating a copy of your image,
just do a drawImage into a new BufferedImage:
shapeImageCopy =
graphicsConfig.createCompatibleImage(
Hello,
[EMAIL PROTECTED] wrote:
Thanks Chris. Is the situation similar for the DirectX pipeline on Windows (in
terms of hardware required if not performance achieved)?
The current DirectX/Direct3D pipelines have fewer restrictions on the
hardware
(since they don't use advanced features
Hello,
First, this is not the right forum to ask this - you need
to find AWT forum.
But anyway, unfortunately Java does not currently support
shaped toplevel windows. This is being planned for the next
release.
Thanks,
Dmitri
[EMAIL PROTECTED] wrote:
Hello guys,
I want to
Hi Brian,
does this happen with all java applications or
yours only?
Does resizing help?
Which java version are you running on?
Thanks,
Dmitri
Peterson, Brian J. wrote:
My client application’s graphics appear to lock up as if the EDT has
been blocked, but it isn’t – the EDT
Another way besides adjusting the acceleration threshold
via the property is to prime the images before rendering as
you're loading them.
It could be done by rendering an image to a VolatileImage until
the former becomes accelerated as reported by Image.getCapabilities()
(or until a
[EMAIL PROTECTED] wrote:
Thanks Fred. Great information.
I tried -Dsun.java2d.accthreshold=0 as you described. It works fine when I have
enabled the opengl pipeline using -Dsun.java2d.opengl=true, however if I have
the d3d pipeline enabled with -Dsun.java2d.d3d=true then I seem to loose
[EMAIL PROTECTED] wrote:
Thanks for all of the advice. You provided enough hints for me to get a
workaround that performs just as well on both the opengl and d3d pipelines.
This is what works for me:
In a static method do something like this so I have a dummy graphics lying
about for future
[EMAIL PROTECTED] wrote:
As I asked in one of my previous email, what do you think about
using acceleration priority property for this? Say, if it's
1.0 then we try to cache the image on first try. 0.0 currently means that we
won't attempt to
accelerate it and release the cached version.
Hello,
the d3d pipeline (in java6) does support bilinear filtering.
Are you creating the BufferedImages yourself like
you'd shown or using the 'new BufferedImage(w,h,type)'
constructor? If it's the former, the images will
not be managed.
Also, if you render to this image on every
[EMAIL PROTECTED] wrote:
You don't need to use webstart, do you? Can you just have them try
running SwingSet2 from the command line with -Dsun.java2d.opengl=True?
The laptop at the show has only the JRE installed, so unless I missed
something, we'd need to run the web start demo.
You can
OK, I've checked and it appears that we don't use the
DirectDraw scale loops for Bilinear filtering,
presumably because we can't control the filtering
algorithm when doing a DirectDraw stretch Blit.
The OpenGL pipeline handles it just fine, though.
As well as the upcoming Direct3D 9
) the BufferedImage to the backbuffer
I would advise against doing all this, though.
Do try using the OpenGL pipeline and let us know
if there's something wrong..
Thanks,
Dmitri
Dmitri Trembovetski wrote:
OK, I've checked and it appears that we don't use the
DirectDraw scale
Did you try the 'fbobject' property Chris suggested?
Thanks,
Dmitri
[EMAIL PROTECTED] wrote:
You can set the _JAVA_OPTIONS env variable to -Dsun.java2d.opengl=true
(or any other set of properties separated by spaces) in System
Properties/Advanced/Env.
Variables, so that all vms
[EMAIL PROTECTED] wrote:
I am trying to implement an animation in Fullscreen mode (FSEM) where the
background remains static to a large extent and only some small portion of the
display should differ from frame to frame. I can do this by drawing both the
static background image and the
And Phil already fixed the bug in the jdk7 workspace (6576507).
It will take some time for it to appear in a promoted jdk7
build, though.
Thanks,
Dmitri
[EMAIL PROTECTED] wrote:
Thanks for the suggested workaround. Works good and the text is no longer
garbled.
Kirill
[Message
Hi Ken,
first of all, rendering to the same graphics context from
multiple thread is not a good idea. Java2D does not
guarantee thread safety, and doing so could
lead to unpredictable results (and even crashes due
to bugs in our code). So, please don't do that.
As to your question
(canvasImage, 0, 0, thisW, thisH, this);
bs.show();
}
paint() should fail but it works just fine.
I don't understand how paint can drawImage if bg is disposed.
Ken
Dmitri Trembovetski wrote:
Ken Warner wrote:
Hi Dmitri,
I don't call repaint() from my code ever. I have ignoreRepaint
Hi Rob,
what java version are you using? We have made some improvements in
jdk7 so that we don't send extra requests to the server.
Although looking at the requests it appears that the top
ones might belong to AWT, not 2D - which would explain
why you didn't see any difference when
with primitives sent to the X-Server?
And, what input settings cause it to change from client to server. (The
pmoffscreen=false does help quite a bit when remoting the GUI over X.)
Thanks!
Rob
Dmitri Trembovetski wrote:
Hi Rob,
what java version are you using? We have made some improvements
Hi Rob,
Rob Ratcliff wrote:
Hi Dmitri,
Dmitri Trembovetski wrote:
But in short, you'll need to minimize the amount of
rendering which is not supported by the X protocol if
you're expecting your application to be used in remote
X situations.
It may be used remotely, but currently
at how this can be done in
j2se/src/solaris/classes/sun/awt/X11GraphicsEnvironment.java ,
see _isDisplayLocal method
(now that we're open source and all =)
Thanks,
Dmitri
Java2D Team
Dmitri Trembovetski wrote:
Hi Rob,
Rob Ratcliff wrote:
Hi Dmitri,
Dmitri Trembovetski wrote
Hi Taras,
[EMAIL PROTECTED] wrote:
Dmitry,
I have tried enabling Java2D DirectDraw pipeline. Results were a mixed bag - in
some cases it seems to help, in other cases not at all.
OK.
Not really relevant to the discussion, but one thing is that
with the hw acceleration
Hi Taras,
I believe I explained the cause in my other message (attached).
To sum it up, copying large image from system memory to the
screen using our GDI blit loops can be slow in some cases
depending on the dimensions of the image.
Thanks,
Dmitri
[EMAIL PROTECTED] wrote:
[EMAIL PROTECTED] wrote:
Ok, but it seems that regular scrolling is very fast.
So I'm wondering why it only affects mousewheel scrolling.
Ah! I missed that bit somehow.
lameI'm trying to reproduce this now. How do I make Intellij
to use jdk6?/lame
Dmitri
[Message sent by forum
Hi Rob,
Rob Ratcliff wrote:
Dmitri Trembovetski wrote:
In the local server case, have you tried setting
this env. variable: J2D_PIXMAPS=shared . It may help.
Oddly enough, when we use shared, the X-Server load goes up quite a
bit (on the order of 30-50%), whereas when we use server
Hi Oliver,
looks like a problem with Swing's handling of COM stuff
(I've cc-ed responsible swing engineer). What exact java
version is this?
Thanks,
Dmitri
Olivier Lefevre wrote:
Upon closing a perfectly ordinary program (a test JTable within
a scrollpane) running under Java 6
Hello,
Sun had released an Early Access of 6uN (formerly known as
the Consumer Release). You can get build b04 here:
http://download.java.net/jdk6/
This build contains the new Direct3D 9-based Java2D pipeline,
which is enabled by default on Windows platform. It is very similar to
Thanks, Roger.
Yes, this is a known problem with the 945G chipset:
6612195: D3d: Netbeans editor is completely unusable with JDK 6uN [Intel
945G]
You'll have to use the workaround for now, unfortunately.
Thank you,
Dmitri
[EMAIL PROTECTED] wrote:
Hi Dmitri,
I've just
value? This goes back to an earlier discussion I had
with you about the possibility of being able to set the JVM arguments to
programmatically from an applet.
Here is the memory help page I have available to the users that users
seem to want to avoid.
http://pancyl.com/memoryhelp.htm
Ken
Dmitri
Good to hear!
Dmitri
[EMAIL PROTECTED] wrote:
Works smoothly on this Dell Latitude D620 with Vista Ultimate so far.
In fact, it works better - the JTable headers are now much more compact and
elegant compare to JavaSE6u2 (esp with the sorting icon!) :)
[Message sent by forum member
Hi Sebastian,
It is true that some operations may become slower.
Mostly it is when software and hardware rendering
are mixed togeter. In your case it is likely that you are
causing reading from video memory to system memory,
which is very slow.
But to verify this and may be
Hi Richard,
thank you for the report.
[EMAIL PROTECTED] wrote:
I tried the new Update N with one of my Java applets and the framerate has
degraded markedly.
Does your applet render directly to the screen?
Do you use any kind of back-buffer? If so, is it a
VolatileImage or a
Hi Martin,
Thanks a lot for the detailed report.
There are two issues here:
- some images loaded with Toolkit.getImage() (at least, pngs) aren't
accelerated - this had been addressed in jdk7 but not in 6uN.
I'll file a bug on this one.
- for some unaccelerated images
Hello,
Just an update..
Dmitri Trembovetski wrote:
Hi Martin,
Thanks a lot for the detailed report.
There are two issues here:
- some images loaded with Toolkit.getImage() (at least, pngs) aren't
accelerated - this had been addressed in jdk7 but not in 6uN.
I'll
Hi Ken,
it should have been installed. However, there were some issues with that
build, see
http://forums.java.net/jive/thread.jspa?threadID=31404tstart=0
Thanks,
Dmitri
Ken Warner wrote:
Hi,
I downloaded jre-6u5-ea-bin-b04-windows-i586-27_sep_2007.jar to try D3D
Hi Bill,
yes, this question is more related to Swing/awt. You will
have better luck here:
http://forums.java.net/jive/forum.jspa?forumID=74start=0
Thanks,
Dmitri
Bill Dodson wrote:
I am not sure this is the place for this question, but I couldn't seem
to find a swing list.
In
Hi Dick,
thanks for the info.
[EMAIL PROTECTED] wrote:
I tried the release and had got all kind of paint-related problems in my java
xmleditor. They did occur especially with bigger files A few examples:
- My textpane is not painted correctly: when I drag with my mouse over the text
I
Chris pointed out that this is on Sparc, so no
nice nvidia/ati boards there, but I agree that
you could first try to tune your application
with the default pipeline - it may just perform
well enough.
There's some information about the pipeline
properties here:
Yes, performance was the main consideration. We want
objects to be disposed of as quickly as possible.
Also, if the main issue is 'resurrecting' the object
after taking it off the queue it's not a problem
for the Disposer: we don't do that as all data
which needs disposal is kept in
Hi James,
yes, the d3d pipeline is disabled on Windows 2003,
and starting with build 08 on any server-class OS
(for example Windows Server 2008).
The reason is that typically people don't care about
graphics performance on a server, and also drivers
tend to be old/buggy on servers
[EMAIL PROTECTED] wrote:
processing in software could benefit from porting
their operations to
the GPU -- regardless of whether those pixels are
going straight to the
display or coming back out of VRAM to be written to a
file.
Yes I know gpgpu and yes I've already on such a project, I also
It would be interesting to find out what was causing
the freeze. Would it be possible to create a small
test case reproducing the issue?
Or if you could just show a piece of code which
was using VolatileImages?
Thanks,
Dmitri
Java2D Team
[EMAIL PROTECTED] wrote:
Excellent
Hi,
[EMAIL PROTECTED] wrote:
Hi Dmitri,
The freeze was actually being caused by a concurrency issue which curiously
only showed up using VolatileImage. So I am glad I tried it because I wouldn't
have seen the problem otherwise.
Now, having got VolatileImage to work, I find that working
I think you might want to ask this on javagaming.org, in
the jinput forum:
http://www.javagaming.org/forums/index.php?board=27.0
Thanks,
Dmitri
Ken Warner wrote:
It would be a neat thing to be able to pan/tilt/zoom with one device.
[EMAIL PROTECTED] wrote:
Hi Dmitri,
First of all, did you determine (by profiling and
such) that it is expensive or is this your gut feeling? It is
important to work with correct data, and sometimes our
assumptions about performance implications may be
incorrect (I get this stuff wrong
First of all, FYI, b07 is out. It has a couple of
important fixes - it significantly improves performance
of Netbeans (and other applications which use
LCD and grayscale AA text simultaneously) and addresses
issues on Intel chips.
Ken Warner wrote:
I have an NVida GeForce2
FYI for those on the list: for some reason only one in
three messages posted on the forum get to the list
which is why some of the posts look kind of out of place.
Dmitri
[EMAIL PROTECTED] wrote:
Woow. Just reproduced it with Substance LF demo. Just click the List tab on
the left.
Just in case this hadn't been replied to:
yes, we'd seen this behavior on certain video boards
only on Vista with Aero enabled.
I'm pretty sure this is a Vista bug, but we'll
try to work around it.
Thanks,
Dmitri
[EMAIL PROTECTED] wrote:
Hello,
I've been playing a few hours
Thanks a lot, Clemens, for looking into this!
Dmitri
[EMAIL PROTECTED] wrote:
Clemens, you were right... I am ashamed. I thought I
was cleaning
that reference, while I was actually not. I guess I
over-sought this
possibility simply because everything was working
fine with OSXImage
.
Thank you,
Dmitri
Dmitri Trembovetski wrote:
Just in case this hadn't been replied to:
yes, we'd seen this behavior on certain video boards
only on Vista with Aero enabled.
I'm pretty sure this is a Vista bug, but we'll
try to work around it.
Thanks,
Dmitri
[EMAIL
[EMAIL PROTECTED] wrote:
Unfortunately you will not be able to force it
using -Dsun.java2d.d3d=true .
Couldn't this be changed at least for the operating-system checks?
If someone specifies d3d he really wants D3D enabled, otherwise he/she would
not specify it, or
How about this then?
http://java.sun.com/javase/6/docs/api/java/awt/image/VolatileImage.html
Thanks,
Dmitri
[EMAIL PROTECTED] wrote:
Ken, unfortunately I cannot use BufferStrategy because I need to manipulate
sub-images of a VI. I can't see how that's possible with
And as for multiple volatile images you'll have to
validate each image separately, and loop until
all of them are not lost.
That's a bit of a pain, sorry.
Thanks,
Dmitri
Dmitri Trembovetski wrote:
How about this then?
http://java.sun.com/javase/6/docs/api/java/awt/image
HOW DID THEY DO THAT??? Is this another secret environment variable?
I would like to know how to go into fullscreen mode without the status
bar showing.
I think they may be exploiting a bug fixed in the latest
versions.
On my jre (6uN) the window does show the warning.
Thanks,
Hi Mark,
I recall that Alex did something like this on his blog:
http://weblogs.java.net/blog/alexfromsun/
I think this is the one:
http://weblogs.java.net/blog/alexfromsun/archive/2006/07/jxtransformer_t.html
Thanks,
Dmitri
Mark Stephens wrote:
I am trying to get some
Hi Jim,
could you take a look at this one if you have a sec:
http://www.javagaming.org/forums/index.php?topic=17925.0
It'll take me much longer than you to explain the
guy what's going on..
Thanks,
Dmitri
And that is why reply to sender only w/o looking
at who you're replying to is not smart =)
Dmitri
Dmitri Trembovetski wrote:
Hi Jim,
could you take a look at this one if you have a sec:
http://www.javagaming.org/forums/index.php?topic=17925.0
It'll take me much longer than
[EMAIL PROTECTED] wrote:
[quote]
I have a FX5200 board here and it doesn't have an of these issues.
It's not the fastest board around, for sure, but I haven't seen
rendering artifacts you're describing.
[/quote]
Well it does not show artifacts - it works as intended but sometimes too slow.
So
Hi Michele,
[EMAIL PROTECTED] wrote:
I'll try the new driver tomorrow.
Any luck? We're a bit pressed for time here, I'd like
to put the fix in today if possible (it's
either today or on January) and for that
I need a confirmation that the new driver
helped..
Thanks,
Dmitri
Thanks, Richard, for submitting this.
[EMAIL PROTECTED] wrote:
Reposted from http://weblogs.java.net/blog/chet/archive/2006/10/java_on_vista_y.html on
Dmitri's suggestion...
So here's an interesting problem, related to - if not directly caused by - Java on Vista.
Brand new machine
[EMAIL PROTECTED] wrote:
Moments after I posted this, the symptom occurred. (Machine simply powers off. No BSOD,
no warning, just off. Like the power cord had been pulled on a desktop. Only
this is a notebook with a fully charged battery plugged in to a UPS. ;-)
I am now starting to
Hi,
I don't quite understand the question. Why couldn't you just
render all your images (the sysmem ones, which I assume are
BufferedImages) and the vram-based ones (VolatileImages or
cached BufferedImages?) to your back-buffer (which resides in
vram)?
Whatever order you draw them
Hi,
thank you for your report.
There's some kind of problem with the initialization
of the new Direct3D pipeline (and it tries over and over)
according to the log.
I take it that it continues to spill the
same output over and over when the application is running,
right?
[I]
OK, I have tried it on my system (XP with Nvidia 7900)
and it worked fine - I get consistent 60fps
(it's display refresh bound at 60hz), it switches between
fs and windowed mode.
We have a 6600 board in our lab, I'll try it there
as well.
Thanks,
Dmitri
[EMAIL PROTECTED] wrote:
I get consistent 60fps
(it's display refresh bound at 60hz)
Is V-Sync new to 6uN? Because, as I stated earlier, I get ~200 frames using
6u1, and my display certainly doesn't draw that quick.
Yes. It's v-sync-ed in fullscreen mode.
This would (could?) explain
[EMAIL PROTECTED] wrote:
Ah, nice to hear it's all working! Is there any way to manage v-sync from
within Java, and if not, are there any plans to add such a feature?
Enabling v-sync in windowed mode could save performance as those extra frames
aren't all that useful anyways, and some may want
Hi Pepe,
it is useful but this issue is kind of known.
One always had to disable ddraw to use opengl.
Thanks,
Dmitri
[EMAIL PROTECTED] wrote:
No one, really?
If my report is not useful, please at least tell me so, i'll provide anything
needed (except the machine itself or
Take a look at this preso if you haven't already:
http://gceclub.sun.com.cn/java_one_online/2005/TS-3214/ts-3214.pdf
Slides 42-43.
And, of course:
http://java.sun.com/docs/books/tutorial/2d/text/textattributes.html
Dmitri
[EMAIL PROTECTED] wrote:
I see that the font attribute
I have tried on my 32-bit Vista (with 6u10 b08) and it worked
fine..
Thanks,
Dmitri
[EMAIL PROTECTED] wrote:
Hi Phil,
The Vista machine is 64-bit and the XP machine is 32-bit so perhaps that has
something to do with it.
Anyway, I have emailed you screen shots of the problem so you
Hello,
just curious, why would you want to draw translucent images
directly to the screen?
Drawing translucent images to an opaque window sounds
strange to me. Wouldn't you get artifacts with partial
repaints and stuff? If you do clear the window before
rendering your image, then
And my previous statement that it works on Vista 32-bit
was incorrect..
Thanks,
Dmitri
Phil Race wrote:
Its been a couple of weeks but yesterday finally looked into this.
The problem is indeed specific to the version of the font on Vista
and so affects 32 and 64 bit.
When Microsoft
Hello,
[EMAIL PROTECTED] wrote:
Another questions is which java version have you
tried?
Have you tried 6uN (dev. builds available at
http://jdk6.dev.java.net)
I'm only using the standard Java 6 JRE from Sun. I'd very much like not to
depend on non-standard Java distributions, since I'd
Why don't you use a translucent BufferedImage?
You can use BufferedImage.TYPE_INT_ARGB as the bi type
when creating it.
Thanks,
Dmitri
[EMAIL PROTECTED] wrote:
I want to display a curve in J3D without having to draw a zillion line segments
and I'm not too concerned about display
[EMAIL PROTECTED] wrote:
OK, but...when I make the host quad transparent, the texture disappears too.
I'm using Mode DECAL.
I think I still need some more hints. What specifies the transparent color of
the image?
Note that I'm talking about using a TRANSLUCENT image,
not BITMASK (see
Unfortunately there's no way to tell for sure if a particular
operation is accelerated. There's an RFE for providing an api
for discovering capabilities, but it won't be implemented until
java 7.
Thanks,
Dmitri
[EMAIL PROTECTED] wrote:
How do I detect when a feature such as
Hi Horia,
yes, this is a known limitation of the current
Direct3D pipelne:
6635462: D3D: XOR rendering is extremly slow
http://bugs.sun.com/view_bug.do?bug_id=6635462
Does it work ok otherwise if this drag mode
is not enabled on your system?
Thanks,
Dmitri
[EMAIL
like in your app
but if you can find a way to do it differently it'd
be helpful. Unfortunately the bug with unaccelerated
xor ops isn't easy to fix.
Thanks,
Dmitri
Dmitri Trembovetski wrote:
I could not reproduce the issue on my system (XP
with Nvidia 6800 board).
What is your
[EMAIL PROTECTED] wrote:
here is my 2D.log
[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
Ken Warner wrote:
I hope MemoryImageSource is not going to be depricated!!!
I use it big time in all my applets.
What would be the replacement for MemoryImageSource? I hope
you aren't thinking that BufferedImage is better. BufferedImage
is a giant, poorly thought out hairball...
Here we
I only see a bunch of small collections (I tried on
6u10) - probably because for each pixel you set an
int[1] array is created.
I don't see the heap growing. Run it with -verbose:gc ,
see what it says.
If you want to try the approach Clemens suggested, you'll
only need to change
Phil Race wrote:
The first line is LCD text, the second line is greyscale.
The problem is that we do not have loops - in either software
or hardware, that work for LCD text with the composite you have specified.
There's an open bug on this: 6274808.
Note that this bug mentions that complex
Hi Peter,
yes, currently the D3D pipeline is disabled on all Intel
adapters. You would only want to enable it on the latest
adapters anyway (G965, or X3xxx family) since earlier
ones (915) don't have hw transforms and lighting anyway
which means they're very slow.
The G965 are OK
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
[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]
Hi,
which 6u10 build are you running? We have made some
optimizations in I believe b23 (which isn't out yet)
which may help this case.
Also, what's your video board? Could you
please set J2D_TRACE_LEVEL=4 env. variable,
then run your app and post the output.
Could you post a
cause
more work to be needed, but it seemed likely you were hitting
the first case.
-phil.
Dmitri Trembovetski wrote:
[EMAIL PROTECTED] wrote:
Hi, Dmitri
The output of trace_level:
[I] OS Version = OS_VISTA or newer
[E] D3DPPLM::CheckForBadHardware: found matching hardware:
VendorId=0x8086
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)
[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,
Thanks for the test and the data. I'll file a bug (if there isn't already -
I vaguely recall having filed something like this).
There may be a way to speed up BufferedImage - accelerated
surface copies.
Thanks,
Dmitri
[EMAIL PROTECTED] wrote:
I'm using the latest one which is
A colleague pointed out that you're rendering
directly to the screen (frame.getGraphcis()...), which
is a no-no in a swing application. The performance issue
is not related to this, but just FYI, you don't want to
do that.
Dmitri
Dmitri Trembovetski wrote:
Thanks for the test
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-
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
[EMAIL PROTECTED] wrote:
I saw the bug report, and it seems the solution has yet to be found , but i
believe a solution is still being worked on judging by the log messages.
Correct.
So I assume that there is no workaround , and probaly I'm better off with j6u5
for the time being and
101 - 200 of 307 matches
Mail list logo
