from:"Dmitri Trembovetski"


[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 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 started on this system will pick it up.

  Thanks,
Dmitri





(No, there's no alternate JNLP available...)


might be good to have an openGL pipeline-enabled set of demos as well.  :-)



That driver is a bit out of date; there are newer ones on their website
[1] that should be tried in order to determine whether the problem
till exists.  Nvidia wouldn't be likely to fix the problem until we can
prove that it's still reproducible in their latest drivers.


I won't be able to arrange a driver update at the show - I'd probably be 
executed at dawn if not earlier.   ;-)

Seems like I need to remove the opengl pipeline setting from our app in order 
to avoid this issue.
[Message sent by forum member 'russelleast' (russelleast)]

http://forums.java.net/jive/thread.jspa?messageID=223157

===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.


===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.

Re: [JAVA2D] D3D pipeline and scaling


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

  Thanks,
Dmitri


[EMAIL PROTECTED] wrote:

Thanks for the reply. I've tried using the Volatile Images (which seems to be 
the right approach as suggested by you and also in previous posts). However, 
the scaling the backbuffer is for some reason painfully slow. It takes 4 
seconds for a frame, instead of the 40ms with software based scaling. The 
following short snipped reproduces the problem (justs scales a red square):

private static JFrame frame;
private static JPanel panel;
private static VolatileImage dummyImage;
private static Graphics dummyGraphics;

public static void main(String[] args) throws InterruptedException {
frame = new JFrame(...);
frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
panel = new JPanel() {
public void paintComponent(Graphics g) {
if (dummyImage != null) {
dummyGraphics.setColor(Color.RED);
dummyGraphics.fillRect(700, 350, 100, 100);

((Graphics2D) 
g).setRenderingHint(RenderingHints.KEY_INTERPOLATION, 
RenderingHints.VALUE_INTERPOLATION_BILINEAR);
long s = System.nanoTime();
g.drawImage(dummyImage, 0, 0, 1600, 900, 0, 0, 
800, 450, null);
System.out.println((System.nanoTime() - s) / 
100);

System.out.println(dummyImage.getCapabilities().isAccelerated() +   + 
((Graphics2D) g).getDeviceConfiguration().getImageCapabilities().isAccelerated());
}
}
};
frame.add(panel);
frame.setSize(1700, 1000);

GraphicsEnvironment ge = 
GraphicsEnvironment.getLocalGraphicsEnvironment();
GraphicsConfiguration gc = 
ge.getDefaultScreenDevice().getDefaultConfiguration();
dummyImage = gc.createCompatibleVolatileImage(800, 450, 
Transparency.OPAQUE);
dummyGraphics = dummyImage.getGraphics();
System.out.println(dummyImage.validate(gc));
System.out.println(dummyImage.validate(gc));

frame.setVisible(true);

Thread.sleep(4000);
for (int i = 0; i  1000; i++) {
Thread.sleep(100);
frame.repaint();
}
}

The console output is:

Direct3D pipeline enabled on screen 0
1
0
4120
true true
4113
true true
4112
true true
3 calls to sun.java2d.windows.DDBlitLoops::Blit(Integer RGB DirectDraw, SrcNoEa, 
Integer RGB DirectDraw)
10 calls to D3DFillRect
3 calls to sun.java2d.loops.TransformHelper::TransformHelper(IntRgb, SrcNoEa, 
IntArgbPre)
16 total calls to 3 different primitives

The VM params are:

 -Dsun.java2d.d3d=True -Dsun.java2d.ddscale=true -Dsun.java2d.trace=count

It is the same result with the two PCs mentioned in the previous post. Only way 
I can think of that it gets that slow is that the images are kept in the video 
buffer but for some reason scaling is still done in software. Any ideas of what 
is wrong? Am I missing something?

Thanks, Remo
[Message sent by forum member 'remmeier' (remmeier)]

http://forums.java.net/jive/thread.jspa?messageID=223021

===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.


===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.

Re: [JAVA2D] D3D pipeline and scaling


  But if you're really set on using the d3d pipeline,
  here's another alternative, which may only work
  on jdk6 and earlier releases.
   1. set -Dsun.java2d.allowrastersteal=true
  set -Dsun.java2d.accthreshold=0
  set -Dsun.java2d.d3d=true (or for earlier
  releases, -Dsun.java2d.translaccel=true)
   2. modify your BufferedImage's raster directly
  as you were doing before with new data, but
  after each frame do a 1x1 fillRect() with
  translucent color to that buffered image
  to let us know that we need to update the
  cached version
   3. copy (stretch) 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 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 -based pipeline.

  Thanks,
Dmitri


[EMAIL PROTECTED] wrote:

Thanks for the reply. I've tried using the Volatile Images (which
seems to be the right approach as suggested by you and also in
previous posts). However, the scaling the backbuffer is for some
reason painfully slow. It takes 4 seconds for a frame, instead of the
40ms with software based scaling. The following short snipped
reproduces the problem (justs scales a red square):

private static JFrame frame;
private static JPanel panel;
private static VolatileImage dummyImage;
private static Graphics dummyGraphics;

public static void main(String[] args) throws InterruptedException {
frame = new JFrame(...);
frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
panel = new JPanel() {
public void paintComponent(Graphics g) {
if (dummyImage != null) {
dummyGraphics.setColor(Color.RED);
dummyGraphics.fillRect(700, 350, 100,
100);

((Graphics2D)
g).setRenderingHint(RenderingHints.KEY_INTERPOLATION,
RenderingHints.VALUE_INTERPOLATION_BILINEAR);
long s = System.nanoTime();
g.drawImage(dummyImage, 0, 0, 1600,
900, 0, 0, 800, 450, null);
System.out.println((System.nanoTime()
- s) / 100);

System.out.println(dummyImage.getCapabilities().isAccelerated() +  
+ ((Graphics2D)
g).getDeviceConfiguration().getImageCapabilities().isAccelerated());
}
}
};
frame.add(panel);
frame.setSize(1700, 1000);

GraphicsEnvironment ge =
GraphicsEnvironment.getLocalGraphicsEnvironment();
GraphicsConfiguration gc =
ge.getDefaultScreenDevice().getDefaultConfiguration();
dummyImage = gc.createCompatibleVolatileImage(800, 450,
Transparency.OPAQUE);
dummyGraphics = dummyImage.getGraphics();
System.out.println(dummyImage.validate(gc));
System.out.println(dummyImage.validate(gc));

frame.setVisible(true);

Thread.sleep(4000);
for (int i = 0; i  1000; i++) {
Thread.sleep(100);
frame.repaint();
}
}

The console output is:

Direct3D pipeline enabled on screen 0
1
0
4120
true true
4113
true true
4112
true true
3 calls to sun.java2d.windows.DDBlitLoops::Blit(Integer RGB
DirectDraw, SrcNoEa, Integer RGB DirectDraw)
10 calls to D3DFillRect
3 calls to sun.java2d.loops.TransformHelper::TransformHelper(IntRgb,
SrcNoEa, IntArgbPre)
16 total calls to 3 different primitives

The VM params are:

 -Dsun.java2d.d3d=True -Dsun.java2d.ddscale=true -Dsun.java2d.trace=count

It is the same result with the two PCs mentioned in the previous post.
Only way I can think of that it gets that slow is that the images are
kept in the video buffer but for some reason scaling is still done in
software. Any ideas of what is wrong? Am I missing something?

Thanks, Remo
[Message sent by forum member 'remmeier' (remmeier)]

http://forums.java.net/jive/thread.jspa?messageID=223021

===

To unsubscribe, send email to [EMAIL PROTECTED] and include in the
body
of the message signoff JAVA2D-INTEREST.  For general help, send
email to
[EMAIL PROTECTED] and include in the body of the message help.


===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.


===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body

Re: [JAVA2D] openGL pipeline causing garbled display on Dell M90


  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 started on this system will pick it up.


Thanks Dimitri.
With that, I can confirm that the SwingSet2 demo also fails in the same way - 
garbled window contents.
[Message sent by forum member 'russelleast' (russelleast)]

http://forums.java.net/jive/thread.jspa?messageID=223180

===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.


===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.

Re: [JAVA2D] drawing on only part of display in fullscreen mode with double buffering?

2007-06-23 Thread Dmitri Trembovetski


[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 animating foreground image to the back buffer 
and then display it using BufferStrategy.show():

Suppose the background image is bg (a BufferedImage) and suppose that the small 
part that changes during the animation is stored in another image fg. For 
simplicity suppose that the screen position where fg is drawn does not change 
in successive frames. I can implement this as follows:

public void animate(){
  if (getBufferStrategy().contentsLost())
  createBufferStrategy(2);
  Graphics2D g = (Graphics2D) getBufferStrategy().getDrawGraphics();
  g.drawImage(bg,x1,y1,null);   // x1,y1,bg never change
  g.drawImage(fg,x2,y2,null);// x2,y2 constant, only fg changes
  getBufferStrategy().show();
}


  First of all, your buffer strategy handling is not
  entirely correct. You are not supposed to recreate
  the buffer strategy when it's lost, it's taken
  care for you.
  Take a look at the suggested loop in the BS's
  javadoc (updated for jdk1.6):

   http://java.sun.com/javase/6/docs/api/java/awt/image/BufferStrategy.html

  Regarding your question
  Unfortunately the buffer strategy api does not provide
  partial front-buffer updates. However, if the strategy is hw
  accelerated the showing of the back-buffer is very
  fast. Most games don't bother with partial updates,
  they re-render the whole back-buffer every time.

  If you're concerned with re-rendering the whole back-buffer
  on every frame, you can also create
  a bufferstrategy with FlipContents.COPY capability.
  It will ensure that the contents of the back-buffer
  do not change after you do the show(), so you
  can only re-render stuff you need in the back-buffer,
  and then show() it (all).

  However, before going to all these troubles, make
  sure there's actually an issue - profile the application
  and see what really takes time.

  Thanks,
Dmitri





But I am a bit concerned with this approach. Because this implementation has to 
blit/flip the entire back buffer to front even though most part is actually 
never changing. I am wondering if there is a better way of doing this. For 
example, is there a way to blit/flip only a portion of the front buffer? Or is 
this actually taken care of by the BufferStrategy behind the scene?
[Message sent by forum member 'boyaci' (boyaci)]

http://forums.java.net/jive/thread.jspa?messageID=223663

===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.


===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.

Re: [JAVA2D] Bug in rendering text under JDK 6.0

2007-07-04 Thread Dmitri Trembovetski


  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 sent by forum member 'kirillcool' (kirillcool)]

http://forums.java.net/jive/thread.jspa?messageID=225149

===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.


===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.

Re: [JAVA2D] Question about recommended render loop for BufferStrategy...

2007-07-09 Thread Dmitri Trembovetski


  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 why it works - you just got
  lucky and the paint on EDT executed while another
  thread was in between the getDrawGraphics() and dispose().

  After the dispose() all rendering operations to a
  graphics context become no-ops, so by definition you
  would only see something rendered the paint event
  happened to be while the graphics was still valid.

  Thank you,
Dmitri
  Java2D Team


Ken Warner wrote:

According to the documentation on:
http://java.sun.com/javase/6/docs/api/java/awt/image/BufferStrategy.html

One is supposed to
do {
   Graphics graphics = strategy.getDrawGraphics();
   //render here
   graphics.dispose();
} while (strategy.contentsRestored());

So I did that where I render:
do {
   do {
 bg = (Graphics2D)bs.getDrawGraphics();
 mis.newPixels(pixels, cm, 0, thisW);
 bg.drawImage(canvasImage, 0, 0, thisW, thisH, this);
 drawAttribution();
 bg.dispose();
} while (bs.contentsRestored());
bs.show();
} while (bs.contentsLost());

So I'm disposing of bg -- the BufferStrategy graphics after I render.

The question is -- how come I can still use the buffer graphics (bg)
at other times to draw stuff.  My applet draws onto the BufferStrategy (bs)
in many other places at various times.  And it works and all the while
I have dispose()'ed of the buffergraphics (bg) and the loop above is the
only
place I getDrawGraphics();

For example -- here's my paint() method -- no problem -- no drawGraphics.

public void paint(Graphics g)
{
   //System.err.println(paint());
   bg.drawImage(canvasImage, 0, 0, thisW, thisH, this);
   if(DRAWATT)
   drawAttribution();
   bs.show();
}

I don't understand that...

Ken

===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.


===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.

Re: [JAVA2D] Question about recommended render loop for BufferStrategy...

2007-07-11 Thread Dmitri Trembovetski


  If you can put together a complete test which shows
  that you can render to a Graphics object after it's
  been disposed (and stuff shows up in the destination),
  that would be a bug.

  If you can, please send the test over. Otherwise it
  is hard to tell what could be wrong.

  Thanks,
Dmitri


Ken Warner wrote:

Ken Warner wrote:

According to the documentation on:
http://java.sun.com/javase/6/docs/api/java/awt/image/BufferStrategy.html


One is supposed to
do {
   Graphics graphics = strategy.getDrawGraphics();
   //render here
   graphics.dispose();
} while (strategy.contentsRestored());

So I did that where I render:
do {
   do {
 bg = (Graphics2D)bs.getDrawGraphics();
 mis.newPixels(pixels, cm, 0, thisW);  //MemoryImageSource
 bg.drawImage(canvasImage, 0, 0, thisW, thisH, this);
 bg.dispose();
} while (bs.contentsRestored());
bs.show();
} while (bs.contentsLost());

So I'm disposing of bg -- the BufferStrategy graphics after I render.

The question is --

how come I can still use the buffer graphics (bg)
at other times to draw stuff.

My applet draws onto the BufferStrategy (bs) in many other places at
various times.  And it works after I have dispose()'ed of the
buffergraphics (bg) and the loop above is the only place I
getDrawGraphics();

For example -- here's my paint() method -- no problem -- no drawGraphics.

public void paint(Graphics g)
{
   //System.err.println(paint());
   bg.drawImage(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() set for

the Canvas component.  paint() is only called from the AWT eventloop on
expose and events like that -- do I understand that right?

The loop below is called from my own looping thread when I get some

newPixels for my MemoryImageSource.  I have not seen any problems.

But I know that my applet is not accelerated on my machine.  It only

has unaccelerated bitblt from the BufferStrategy.  I can't test
real acceleration.  My machine is too old.

What I'm trying to say -- clumsily -- is that I believe that only one

thread at a time could render to my buffer -- I think...



  OK.. Then what's the question, again? I'm sorry, I'm just
  not following.

  Thanks,
Dmitri



Ken
Dmitri Trembovetski wrote:

  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 why it works - you just got

  lucky and the paint on EDT executed while another
  thread was in between the getDrawGraphics() and dispose().

  After the dispose() all rendering operations to a

  graphics context become no-ops, so by definition you
  would only see something rendered the paint event
  happened to be while the graphics was still valid.

  Thank you,

Dmitri
  Java2D Team


===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.


===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.

Re: [JAVA2D] Trouble Shooting High X-Server Load on Solaris

2007-09-17 Thread Dmitri Trembovetski


  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 trying the Java2D
  flags.

  Thanks,
Dmitri


Rob Ratcliff wrote:

Hi,

I'm troubleshooting a fairly large application built on top of the NetBeans 6 
platform that is causing the X-Server to chew up up a lot (30%-50%) CPU when 
all it seems to be doing is refreshing a blank (no data) Map (we're using 
Openmap) once a second. (I'm going verify that this week and ensure the entire 
app isn't getting repainted or revalidated once a second or more.) It is 
running locally and I'm running it with the -J-Dsun.java2d.pmoffscreen=true. 
(I've tried false as well.) The Java process is only taking 5% or so compared 
to the X-Server load.

In comparison, a similar application (uses OpenMap, but not built on NetBeans) 
we have uses only 2-5% total CPU with the map populated and updating more than 
once a second.

I've tried all the flags documented in the Java2D whitepaper 
(http://java.sun.com/products/java-media/2D/perf_graphics.html), but I haven't 
been as fortunate this time for a quick fix. (I did use the -J option to pass 
the VM option through the NetBeans exec to the VM.)

(BTW, this is a Sun Blade 2000 UltraSparc III+ with a GFX-450 Graphics card, 
running Solaris 8. It has 4 GB of memory and I significantly increased the 
shared memory segments from the defaults.)

To get some insight into what was going on, I used the X-Server proxy, xmon, to 
monitor the X-Event traffic to see what was going on and noticed that there 
seems to be a lot of X-Event traffic. I was expecting more bitmap type 
operations where the Swing's buffered image would be sent to the local X-Server 
rather than the nearly 2000 primitive draws per minute. It is almost as if 
Swing isn't double buffering.

I've also tried using the  -J-Dsun.java2d.trace=optionname,optionname to 
get a log of the messages, but nothing was printed. (I've tried it on Java 5 and 6.) Does 
that work on the newer versions of the VM. (I need to run a test as well outside of the 
NetBeans app to see if the NetBeans platform is intercepting it somewhere.)

Does anybody have some suggestions on what might be going on?

Thanks!

Rob

--xmon 
summary-

requests received (for about 1 minute):
code  count  name
  1 9CreateWindow
  229ChangeWindowAttributes
  3 4GetWindowAttributes
  4 4DestroyWindow
  8 6MapWindow
 10 1UnmapWindow
 1220ConfigureWindow
 14 4GetGeometry
 15 4QueryTree
 1683InternAtom
 17 1GetAtomName
 18   129ChangeProperty
 1911DeleteProperty
 20   326GetProperty
 23 2GetSelectionOwner
 24   317ConvertSelection
 25 4SendEvent
 36 1GrabServer
 37 1UngrabServer
 40 2TranslateCoordinates
 42 7SetInputFocus
 43   615GetInputFocus
 4519OpenFont
 46 2CloseFont
 4718QueryFont
 5351CreatePixmap
 5436FreePixmap
 5581CreateGC
 56   2979ChangeGC
 59   2027SetClipRectangles
 6048FreeGC
 61 2ClearArea
 62   497CopyArea
 66   1605PolySegment
 67   246PolyRectangle
 69 3FillPoly
 70   1615PolyFillRectangle
 72   490PutImage
 73 8GetImage
 78 2CreateColormap
 8436AllocColor
 9317CreateCursor
 94 2CreateGlyphCursor
 9728QueryBestSize
 98 8QueryExtension
101 1GetKeyboardMapping
117 1GetPointerMapping
119 2GetModifierMapping
events received (for about 1 minute):
code  count name:
  681MotionNotify
  7 8EnterNotify
  8 8LeaveNotify
  911FocusIn
 1012FocusOut
 1211Expose
 17 1DestroyNotify
 18 1UnmapNotify
 19 2MapNotify
 21 2ReparentNotify
 2213ConfigureNotify
 28   783PropertyNotify
 31   319SelectionNotify
 33 5ClientMessage
errors received:
code  count  name
 10 1Access

===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.


===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.

Re: [JAVA2D] Trouble Shooting High X-Server Load on Solaris

2007-09-18 Thread Dmitri Trembovetski


  Hi Rob,

  OK, I understand it better now. If your application does
  translucent (alpha compositing) or anti-aliased rendering -
  both not supported by the X protocol - we have
  to perform the rendering using our software loops.

  But since Swing's back-buffer lives on the server
  (in a pixmap), we have to read the pixels from the
  pixmap to the client, modify then and write them
  back.

  It's worse if you have a gradient: then the rendering
  will be done scanline by scanline - this is the
  way our software pipeline does it.

  Consider rendering your gradient to a BufferedImage
  instead and then copying it to the back-buffer.
  If the gradient fills whole component area (and is not
  translucent), the BufferedImage can be opaque
  (and make sure that isOpaque() property of the component
  is true)

  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.

  In the local server case, have you tried setting
  this env. variable: J2D_PIXMAPS=shared . It may help.

  And, you can always programmatically set
  -Dsun.java2d.pmoffscreen=false in your application (just
  make sure you set it before any gui is initialized).

  Thanks,
Dmitri

Rob Ratcliff wrote:

Hi Dmitri,

I think we're understanding the problem more now. We think that a
repaint of the blank map is causing a repaint of an overlapping panel
that sports translucent gradient shading and vice-versa. So we're going
to take that out of the equation and see if the X-Server responds better.

Just to clarify my understanding though, where is the filled rectangle
generated? Is it an off-screen buffer/pixmap on the client side that is
sent to the X-Server or is it done 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 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 trying the Java2D
  flags.

  Thanks,
Dmitri







===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.

Re: [JAVA2D] Trouble Shooting High X-Server Load on Solaris

2007-09-19 Thread Dmitri Trembovetski


  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 we're trying to get it to run
without excessively loading up the local X-Server
I think we should probably add a -nonFancyMode flag to our app where it
doesn't use translucent panels or gradient shading on machines with
older graphics cards or when remoting the app.


  Yes, that would be a good idea. It doesn't even have to be
  automatic - one can add an option for the user to switch at
  runtime.


  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, the X-Server
load goes down to more normal levels (like 5-10%).
Why would that be on a local box? Seems like shared memory would be more
efficient? (using sun.java2d.pmoffscreen=true for both cases)


  That would be my assumption as well. Not sure why would
  that not be the case.


  And, you can always programmatically set
  -Dsun.java2d.pmoffscreen=false in your application (just
  make sure you set it before any gui is initialized).

That's a good idea. In the past, we've put that in the scripts, which
would detect whether the display variable was set to the local display
or the remote display. We also had to put in logic to detect certain
graphics cards since they responded differently as well.

BTW, (you all might have considered this already) it might be nice to
have a command line setting like -bestSettings where the Java2D layer
could attempt to automatically measure and configure itself with the
most optimal settings for lowest overall load (Java Application+XServer)
and graphics responsiveness at least for the client and server running
on the same box. It can take some time to manually figure the optimal
combination of environment variables and command line settings to create
the best performing application especially when it seems that different
X-Server/graphics card tends to require different settings. (For
instance, on certain Linux boxes, it was more efficient to use
pmoffscreen=true even when remoting the application from the Solaris box
when on a fast network.)


  I think it would be very hard to determine such best settings.
  The main issue is that each application may behave differently -
  so we couldn't do it just once during the installation of the jre,
  for example. And, of course, people can use different DISPLAY from
  the one that the jre was installed with (happens all the time
  with server boxes). To do something like this every time during
  startup would have a startup time impact.

  In general we rely on that the developers know better about what
  their application does and how it behaves. Any heuristics we
  could come up with will help some and hurt others - this was proven
  many times already.

  But the developer can have (like you suggested) a no fancy mode in
  the application appropriate for the conditions, or key off the user
  input.

  Thanks,
Dmitri




Thanks again!

Rob



===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.

Re: [JAVA2D] Trouble Shooting High X-Server Load on Solaris

2007-09-20 Thread Dmitri Trembovetski


  Just thought I'd mention it - you can probably detect if the
  display is local or remote programmatically:
  get DISPLAY env variable via System.getenv() and
  then check if there's an intersection between
  the addresses of the host you're displaying to
  and the local host.

  You can peek 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:


  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 we're trying to get it to run
without excessively loading up the local X-Server
I think we should probably add a -nonFancyMode flag to our app where it
doesn't use translucent panels or gradient shading on machines with
older graphics cards or when remoting the app.


  Yes, that would be a good idea. It doesn't even have to be
  automatic - one can add an option for the user to switch at
  runtime.


  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, the X-Server
load goes down to more normal levels (like 5-10%).
Why would that be on a local box? Seems like shared memory would be more
efficient? (using sun.java2d.pmoffscreen=true for both cases)


  That would be my assumption as well. Not sure why would
  that not be the case.


  And, you can always programmatically set
  -Dsun.java2d.pmoffscreen=false in your application (just
  make sure you set it before any gui is initialized).

That's a good idea. In the past, we've put that in the scripts, which
would detect whether the display variable was set to the local display
or the remote display. We also had to put in logic to detect certain
graphics cards since they responded differently as well.

BTW, (you all might have considered this already) it might be nice to
have a command line setting like -bestSettings where the Java2D layer
could attempt to automatically measure and configure itself with the
most optimal settings for lowest overall load (Java Application+XServer)
and graphics responsiveness at least for the client and server running
on the same box. It can take some time to manually figure the optimal
combination of environment variables and command line settings to create
the best performing application especially when it seems that different
X-Server/graphics card tends to require different settings. (For
instance, on certain Linux boxes, it was more efficient to use
pmoffscreen=true even when remoting the application from the Solaris box
when on a fast network.)


  I think it would be very hard to determine such best settings.
  The main issue is that each application may behave differently -
  so we couldn't do it just once during the installation of the jre,
  for example. And, of course, people can use different DISPLAY from
  the one that the jre was installed with (happens all the time
  with server boxes). To do something like this every time during
  startup would have a startup time impact.

  In general we rely on that the developers know better about what
  their application does and how it behaves. Any heuristics we
  could come up with will help some and hurt others - this was proven
  many times already.

  But the developer can have (like you suggested) a no fancy mode in
  the application appropriate for the conditions, or key off the user
  input.

  Thanks,
Dmitri




Thanks again!

Rob





===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.

Re: [JAVA2D] Extremely bad mousewheel scrolling performance on Mustang

2007-09-20 Thread Dmitri Trembovetski


  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 unconditionally disabled IntelliJ
  will miss the  new fully hw-accelerated Direct3D pipeline
  to be introduced soon in 6 update release.


I have tried your second suggestion, and so far it seems to work! (at least in 
my configuration).

I am not very familiar with Java2D acceleration, but
-Was the 'grey rect' fix introduced in Mustang? That would explain why the 
problem does not manifest on JRE 1.5


  Yes, the 'gray rect' fix was introduced in Mustang.

  The difference between 5.0 and 6.0 (with respect to the gray
  rect fix) is that in 5.0 the scrolling happens on the screen:
  first a copyArea is done on the screen surface, then Swing
  repaints the exposed area to the back-buffer (or, rather,
  a scratch buffer), which is then copied to the screen.

  In 6.0 with the gray rect fix it all happens in the back-buffer:
  both the copyArea and the repainting of the newly exposed
  area. Then the back-buffer is copied to the screen.

  With HW acceleration disabled this back-buffer is just a
  BufferedImage, so copyArea operation for large regions
  may be slower than on-screen scroll operation we had
  in 5.0 (which was handled through GDI and thus was hw
  accelerated in most cases).

  And a copy from the back-buffer to the screen - and such
  a copy after a large scroll could be pretty big - (which is
  handled through our GDI blit loops) could be rather slow in
  some cases like if the dimensions of the image being copied
  are not dword aligned (scan line is not a  multiple of 4).
  In this latter case the blit happens scan line by scan line,
  which is slow (I think there's a bug filed on that).


-IDEA opens a new top-level frame for each open project. Does the 'grey-rect' 
fix perhaps (try to) allocate VRAM for each non-foreground frame - and because 
of that remaining VRAM amount may get quite small, slowing down drawing 
operations?


  I don't think that's a problem - especially since you're
  having issues even with hw acceleration disabled.

  Thanks,
Dmitri



I have not tested this fully yet. But I will do so, and report the results here.

For now: thanks for your quick feedback.

Taras
[Message sent by forum member 'plethora' (plethora)]

http://forums.java.net/jive/thread.jspa?messageID=236246

===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.


===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.

Re: [JAVA2D] Extremely bad mousewheel scrolling performance on Mustang

2007-09-21 Thread Dmitri Trembovetski



  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:

Dmitry,

After running for a day with the grey rect fix disabled, I can confirm that 
it solves my problem.

Is there anything I can do to diagnose why the grey rect fix causes such 
extremely bad mousewheel scrolling performance on my system?

Thanks for your help,

Taras
[Message sent by forum member 'plethora' (plethora)]

http://forums.java.net/jive/thread.jspa?messageID=236447

===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.


===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.
---BeginMessage---


  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 unconditionally disabled IntelliJ
  will miss the  new fully hw-accelerated Direct3D pipeline
  to be introduced soon in 6 update release.


I have tried your second suggestion, and so far it seems to work! (at least in 
my configuration).

I am not very familiar with Java2D acceleration, but
-Was the 'grey rect' fix introduced in Mustang? That would explain why the 
problem does not manifest on JRE 1.5


  Yes, the 'gray rect' fix was introduced in Mustang.

  The difference between 5.0 and 6.0 (with respect to the gray
  rect fix) is that in 5.0 the scrolling happens on the screen:
  first a copyArea is done on the screen surface, then Swing
  repaints the exposed area to the back-buffer (or, rather,
  a scratch buffer), which is then copied to the screen.

  In 6.0 with the gray rect fix it all happens in the back-buffer:
  both the copyArea and the repainting of the newly exposed
  area. Then the back-buffer is copied to the screen.

  With HW acceleration disabled this back-buffer is just a
  BufferedImage, so copyArea operation for large regions
  may be slower than on-screen scroll operation we had
  in 5.0 (which was handled through GDI and thus was hw
  accelerated in most cases).

  And a copy from the back-buffer to the screen - and such
  a copy after a large scroll could be pretty big - (which is
  handled through our GDI blit loops) could be rather slow in
  some cases like if the dimensions of the image being copied
  are not dword aligned (scan line is not a  multiple of 4).
  In this latter case the blit happens scan line by scan line,
  which is slow (I think there's a bug filed on that).


-IDEA opens a new top-level frame for each open project. Does the 'grey-rect' 
fix perhaps (try to) allocate VRAM for each non-foreground frame - and because 
of that remaining VRAM amount may get quite small, slowing down drawing 
operations?


  I don't think that's a problem - especially since you're
  having issues even with hw acceleration disabled.

  Thanks,
Dmitri



I have not tested this fully yet. But I will do so, and report the results here.

For now: thanks for your quick feedback.

Taras
[Message sent by forum member 'plethora' (plethora)]

http://forums.java.net/jive/thread.jspa?messageID=236246

===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.



===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.
---End Message---

Re: [JAVA2D] Extremely bad mousewheel scrolling performance on Mustang

2007-09-21 Thread Dmitri Trembovetski


[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 member 'plethora' (plethora)]

http://forums.java.net/jive/thread.jspa?messageID=236488

===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.


===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.

Re: [JAVA2D] Trouble Shooting High X-Server Load on Solaris

2007-09-26 Thread Dmitri Trembovetski


  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, the X-Server
load goes down to more normal levels (like 5-10%).
Why would that be on a local box? Seems like shared memory would be more
efficient? (using sun.java2d.pmoffscreen=true for both cases)

  That would be my assumption as well. Not sure why would
  that not be the case.


My current theory now as to why the server setting lowered the CPU
time of the X-Server is that the additional communication traffic became
the bottleneck, which throttled the amount of requests per second that
the X-Server had to service. I've switched back to shared since the
graphics tended to restore faster after something like an overlapping
window obscured part of the screen.


  I guess it makes sense.


Also, I tried rendering the most expensive paint operation into an
off-screen buffer and then painted the buffer. The time to execute the


  When you say off-screen buffer, what do you mean? A BufferedImage
  or an image returned by create[Compatible]Image()?


paint method was reduced from 250 ms or more to around 90 ms, but the
X-Server CPU required did not change. Does the X-Server participate at
all when graphics are rendered in an off-screen buffer? If so, is there


  If you're rendering to a BufferedImage then X server is not involved.

  It only gets involved when you copy this image either to the screen
  or to a surface backed by a Pixmap (opaque VolatileImage, BufferStrategy,
  and - prior to jdk7 - opaque images created with create[Compatible]Image).
  It is copied to a Pixmap/Window using X[Shm]PutImage. If such
  image is translucent we first get the pixels from the destination
  surface using XGetImage, then do the compositing on the client side
  with our software loops, and then ship the pixels back with XPutImage.

  Also, if such BufferedImage can be cached in a pixmap (if it's opaque
  or 1-bit transparent), it gets copied to a pixmap and then all copies
  from this image happen from that cached pixmap. It gets updated when
  the original image gets rendered to.

  The only thing you can do is disable the caching by setting
  the acceleration priority property of an image to 0.0f. But I doubt
  that this would help your case.


a way to have it not participate? I would think that painting a rendered
pixmap shouldn't be all that expensive. Buffered images are already
compatible with the system's graphics now right? (The original paint
method painted a sequence of perhaps 30 30x90 images/icons.)   It is
still a little unclear to me where the various rendering/drawing
operations take place for the local X client-server model. Is there a
good reference to look at for this. (I guess I could download the VM
source now and peruse that if I had some spare time.)


  It would really help if you could produce a simple test case
  which resembles what your application does..

  Thanks,
Dmitri




We are also going to try Solaris 10 just to see if it behaves the same
way. We'll give dtrace a try as well to see if that illuminates what is
going on.

Thanks,

Rob





===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.

Re: [JAVA2D] Bizarre exception (Win32ShellFolder2)

2007-09-28 Thread Dmitri Trembovetski


  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 I got a flurry of

Exception while removing reference:
java.util.concurrent.RejectedExecutionException
java.util.concurrent.RejectedExecutionException
at
java.util.concurrent.ThreadPoolExecutor$AbortPolicy.rejectedExecution(ThreadPoolExecutor.java:1759)
at
java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:767)
at
java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:658)
at
java.util.concurrent.AbstractExecutorService.submit(AbstractExecutorService.java:92)
at
sun.awt.shell.Win32ShellFolder2$ComTask.execute(Win32ShellFolder2.java:1214)
at
sun.awt.shell.Win32ShellFolder2$FolderDisposer.dispose(Win32ShellFolder2.java:170)
at sun.java2d.Disposer.run(Disposer.java:128)
at java.lang.Thread.run(Thread.java:619)

Any idea what could be causing this? This is not readily reproducible
or I'd file a proper bug report.

Regards,

-- O.L.

===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.


===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.

[JAVA2D] Please try the new Direct3D 9-based Java2D pipeline in 6uN EA

2007-10-03 Thread Dmitri Trembovetski


  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 the
  OpenGL pipeline (in fact they share a lot of code), and is
  based on the Single Thread Rendering model developed for the OpenGL
  pipeline:
http://weblogs.java.net/blog/campbell/archive/2005/03/strcrazy_improv_1.html

  The D3D pipeline accelerates pretty much the same set of operations
  as the OGL one:
http://weblogs.java.net/blog/campbell/archive/2004/11/behind_the_grap.html

  So, this is a call to action:

  Please try your applications with this new pipeline and let us know
  if you find any issues. We really want to make this pipeline rock-solid
  as it needs to be if it is to be left enabled by default. Time is short,
  so the sooner you report issues the better chances are we'll have time
  to fix them.

  Please report both negative and positive findings so we can
  keep track of what's working and what's not (and on which
  HW).

  Take a look at this page for testing/troubleshooting guidelines:
https://jdk6.dev.java.net/testD3D.html
  (please make sure to include the output of J2D_TRACE_LEVEL=4 output
  with your postings)

  There are some known problems in full-screen mode, multi-screen,
  and on some chipsets (namely, Intel 645G). These are being worked on
  and hopefully will be addressed by the release time.

  Another thing to be aware of - this pipeline does not
  accelerate Xor rendering mode. It will be really, really slow.
  Sorry about that.

  Thanks,
Dmitri
  Java2D Team

===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.

Re: [JAVA2D] Please try the new Direct3D 9-based Java2D pipeline in 6uN EA


  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 installed 6uN EA, and I ran into two graphics problems. First, when 
you scroll through a Java source-code file in NetBeans 6.0-b1, the file display 
gets corrupted - just cycle through a few pages hitting Page Down and you'll 
see it. Second, I wrote an app where I manipulate some rather large image 
files, and I display these files drawing a BufferedImage over a JPanel. This 
JPanel is inside a JScrollPane. I've loaded a 5648x3584 image file, and 
scrolling is smooth under Java 1.6.2, but it's way slower under 6uN. My machine 
settings follow:

- Lenovo ThinkPad X60s
- WinXP Pro SP2
- Intel 945GM Express Chipset

Here's the output I get when I set J2D_TRACE_LEVEL=4 :

[I] CheckAdaptersInfo
[I] --
[I] Adapter Ordinal  : 0
[I] Description  : Mobile Intel(R) 945GM Express Chipset Family
[I] GDI Name, Driver : \\.\DISPLAY1, ialmrnt5.dll
[I] Vendor Id: 0x8086
[I] Version  : 6.14.10.4450
[I] --
[I] InitD3D: successfully created Direct3D9 object
[I] D3DGD_getDeviceCapsNative
[I] D3DPPLM::CheckDeviceCaps: device 0: Passed
[I] D3DContext::InitContext device 0
[I] D3DContext::ConfigureContext device 0
[I] D3DContext::ConfigureContext: successfully created device: 0
[I] D3DContext::InitDevice: device 0
[W] D3DContext::InitDevice: sync query not available
[I] D3DContext::InitDefice: successfully initialized device 0
[V]   | CAPS_DEVICE_OK
[V]   | CAPS_ALPHA_RT_PLAIN
[V]   | CAPS_ALPHA_RTT
[V]   | CAPS_OPAQUE_RTT
[V]   | CAPS_LCD_SHADER | CAPS_BIOP_SHADER
[V]   | CAPS_MULTITEXTURE
[V]   | CAPS_TEXNONSQUARE

I get smooth performance again if I use -Dsun.java2d.d3d=false in my command 
line. Cheers,

Roger
[Message sent by forum member 'roger_rf' (roger_rf)]

http://forums.java.net/jive/thread.jspa?messageID=238462

===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.


===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.

Re: [JAVA2D] Please try the new Direct3D 9-based Java2D pipeline in 6uN EA


  Hi Ken,

  thank you for your comments.

  I don't think I can comment on the VM heap issue -
  this is probably a question for the deployment team.

  I'm not sure how it would work given that VM serves
  multiple applets at the same time.

  Thanks,
Dmitri


Ken Warner wrote:

Hi Dmitri,

I'm really excited to hear about this.  The boost in performance will be
a real advantage for Java in the Java vs. Flash war that is going on now.

But I am running into a related problem.  In the process of beta testing
my panorama viewer, I'm encountered a lot of problems with MemoryErrors
on client machines.  The problem is easily remedied by setting the VM
arguments.  But at the same time, those same people exhibit a
reluctance to simply open the Java Control Panel and set the VM
arguments.  I even have a whole system set up where by my viewer pops up
an HTML page that explains that there has been a memory error and a link
to an HTML page that explains how to easily fix it.

Yet people still complain and point out that Flash doesn't have these
problems.  Now Flash 9 has supports a panorama viewer but the image
quality is terrible.  Java can render an image much more nicely and
clearly.  Yet, Java is still seen as deficient just because the default
JVM memory parameters are too small and people are reluctant to take the
30 seconds it takes to set the memory parameters to a higher value.

Is there any thought at SUN to set the default memory parameters for the
JVM to a larger 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 Trembovetski wrote:

  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 the
  OpenGL pipeline (in fact they share a lot of code), and is
  based on the Single Thread Rendering model developed for the OpenGL
  pipeline:

http://weblogs.java.net/blog/campbell/archive/2005/03/strcrazy_improv_1.html



  The D3D pipeline accelerates pretty much the same set of operations
  as the OGL one:

http://weblogs.java.net/blog/campbell/archive/2004/11/behind_the_grap.html



  So, this is a call to action:

  Please try your applications with this new pipeline and let us know
  if you find any issues. We really want to make this pipeline rock-solid
  as it needs to be if it is to be left enabled by default. Time is
short,
  so the sooner you report issues the better chances are we'll have time
  to fix them.

  Please report both negative and positive findings so we can
  keep track of what's working and what's not (and on which
  HW).

  Take a look at this page for testing/troubleshooting guidelines:
https://jdk6.dev.java.net/testD3D.html
  (please make sure to include the output of J2D_TRACE_LEVEL=4 output
  with your postings)

  There are some known problems in full-screen mode, multi-screen,
  and on some chipsets (namely, Intel 645G). These are being worked on
  and hopefully will be addressed by the release time.

  Another thing to be aware of - this pipeline does not
  accelerate Xor rendering mode. It will be really, really slow.
  Sorry about that.

  Thanks,
Dmitri
  Java2D Team

===


To unsubscribe, send email to [EMAIL PROTECTED] and include in the
body
of the message signoff JAVA2D-INTEREST.  For general help, send
email to
[EMAIL PROTECTED] and include in the body of the message help.




===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.


===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.

Re: [JAVA2D] Please try the new Direct3D 9-based Java2D pipeline in 6uN EA


  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 'alexlamsl' (alexlamsl)]

http://forums.java.net/jive/thread.jspa?messageID=238479

===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.


===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.

Re: [JAVA2D] Please try the new Direct3D 9-based Java2D pipeline in 6uN EA


  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 suggest a workaround
  it would be great if you can come up with a simple
  test which reproduces the issue.

  Thanks,
Dmitri


[EMAIL PROTECTED] wrote:

Hi Dmitri,

I was really excited to get my hands on the 6uN EA. But the performance boost 
of the DX9 rendering I expected didn't come. In fact, it became horribly slow :(

Here is what the trace output says:

[I] CheckAdaptersInfo
[I] --
[I] Adapter Ordinal  : 0
[I] Description  : NVIDIA Quadro FX 3450/4000 SDI
[I] GDI Name, Driver : \\.\DISPLAY1, nv4_disp.dll
[I] Vendor Id: 0x10de
[I] Version  : 6.14.10.7718
[I] --
[I] InitD3D: successfully created Direct3D9 object
[I] D3DGD_getDeviceCapsNative
[I] D3DPPLM::CheckDeviceCaps: device 0: Passed
[I] D3DContext::InitContext device 0
[I] D3DContext::ConfigureContext device 0
[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_ALPHA_RT_PLAIN
[V]   | CAPS_ALPHA_RTT
[V]   | CAPS_OPAQUE_RTT
[V]   | CAPS_LCD_SHADER | CAPS_BIOP_SHADER
[V]   | CAPS_MULTITEXTURE
[V]   | CAPS_TEXNONPOW2
[V]   | CAPS_TEXNONSQUARE

My application uses some techniques Romain Guy describes in his blog to blur 
out the application contents and then display a dialog in the foreground via 
the LayeredPane. I create a BufferedImage and paint the content on it. It is 
then resized to half its size and then the blur filter from the SwingLabs 
project is applied to it. The original content pane is then replaced by this 
picture, while the foreground draws a rounded-corner wait-dialog.

Launching with -Dsun.java2d.d3d=false takes 273ms to setup this effect. With DX 
rendering it takes 2038ms. The front dialog displays a small animated 
GIF-picture. The old rendering was totally smooth, the DX version has around 
1fps.

If you need more information, please let me know.

Regards,
Sebastian Kopsan
[Message sent by forum member 'fenriswulf' (fenriswulf)]

http://forums.java.net/jive/thread.jspa?messageID=238510

===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.


===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.

Re: [JAVA2D] Update N: Framerate degrades markedly

2007-10-08 Thread Dmitri Trembovetski


  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 BufferedImage (or image created with
  'createImage')?

  It is likely that you might be seeing the effects of
  our support for onscreen rendering.
  I've filed bug
6613062 D3D: improve on-screen rendering responsiveness
  which will improve the situation.

  Thanks,
Dmtiri
  Java2D Team



I can confirm the Direct3D pipeline is enabled (see listing at the end of this 
post), and that if I use -Dsun.java2d.d3d=false everything goes back to normal 
(eg. fast and smooth).

Admittedly this applet is a few years old, but it has always been fine under 
JDK1.4, Java 5 and Java 6 up until now.

You can try it for yourself at:

http://www.play500online.com/500/500.jsp (and click 'Start New')

I am happy to send a copy of the source to the team if you can give me the best 
e-mail address. In brief though, it is all Java2D, transparency, clipping, 
anti-aliasing and VoltaileImages.

Regards,

Richard
[EMAIL PROTECTED]

---

[I] CheckAdaptersInfo
[I] --
[I] Adapter Ordinal  : 0
[I] Description  : RADEON 9500 PRO / 9700
[I] GDI Name, Driver : \\.\DISPLAY1, ati2dvag.dll
[I] Vendor Id: 0x1002
[I] Version  : 6.14.10.6660
[I] --
[I] Adapter Ordinal  : 1
[I] Description  : RADEON 9500 PRO / 9700 - Secondary
[I] GDI Name, Driver : \\.\DISPLAY2, ati2dvag.dll
[I] Vendor Id: 0x1002
[I] Version  : 6.14.10.6660
[I] --
[I] InitD3D: successfully created Direct3D9 object
[I] D3DGD_getDeviceCapsNative
[I] D3DPPLM::CheckDeviceCaps: device 0: Passed
[I] D3DContext::InitContext device 0
[I] D3DContext::ConfigureContext device 0
[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_ALPHA_RT_PLAIN
[V]   | CAPS_ALPHA_RTT
[V]   | CAPS_OPAQUE_RTT
[V]   | CAPS_LCD_SHADER | CAPS_BIOP_SHADER
[V]   | CAPS_MULTITEXTURE
[V]   | CAPS_TEXNONSQUARE
[I] D3DGD_getDeviceCapsNative
[I] D3DPPLM::CheckDeviceCaps: device 1: Passed
[I] D3DContext::InitContext device 1
[I] D3DContext::ConfigureContext device 1
[I] D3DContext::ConfigureContext: successfully created device: 1
[I] D3DContext::InitDevice: device 1
[I] D3DContext::InitDefice: successfully initialized device 1
[V]   | CAPS_DEVICE_OK
[V]   | CAPS_ALPHA_RT_PLAIN
[V]   | CAPS_ALPHA_RTT
[V]   | CAPS_OPAQUE_RTT
[V]   | CAPS_LCD_SHADER | CAPS_BIOP_SHADER
[V]   | CAPS_MULTITEXTURE
[V]   | CAPS_TEXNONSQUARE
[Message sent by forum member 'kennardconsulting' (kennardconsulting)]

http://forums.java.net/jive/thread.jspa?messageID=238851

===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.


===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.

Re: [JAVA2D] Please try the new Direct3D 9-based Java2D pipeline in 6uN EA

2007-10-09 Thread Dmitri Trembovetski


  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 rendering performance degraded
  I'll see what can be done for this one.

  A workaround is, as you have mentioned, to use ImageIO for reading
  images.

  In Java 6u4:
3.861277 ms
6.203313 ms
7.477602 ms
2.312025 ms
2.202579 ms

  With 6uN without the fix I get:
48.689088 ms
40.162102 ms
47.807305 ms
49.540503 ms

  With the fix or the ImageIO work around:
0.094893 ms
0.0937 ms
0.119034 ms
0.09319 ms
0.092727 ms

  Thanks,
Dmitri
  Java2D Team


[EMAIL PROTECTED] wrote:

Hello,

I see a noticeable performance degradation in one of my apps.
Painting PNG images (upscaling using bilinear or bicubic filtering) seems to be 
slower (factor of 20 in my case).
Loading the image using ImageIO instead of Toolkit#getImage seems to resolve 
the problem.

Test:

[code]
import javax.swing.*;
import java.awt.*;
import java.awt.event.ActionEvent;
import java.awt.event.ActionListener;
import java.io.IOException;
import java.net.URL;

public class PerformanceTest
{
public static void main(String[] args)
{
EventQueue.invokeLater(new Runnable()
{
public void run()
{
try
{
initGUI();
}
catch (Exception e)
{
e.printStackTrace();
}
}
});
}


private static void initGUI() throws IOException, InterruptedException
{
JFrame frame = new JFrame();
final ImagePanel imagePanel = new ImagePanel();
frame.getContentPane().add(imagePanel, BorderLayout.CENTER);
frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
frame.setBounds(100, 100, 600, 600);
frame.setVisible(true);

Timer timer = new Timer(20, new ActionListener()
{
public void actionPerformed(ActionEvent e)
{
imagePanel.repaint();
}
});

timer.start();
}


private static class ImagePanel extends JPanel
{
private Image image;


private ImagePanel() throws InterruptedException, IOException
{
image = Toolkit.getDefaultToolkit().getImage(new 
URL(http://java.sun.com/docs/books/tutorial/figures/uiswing/components/HtmlButtonMetal.png;));
//image = ImageIO.read(new 
URL(http://java.sun.com/docs/books/tutorial/figures/uiswing/components/HtmlButtonMetal.png;));

MediaTracker mediaTracker = new MediaTracker(this);
mediaTracker.addImage(image, 1);
mediaTracker.waitForAll();
}


protected void paintComponent(Graphics g)
{
long ns1 = System.nanoTime();
int o = (int) (Math.random() * 20);
Graphics2D g2d = (Graphics2D) g;
g2d.setRenderingHint(RenderingHints.KEY_INTERPOLATION, 
RenderingHints.VALUE_INTERPOLATION_BILINEAR);
g2d.drawImage(image, o, o, 200, 200, null);
long ns2 = System.nanoTime();
System.out.println((ns2 - ns1) / 100. +  ms);
}
}
}
[/code]

Operating System is Windows Vista

Output:
1.6.0_05-ea-b04

[I] CheckAdaptersInfo
[I] --
[I] Adapter Ordinal  : 0
[I] Description  : NVIDIA GeForce Go 7900 GS (Microsoft Corporation - WDDM)
[I] GDI Name, Driver : \\.\DISPLAY1, nvd3dum
[I] Vendor Id: 0x10de
[I] Version  : 7.15.10.9746
[I] --
[I] InitD3D: successfully created Direct3D9 object
[I] D3DGD_getDeviceCapsNative
[I] D3DPPLM::CheckDeviceCaps: device 0: Passed
[I] D3DContext::InitContext device 0
[I] D3DContext::ConfigureContext device 0
[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_ALPHA_RT_PLAIN
[V]   | CAPS_ALPHA_RTT
[V]   | CAPS_OPAQUE_RTT
[V]   | CAPS_LCD_SHADER | CAPS_BIOP_SHADER
[V]   | CAPS_MULTITEXTURE
[V]   | CAPS_TEXNONPOW2
[V]   | CAPS_TEXNONSQUARE
78.177883 ms
63.440185 ms
50.098336 ms
55.525353 ms
46.665708 ms
45.636387 ms
42.916208 ms
45.019688 ms
62.719773 ms
48.997568 ms
...

1.6.0_02-b05
[W] GetFlagValues: DDraw/D3D is disabled on Windows Vista
[W] GetFlagValues: DDraw screen locking is disabled (W2K, XP+)
[I] InitDirectX
[V] CheckRegistry: Found Display Device 0: NVIDIA GeForce Go 7900 GS (Microsoft 
Corporation - WDDM)
6.752813 ms
2.110464 ms
2.243441 ms
2.47741 ms
3.281492 ms
2.323549 ms
2.153067 ms
2.332698 ms
2.236387 ms
...

Martin
[Message sent by forum member 'til77' (til77)]

http://forums.java.net/jive/thread.jspa?messageID=239186

Re: [JAVA2D] Please try the new Direct3D 9-based Java2D pipeline in 6uN EA

2007-10-09 Thread Dmitri Trembovetski


  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 file a bug on this one.


  Ok, there's actually a bug for this already:
6231864: Some images loaded via Toolkit or ImageIcon can't be accelerated

  It had been fixed as part of another fix (6205557) in jdk7.
  I will see if I can fix it in 6uN (it won't be a straight
  back-port of jdk7 fix).


- for some unaccelerated images rendering performance degraded
  I'll see what can be done for this one.


  This one is also known:
4841762: D3D/OGL: enable bilinear sw-surface transforms

  Thanks,
Dmitri




  A workaround is, as you have mentioned, to use ImageIO for reading
  images.

  In Java 6u4:
3.861277 ms
6.203313 ms
7.477602 ms
2.312025 ms
2.202579 ms

  With 6uN without the fix I get:
48.689088 ms
40.162102 ms
47.807305 ms
49.540503 ms

  With the fix or the ImageIO work around:
0.094893 ms
0.0937 ms
0.119034 ms
0.09319 ms
0.092727 ms

  Thanks,
Dmitri
  Java2D Team


[EMAIL PROTECTED] wrote:

Hello,

I see a noticeable performance degradation in one of my apps.
Painting PNG images (upscaling using bilinear or bicubic filtering)
seems to be slower (factor of 20 in my case).
Loading the image using ImageIO instead of Toolkit#getImage seems to
resolve the problem.

Test:

[code]
import javax.swing.*;
import java.awt.*;
import java.awt.event.ActionEvent;
import java.awt.event.ActionListener;
import java.io.IOException;
import java.net.URL;

public class PerformanceTest
{
public static void main(String[] args)
{
EventQueue.invokeLater(new Runnable()
{
public void run()
{
try
{
initGUI();
}
catch (Exception e)
{
e.printStackTrace();
}
}
});
}


private static void initGUI() throws IOException,
InterruptedException
{
JFrame frame = new JFrame();
final ImagePanel imagePanel = new ImagePanel();
frame.getContentPane().add(imagePanel, BorderLayout.CENTER);
frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
frame.setBounds(100, 100, 600, 600);
frame.setVisible(true);

Timer timer = new Timer(20, new ActionListener()
{
public void actionPerformed(ActionEvent e)
{
imagePanel.repaint();
}
});

timer.start();
}


private static class ImagePanel extends JPanel
{
private Image image;


private ImagePanel() throws InterruptedException, IOException
{
image = Toolkit.getDefaultToolkit().getImage(new
URL(http://java.sun.com/docs/books/tutorial/figures/uiswing/components/HtmlButtonMetal.png;));

//image = ImageIO.read(new
URL(http://java.sun.com/docs/books/tutorial/figures/uiswing/components/HtmlButtonMetal.png;));


MediaTracker mediaTracker = new MediaTracker(this);
mediaTracker.addImage(image, 1);
mediaTracker.waitForAll();
}


protected void paintComponent(Graphics g)
{
long ns1 = System.nanoTime();
int o = (int) (Math.random() * 20);
Graphics2D g2d = (Graphics2D) g;
g2d.setRenderingHint(RenderingHints.KEY_INTERPOLATION,
RenderingHints.VALUE_INTERPOLATION_BILINEAR);
g2d.drawImage(image, o, o, 200, 200, null);
long ns2 = System.nanoTime();
System.out.println((ns2 - ns1) / 100. +  ms);
}
}
}
[/code]

Operating System is Windows Vista

Output:
1.6.0_05-ea-b04

[I] CheckAdaptersInfo
[I] --
[I] Adapter Ordinal  : 0
[I] Description  : NVIDIA GeForce Go 7900 GS (Microsoft
Corporation - WDDM)
[I] GDI Name, Driver : \\.\DISPLAY1, nvd3dum
[I] Vendor Id: 0x10de
[I] Version  : 7.15.10.9746
[I] --
[I] InitD3D: successfully created Direct3D9 object
[I] D3DGD_getDeviceCapsNative
[I] D3DPPLM::CheckDeviceCaps: device 0: Passed
[I] D3DContext::InitContext device 0
[I] D3DContext::ConfigureContext device 0
[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_ALPHA_RT_PLAIN
[V]   | CAPS_ALPHA_RTT
[V]   | CAPS_OPAQUE_RTT
[V]   | CAPS_LCD_SHADER | CAPS_BIOP_SHADER
[V]   | CAPS_MULTITEXTURE
[V]   | CAPS_TEXNONPOW2
[V]   | CAPS_TEXNONSQUARE
78.177883 ms
63.440185 ms
50.098336 ms
55.525353 ms
46.665708 ms
45.636387 ms
42.916208 ms
45.019688 ms
62.719773 ms
48.997568 ms
...

1.6.0_02-b05
[W] GetFlagValues: DDraw/D3D is disabled on Windows Vista
[W] GetFlagValues: DDraw screen

Re: [JAVA2D] How do I install the 1.6 beta as my browser plugin?

2007-10-10 Thread Dmitri Trembovetski


  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
acceleration.  When I install it, there is no installation as browser
plugin.

I imagine this is intentional.  Is there a way to force it to be a
browser plugin?

I would like to see real world performance in the browser.

I tried jre-6u5-ea-windows-i586-p-iftw.exe and that gives me about a
three time performance boost in general computation and about a 1/3'd
performance boos in drawing.

I'd like to compare the beta in the same environment.

Ken

===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.


===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.

Re: [JAVA2D] Swing focus in 1.6

2007-10-22 Thread Dmitri Trembovetski


  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 1.6, when you pass null as the parent component to
JOptionPane.showMessageDialog, the focus after clicking the Ok button
goes to the top level window.  In 1.4 and 1.5, the focus went to the
last component to have focus before the message dialog was opened.  Here
is a small example program.


import java.awt.*;
import javax.swing.*;
import java.awt.event.*;

public class JFrameFocusTest extends JFrame {
 JLabel jLabelWindowName = new JLabel();
 JButton jButtonOpenDialog = new JButton();

 public JFrameFocusTest() {
   try {
 vpGen();
   } catch (Exception e) {
 e.printStackTrace();
   }


 }

 public static void main(String[] arg) {
 JFrameFocusTest jFrameFocusTest1 = new JFrameFocusTest();
 jFrameFocusTest1.setLocation(200,200);
 jFrameFocusTest1.show();
 JFrameFocusTest jFrameFocusTest2 = new JFrameFocusTest();
 jFrameFocusTest2.jLabelWindowName.setText(Top);
 jFrameFocusTest1.setLocation(250,250);
 jFrameFocusTest2.show();
 }
 private void vpGen() throws Exception {
   this.setBounds(new Rectangle(10, 10, 389, 354));
   jLabelWindowName.setText(Bottom);
   jLabelWindowName.setHorizontalAlignment(SwingConstants.CENTER);
   jLabelWindowName.setHorizontalTextPosition(SwingConstants.CENTER);
   jButtonOpenDialog.setText(Open Dialog);
   this.getContentPane().add(jLabelWindowName, BorderLayout.CENTER);
   this.getContentPane().add(jButtonOpenDialog, BorderLayout.SOUTH);
   jButtonOpenDialog.addActionListener(new
java.awt.event.ActionListener() {
 public void actionPerformed(java.awt.event.ActionEvent e) {
   jButtonOpenDialog_actionPerformed(e);
 }
   });
 }

 void jButtonOpenDialog_actionPerformed(java.awt.event.ActionEvent e) {
   //the problem can be fixed in this example by changing
   //the 'null' in the next line to 'this'
   JOptionPane.showMessageDialog(null, Whatever, Error Message,
 JOptionPane.ERROR_MESSAGE);
 }

}


In the above case I know how to make it work like I expected, but in my
real code I sometimes have message dialogs called without a reference to
the specific window that called them.

Does anyone know why this functionality was change for 1.6?

BTW, I am running windows xp.

Thanks
bill

===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.


===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.

Re: [JAVA2D] Please try the new Direct3D 9-based Java2D pipeline in 6uN EA

2007-10-31 Thread Dmitri Trembovetski


  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 got all kind of repaint problems.  The backgroundcolor gets gray.
-  I also use a treetable, and the expansion of nodes gives a totally distorted 
result.



  You're seeing this because your chip is Intel 945G. We've seen
  many reports about problems on this chipset:
6612195: D3D: Netbeans editor is completely unusable with JDK 6uN [Intel 
945G]
6599742: D3D: Text rendering becomes garbled on Intel 945G chipset

  Which is why we will (as of b07) disable the pipeline on Intel 945G.

  Interestingly, it is likely that you will see a performance improvement
  because of that - the chip is that bad =)

  The 965G chipset is better (HW transforms, hw pixel shaders), but the
  drivers still have some issues, and performance is not stellar:
6620073: D3D: running J2DBench restarts the driver on Vista [Intel G965]

  We're working with Intel on this bug as well as performance issues, they
  may have a fix in time. Until they do the pipeline will be disabled
  on 965G as well.

  As a workaround for now you can set -Dsun.java2d.d3d=false (in Java Control
  Panel, for example).

  Thank you,
Dmitri
  Java2D Team



Configuration
Systeem Windows XP Pro SP2
HP Compaq

I verified that it works well after disabling using the -Dsun.java2d.d3d=false 
property.

This is the trace

[I] CheckAdaptersInfo
[I] --
[I] Adapter Ordinal  : 0
[I] Description  : Intel(R) 82945G Express Chipset Family
[I] GDI Name, Driver : \\.\DISPLAY1, ialmrnt5.dll
[I] Vendor Id: 0x8086
[I] Version  : 6.14.10.4308
[I] --
[I] InitD3D: successfully created Direct3D9 object
[I] D3DGD_getDeviceCapsNative
[I] D3DPPLM::CheckDeviceCaps: device 0: Passed
[I] D3DContext::InitContext device 0
[I] D3DContext::ConfigureContext device 0
[I] D3DContext::ConfigureContext: successfully created device: 0
[I] D3DContext::InitDevice: device 0
[W] D3DContext::InitDevice: sync query not available
[I] D3DContext::InitDefice: successfully initialized device 0
[V]   | CAPS_DEVICE_OK
[V]   | CAPS_ALPHA_RT_PLAIN
[V]   | CAPS_ALPHA_RTT
[V]   | CAPS_OPAQUE_RTT
[V]   | CAPS_LCD_SHADER | CAPS_BIOP_SHADER
[V]   | CAPS_MULTITEXTURE
[V]   | CAPS_TEXNONSQUARE

Loading XMLSpear
LookAndFeel com.sun.java.swing.plaf.windows.WindowsLookAndFeel
propert with name homepage  not found.
default homepage is used
os.name  = Windows XP
os.version   = 5.1
java.version = 1.6.0_05-ea
java.vendor  = Sun Microsystems Inc.
java.compiler  = null

Thanks
Dick Deneer
[Message sent by forum member 'deneer' (deneer)]

http://forums.java.net/jive/thread.jspa?messageID=243217

===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.


===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.

Re: [JAVA2D] XVR 600 Graphics card and OpenGL Pipeline

2007-11-02 Thread Dmitri Trembovetski


  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:
http://java.sun.com/javase/6/webnotes/trouble/TSG-Desktop/html/java2d.html

  But in short, you can, as Clemens suggested,
  try -Dsun.java2d.pmoffscreen=false property first
  if your app does lots of translucency/antialiasing.

  Also, try setting this env. variable (without the flag
  above):
export J2D_PIXMAPS=shared
  More info:
 
http://java.sun.com/javase/6/webnotes/trouble/TSG-Desktop/html/gcghe.html#gdkug

  And make sure that you have enough shared memory
  on your system
 
http://java.sun.com/javase/6/webnotes/trouble/TSG-Desktop/html/gcghe.html#gdkti

  Thanks,
Dmitri
  Java2D Team

[EMAIL PROTECTED] wrote:

I would first try out how well it does on the XVR600, I guess it should be good 
enough for most purposes - maybe you don't even need the OpenGL pipeline. You 
could also try to set pmoffscreen if you have to render many translucent 
objects, or if you do a lot of antialiasing.

As far as I know Nvidia cards are quite well supported on Solaris (Nvidia 
provides X11/OpenGL solaris drivers), all in all nvidia cards are the best 
consumer cards if you would like to run the OpenGL pipeline.(Don't go for they 
cheapest models, 7300GT (which is a 7600) and up are ok).

lg Clemens
[Message sent by forum member 'linuxhippy' (linuxhippy)]

http://forums.java.net/jive/thread.jspa?messageID=243454

===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.


===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.

Re: [JAVA2D] Java2D Disposer mechanism

2007-11-02 Thread Dmitri Trembovetski


  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 a separate object
  (DisposerRecord).

  And, if the Disposer is used correctly we don't
  even use the reference to the main object itself,
  but to its 'disposer referent' - see earlier Jim's
  emails.

  Thanks,
Dmitri


[EMAIL PROTECTED] wrote:

I'm curious why the Java2D mechanism uses
WeakReference instead of PhantomReference given the
problem mentioned here:


I also asked this question to myself severla times, because PhantomReferences 
seem to be exactly designed for what the Disposer uses Weak-References.

I think it could be related to performance, because Phantom-References can't be 
completly freed in one GC cycle as far as I know, but of course I may be 
completly wrong ;)

Would be really interesting to know the exact reason from someone who knows for 
sure ;)

, lg Clemens
[Message sent by forum member 'linuxhippy' (linuxhippy)]

http://forums.java.net/jive/thread.jspa?messageID=243389

===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.


===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.

Re: [JAVA2D] Direct3D is disabled in win2003 in 6uN EA?

2007-11-18 Thread Dmitri Trembovetski


  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 as they are not
  updated as often.

  If you have an opinion or use case on why this
  should not be the case please let us know.

  Thanks,
Dmitri

[EMAIL PROTECTED] wrote:

Hello

I got [W] GetFlagValues: D3D is disabled on Win Server 2003 while set 
J2D_TRACE_LEVEL=4

Is it the default behaviour or I can force to enable it in windows 2003?

thanks in advance!

James
[Message sent by forum member 'inchlin' (inchlin)]

http://forums.java.net/jive/thread.jspa?messageID=244202

===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.


===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.

Re: [JAVA2D] Direct3D is disabled in win2003 in 6uN EA?

2007-11-20 Thread Dmitri Trembovetski


[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 have some posts 
in their forums.
Now write some software which does what you describe here, implement it using 
the D3D pipeline including readbacks to VRam and once with  the headless 
software-only Toolkit - now load your service with 20-50 concurrent users 
(otherwise the faster pipeline would not make any sence) - and compare your 
results.
No matter wether you use a 8800GTX or a Readeon-3870, the results will be 
disappointing compared with the software-only pipeline - if you don't believe 
me simply try it out.



  I agree - for servers it's much easier to scale using CPUs
  than GPUs - at least, for now.

  Thanks,
Dmitri



lg Clemens
[Message sent by forum member 'linuxhippy' (linuxhippy)]

http://forums.java.net/jive/thread.jspa?messageID=246354

===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.


===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.

Re: [JAVA2D] Saving restoring a region of a VolatileImage

2007-11-20 Thread Dmitri Trembovetski


  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 Dmitri - thank you.  I have it working now though not for a 
VolatileImage, I had to use a BufferedImage instead. This is because using the 
VI caused my applet to freeze when running inside the browser even though it 
runs OK when run inside the Eclipse applet viewer.

Well I guess that's good enough - it has improved my applet considerably.



===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.

Re: [JAVA2D] Saving restoring a region of a VolatileImage

2007-11-20 Thread Dmitri Trembovetski


  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 with a VI is much 
*slower* than working with a plain BufferedImage.  I don't mean the rendering 
part of it but rather the creating of subimages and then calling drawImage to 
render into the VI is much slower than using a BI.  Why would this be?  The 
code is identical except for using VI instead of BI.



  Could you post your code?

  Note that copying from a VolatileImage to a BufferedImage
  will be very slow, you don't want to do that on every frame.
  It is acceptable for do a snapshot once in a while kind
  of stuff, but not in general.

  Also, depending on what types of rendering operations you
  do BufferedImage may indeed be faster. At least until
  6uN comes out which will have better hardware acceleration.

  Thanks,
Dmitri

===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.

Re: [JAVA2D] Three D mouse / navigator / spaceball --- would it work with Java?

2007-11-21 Thread Dmitri Trembovetski


  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.

http://www.3dconnexion.com/3dmouse/spacenavigator.php

===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.


===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.

Re: [JAVA2D] Rectangle and background clipping issue

2007-11-21 Thread Dmitri Trembovetski


[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 all the time).


I have not officially profiled it but it is visibly slower than I would like.


  I'd still suggest to profile - you may be solving
  a symptom instead of the cause.




Anyway, assuming that it is super-expensive to
 repaint  the whole thing, you can construct a clip shape
 (which would be your bg rectangle minus your small
  rectangles) and set it on the graphics context.
 That way the area of the bg rectangle which isn't
covered by smaller rectangles only will be
 repainted.
   Shape clip may be an expensive operation, though
(depending on the pipeline), so I would still
   suggest to profile (or just time) both
approaches.


Yes, but how do I remove areas from a clip region?  I can only see how to set a 
clip region to a Shape and the area around the smaller rectangles is not a 
Shape.



  Something along these lines
   Area clip = new Area(new Rectangle(0,0,largeRectW,largeRectH));
   clip.subtract(new Area(new Rectangle(,,,)));
   g2d.clip(clip);

  Thanks,
Dmitri

===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.

Re: [JAVA2D] Please try the new Direct3D 9-based Java2D pipeline in 6uN EA

2007-11-23 Thread Dmitri Trembovetski


  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 GTS/GeForce2 Pro Driver Version 3.15.00.12.00
Running Windows 2000 SP4 and DirectDraw 9.0c  -- real old stuff and
yet the most current version of the driver and Java 1.6 is about 3 times
faster than 1.5.


  There are two issues here: GF2 does not meet minimum hw requirements
  so the pipeline will be disabled. You will need
  at least some GeForce FX board (with Shaders 2.0) with
  HW Transform and Lighting.

  Secondly, starting with b08 the pipeline will only be enabled
  on client-class OS (WinXP and newer). Win2K* are classified as
  a server-class OS flavor.

  The reason for this policy is that typically on servers people
  care more about stability than performance, and the drivers
  for these systems are lagging behind client OS-es.

  Thanks,
 Dmitri



It's hard for me to run the beta version to test hardware acceleration.

Have their been any reports about this card failing?  When will there be
a 1.6 JRE with hardware acceleration so I can try my work -- it's an 
applet.


[EMAIL PROTECTED] wrote:

Thanks!

I have filed bug
  6629891: D3D: Rendering artifacts with older driver [Nvidia Quadro 
NVS 110M]

to track this issue (will appear on bugs.sun.com soon).

We'll disable the pipeline on drivers older than 6.14.11.5665 
(earliest known

to work at this point).

Thanks,
  Dmitri
[Message sent by forum member 'trembovetski' (trembovetski)]

http://forums.java.net/jive/thread.jspa?messageID=245499

=== 

To unsubscribe, send email to [EMAIL PROTECTED] and include in the 
body
of the message signoff JAVA2D-INTEREST.  For general help, send 
email to

[EMAIL PROTECTED] and include in the body of the message help.




===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.


===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.

Re: [JAVA2D] OpenGL Pipeline crashes video driver on Vista

2007-11-23 Thread Dmitri Trembovetski


  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.
Scroll up and down - the scrolled area goes black. Or even scroll the pane on 
the left.

Only reproducible on Vista, and only with Aero enabled. Sigh.

So far unable to reproduce with other apps (like jdk demos).

Dmitri
[Message sent by forum member 'trembovetski' (trembovetski)]

http://forums.java.net/jive/thread.jspa?messageID=245736

===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.


===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.

Re: [JAVA2D] Please try the new Direct3D 9-based Java2D pipeline in 6uN EA


  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 with the 6u5 and the D3D pipeline.
(I'm quite sure it is enabled, as a full-screen drawing framerate drops by a 
factor of about 20  when disabled, with CPU usage jumping to about 70%)

Marvelous performance (thank you all for your work), however I have found 
something annoying :

(I did my tests on Windows Vista, with an nVidia GeForce 8600M GT, recent 
drivers (Aero enabled))


If I create an empty resizable JFrame (I tested with SystemLookAndFeel, 
SubstanceLookAndFeel and Metal), and start resizing it, I will most of the time 
see its content flickering (the client rectangle becoming black before being 
repainted).

Obviously, all reverted to normal when I ran the application with  
-Dsun.java2d.d3d=false.

Someone has an idea about what is happening ?
[Message sent by forum member 'artscoop' (artscoop)]

http://forums.java.net/jive/thread.jspa?messageID=245249

===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.


===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.

Re: [JAVA2D] Garbage collecting a BufferedImage


  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  
or awt.ToolkitImage (even though the reference was

not cleaned up).

Thanks a lot and my apologies for the trouble,


No problem at all, however I can really recommend using those tools:
- jconsole: To moonitor jvm behaviour (gc-workload, , generate heap 
snapshots)
- jhat: To inspect heap-snapshots (can be very helpful to find leaks and other 
memory hungry stuff)
- Netbeans profiler: Run it every now and then and see whats going on. It even 
helped me often to find hidden bugs where my code hit a slow-path even for very 
common operations just because I forgot to write a fast-path ^^

lg Clemens
[Message sent by forum member 'linuxhippy' (linuxhippy)]

http://forums.java.net/jive/thread.jspa?messageID=246742

===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.


===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.

Re: [JAVA2D] Please try the new Direct3D 9-based Java2D pipeline in 6uN EA-- another stupid question...


Ken Warner wrote:
I thought the first notice that was sent out about the D3D pipeline said 
that the OpenGl pipeline was turned on for D3D. 


  the OpenGl pipeline was turned on for D3D - this doesn't
  make any sense. Not sure how something like this
  can be concluded from what have been written.


I must have misunderstood what was said. The D3D pipeline and
the OpenGL pipelines are two different pipelines with two
entirely different sets of problems mostly caused by poorly
implemented video card drivers.  Am I finally understanding
this? 


  Yes.


And the OpenGL pipeline has nothing to do with the hardware
acceleration of Java2D which uses the D3D pipeline?  Is that correct?


  Yes.


So it was said that the D3D pipeline will be disabled *BY DEFAULT*
on some OS's.  Will it be possible to *ENABLE* the D3D pipeline with
-Dsun.java2d.d3d=true on the Win200* OS's that are going to have
the D3D pipeline disabled by default from using the D3D pipeline?


  The D3D pipeline is enabled by default on all
  platforms. That means that it will try to get initialized
  on all systems during the startup. However, as a part of the
  initialization process it will check for the driver
  and operating system requirements, as well as hardware
  capabilities. If any of these checks fail the
  pipeline will not be used.

  Currently the check for OS will fail on server class
  operating systems, so the pipeline will not be used.

  Unfortunately you will not be able to force it
  using -Dsun.java2d.d3d=true .


In all the emails that have been flying around, people talk of
...the pipeline... and I get confused about which pipeline
is being talked about.


  Depends on the context, of course, but at least in this
  thread it is most likely in reference to the Direct3D
  pipeline.

  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 PROTECTED] wrote:


Hello,

I've been playing a few hours with the 6u5 and the D3D pipeline.
(I'm quite sure it is enabled, as a full-screen drawing framerate 
drops by a factor of about 20  when disabled, with CPU usage jumping 
to about 70%)


Marvelous performance (thank you all for your work), however I have 
found something annoying :


(I did my tests on Windows Vista, with an nVidia GeForce 8600M GT, 
recent drivers (Aero enabled))



If I create an empty resizable JFrame (I tested with 
SystemLookAndFeel, SubstanceLookAndFeel and Metal), and start 
resizing it, I will most of the time see its content flickering (the 
client rectangle becoming black before being repainted).


Obviously, all reverted to normal when I ran the application with  
-Dsun.java2d.d3d=false.


Someone has an idea about what is happening ?
[Message sent by forum member 'artscoop' (artscoop)]

http://forums.java.net/jive/thread.jspa?messageID=245249

=== 

To unsubscribe, send email to [EMAIL PROTECTED] and include in 
the body
of the message signoff JAVA2D-INTEREST.  For general help, send 
email to

[EMAIL PROTECTED] and include in the body of the message help.



=== 

To unsubscribe, send email to [EMAIL PROTECTED] and include in the 
body
of the message signoff JAVA2D-INTEREST.  For general help, send 
email to

[EMAIL PROTECTED] and include in the body of the message help.




===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.


===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.

Re: [JAVA2D] Please try the new Direct3D 9-based Java2D pipeline in 6uN EA-


[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 sun.java2d.d3d=true/false/force?

This is like taking away the power of descision away from the user which could 
make some users quite angry :-/


  There is a way to ignore the results of the hw checks
  and force the use of the pipeline, just not via the -D
  property but via special env. variable.

  We'd like not to expose this unless really necessary
  because if people start just setting a property
  left and right (as they can or will be able to
  with the webstart or applet) - their users may
  pay for it, because on some systems the drivers
  can bluescreen the system.

  Thank you,
Dmitri




lg Clemens
[Message sent by forum member 'linuxhippy' (linuxhippy)]

http://forums.java.net/jive/thread.jspa?messageID=247249

===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.


===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.

Re: [JAVA2D] Saving restoring a region of a VolatileImage


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



===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.

Re: [JAVA2D] Saving restoring a region of a VolatileImage


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




===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.


===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.

Re: [JAVA2D] Question about fullscreen exclusive mode in applet in browser...

2007-12-03 Thread Dmitri Trembovetski


 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,
Dmitri

Ken Warner wrote:

Hi,

My applet at

http://pancyl.com

can go into fullscreen exclusive mode.  F1 enters -- ESC exits.

When it goes into fullscreen exclusive mode using the 1.6 plugin,
there is a gray status bar at the bottom of the screen that says,
Java Applet Window 
A lot of people find this annoying.  Fullscreen exclusive should mean
FULLSCREEN! 
I've looked at java.awt.GraphicsDevice and this is the method that

set's the bounds of the window.

   public void setFullScreenWindow(Window w) {
   // Get display mode before changing the full screen window
   DisplayMode dm;
   if (w == null) {
   dm = null;
   } else {
   dm = getDisplayMode();
   }
   if (fullScreenWindow != null  windowedModeBounds != null) {
   fullScreenWindow.setBounds(windowedModeBounds);
}
   // Set the full screen window
   fullScreenWindow = w;
   if (fullScreenWindow != null) {
   windowedModeBounds = fullScreenWindow.getBounds();
   fullScreenWindow.setBounds(0, 0, dm.getWidth(), dm.getHeight());
   fullScreenWindow.setVisible(true);
   fullScreenWindow.toFront();
   }
   }

I tried to write my own class to extend GraphicsDevice so I can override 
setFullScreenWindow()
but I can't put it into the java.awt package.  I get a security warning 
at runtime.


I'm not smart enough or good enough to figure out a way to set the 
bounds of the fullscreen window so that the status bar won't show.


However, someone has.  Goto the URL below.  You will see a gallery
of available panoramic images.  They can be shown in Flash, Java or
Quicktime.  Select one to show in Java.  When you see that it's finished
loading, click the right button and enter fullscreen mode.  You will see
that there is no status bar.

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.

http://easypano.com/panorama-gallery.html

Ken

===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.


===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.

Re: [JAVA2D] rotating Swing components

2007-12-05 Thread Dmitri Trembovetski


  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 existing Swing components to rotate their 
contents so that the text appears at 90,180 or 270. Is there a way to 
do this to existing components without having to create a custom 
version and over-ride paint()?


MArk

===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.


===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.

Re: [JAVA2D] fillPolygon performance versus drawImage

2007-12-17 Thread Dmitri Trembovetski


  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

===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.

Re: [JAVA2D] fillPolygon performance versus drawImage

2007-12-17 Thread Dmitri Trembovetski


  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 you to explain the
  guy what's going on..

  Thanks,
Dmitri

===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.


===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.

Re: [JAVA2D] D3D pipeline on Geforce-FX5200

2007-12-20 Thread Dmitri Trembovetski


[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 its not that bad, its perfectly useable.
I thought that the Execptions thrown could be useful, maybe some reace 
condition?

  


 I believe this is a manifestation of an old Java2Demo bug,
 but thanks for reporting (java2d.MemoryMonitor is a Java2Demo class).

 Java2Demo is not the most cleanly written application, which helped
 us with finding many bugs in our code so we like to keep it slightly 
broken =)


 Thanks,
   Dmitri



I'll try the new driver tomorrow.

lg Clemens
[Message sent by forum member 'linuxhippy' (linuxhippy)]

http://forums.java.net/jive/thread.jspa?messageID=251053

===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.
  


===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.

Re: [JAVA2D] D3D pipeline on Geforce-FX5200

2007-12-21 Thread Dmitri Trembovetski


  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

===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.

Re: [JAVA2D] Odd Vista, NVidia, dual-display, Java interaction...

2008-01-04 Thread Dmitri Trembovetski


  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 (Lenovo T61p T7700, 4GB, NVidia Quadro FX 570M driving 
1680x1050 LCD,
 Vista Ultimate 32-bit from Microsoft GM DVD - not the Lenovo pre-install), 
with Java
 1.6.0_03. When docked (but not when not docked), I run it in a dual-monitor
 configuration (add on a 1600x1200 external display via DVI). Two or three 
times
 a day, the machine simply turns off when I am switching to or from
 the Java application (Interactive Brokers trade station started via

  When you say switch to/from, do you mean alt+tabbing
  in/out? (I'm asking because you mentioned that the application
  is running full-screen - I'm assuming it's real full-screen
  mode).

  Or did you just mean maximized window?

 .jnlp download through Firefox). If I don't have the IB Java app running,

  Do you have a link for this application?
  (hopefully they have a demo I could try)

 the machine works flawlessly. If I run the IB Java app undocked (ie, just 
the
 1680x1050 LCD driven), no problem. Seems like an odd interaction between the
 display driver and Java. I'm running the NVidia 7.15.11.5685 drivers dated 
12/10/07.
 Again, it's not a BSOD. The machine simply and instantaneously powers off.
 Java itself, I hope, cannot do that, but the display driver might be able to
 cause such a serious fault.


Any thoughts?

Dmitri has suggested I try a different Java app and the latest build of 6uN, 

 which I'll do. I'll add that I run the Java app full screen (which, in
 a dual display environment, means only 1 screen - the 1600x1200 screen,
 which is below the 1680x1050 screen).

  Does the problem occur when you only have one screen (1600x1200)?

  Which of the two screen is your primary screen?

As I don't have any other Java apps that I routinely run, I'm willing 

 to try any Java apps anyone thinks might be best for this kind of trial.

  You can try one of these simple demos for a start (SwingSet would
  be preferable):
http://java.sun.com/products/javawebstart/demos.html

  None of them enter full-screen mode though.

  Thank you,
Dmitri
  Java2D Team

===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.

Re: [JAVA2D] Odd Vista, NVidia, dual-display, Java interaction...

2008-01-07 Thread Dmitri Trembovetski


[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 suspect that this doesn't have
  much to do with graphics. 6u3 and 6u10 use very
  different APIs for rendering on Vista, so I can't
  imagine how both of them could cause such
  failure.

  I'm wondering if you have an issue with system
  memory or something. Java may trigger it because
  it uses quite a bit of memory. I don't know,
  just thinking aloud.

  Do you have your manifacturer's
  testing tools? (sometimes you can boot into
  their tools and run some tests from there)

  Also, could you check event log and see if there's
  anything there? (Control Panel/
  Administrative Tools/Event Viewer).

  Thanks,
Dmitri


Next experiment: run with just one display, the external 1600x1200 display. Personally, I 
think this will work, but that's just gut feel.

Thanks,
Richard
[Message sent by forum member 'rrelph' (rrelph)]

http://forums.java.net/jive/thread.jspa?messageID=252518

===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.


===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.

Re: [JAVA2D] Merging sysmem vram

2008-01-12 Thread Dmitri Trembovetski


  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 in is up to you - they will appear
  in the destination image in that order.

  Thanks
Dmitri

[EMAIL PROTECTED] wrote:

Hi,

I have a situation where I want to do a hybrid of vram image blits  sysmem image blits. 
The software image blits are just pixel arrays that get drawn into a big array representing 
the screen (framebuffer). I use this for images I'd like to do certain operations on only 
doable in software. Next to those images I also want to draw normal images from 
vram directly (using fixed function pipeline operations (scaling/rotation etc); because for 
these images it would be nice to use that gpu power otherwise doing nothing (and freeing a 
bit of cpu time otherwise needed for these operations).

Now is there a way to mix this? As my framebuffer is blitted as one image, 
overlaps dont mix well with the vram images (i have to blit or the vram images, 
or the framebuffer first, and they will overlap in that order).

But ideally i'd like to have them overlap in the way they are called, i know 
the order that they're called in my program, so is there a way i could set 
certain masks to pixels in my framebuffer or something?

Thanks!

Martijn
[Message sent by forum member 'bitshit' (bitshit)]

http://forums.java.net/jive/thread.jspa?messageID=253568

===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.


===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.

Re: [JAVA2D] 6uN-b10: 2D Performance regression -or- problems enabling D3D pipeline

2008-01-16 Thread Dmitri Trembovetski


  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] D3DContext::ResetContext
 [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


  I have seen a report of similar behavior on on another board
  (Nvidia FX 6200, see bug 6588384) but I haven't been able to
  reproduce this so far myself as I don't have the hardware.
  I'll try to locate 6600GT.

  It is disturbing to see that this happens on another board
  as well.

  Do you see the same problem with other applications?
  Like SwingSet2, for example, from the jdk demo/jfc
  directory?

  Just for the sake of it, could you change the display
  mode to 16-bit color and see if changes anything?

  Thanks,
Dmitri
  Java2D Team

[EMAIL PROTECTED] wrote:

Hi, I'm having performance problems using the latest build of Java 6uN. It 
seems there are problems recognizing my graphics card or initializing the D3D 
pipeline. I have the same piece of code executing under JDK 6u1 and JDK 6uNb10. 
This code is an active rendering loop. Under 6u1, I get ~200 FPS, but under 
6uNb10, I only get 69 FPS. Profiling shows there is significant time spent in 
java.awt.image.BufferStrategy.show().

The different calls look like this:
Executed call: C:\Program Files\Java\jdk1.6.0_01\bin\javaw.exe 
-agentlib:jprofilerti=port=31762 -Xbootclasspath/a:C:\Program 
Files\jprofiler5\bin\agent.jar -classpath C:\JavaProg\fkJava\classes Lab1.two.ActiveDrawer
Executed call: C:\Program Files\Java\jdk1.6.0_10\bin\javaw.exe 
-agentlib:jprofilerti=port=31761 -Xbootclasspath/a:C:\Program 
Files\jprofiler5\bin\agent.jar -classpath C:\JavaProg\fkJava\classes Lab1.two.ActiveDrawer

Here are call trees from profiling:
http://i18.tinypic.com/80uw5zl.png - 6u1
http://i16.tinypic.com/73o8cx5.png - 6uNb10

Below is console output from three separate executions, the two first using 
6u1, and the last one using 6uNb10:



[W] GetFlagValues: DDraw screen locking is disabled (W2K, XP+)
[I] InitDirectX
[V] CheckRegistry: Found Display Device 0: NVIDIA GeForce 6600 GT
[I] CreateDevice: lpGUID=0x0 hMon=0x0
[I] DDSetupDevice
[I] DDraw::CreateDDPrimarySurface: back-buffers=0
[V] DDSetupDevice: successfully created primary surface
[V] DDSetupDevice: successfully setup ddraw device
[I] DDSetupDevice
[I] DDraw::CreateDDPrimarySurface: back-buffers=0
[V] DDSetupDevice: successfully created primary surface
[V] DDSetupDevice: successfully setup ddraw device
[I] D3DContext::D3DContext
[V] D3DUtils_SelectDeviceGUID: using TNL rasterizer
[I] D3DContext::CreateD3DDevice
[I] D3DContext::CreateAndTestD3DDevice
[I] D3DContext::InitD3DDevice: d3dDevice=Oxb1800
[V] D3DContext::CreateAndTestD3DDevice: D3D device creation/initialization 
successful
[W] TestRenderingResults: Quality test failed due to value ff at (34, 0)
[I] CreateD3DDevice: tests PASSED, d3d enabled (forced: no).
[I] D3DContext::CreateD3DDevice
[I] D3DContext::CreateAndTestD3DDevice
[I] D3DContext::InitD3DDevice: d3dDevice=Oxb1800
[V] D3DContext::CreateAndTestD3DDevice: D3D device creation/initialization 
successful
[W] TestRenderingResults: Quality test failed due to value ff at (34, 0)
[I] CreateD3DDevice: tests PASSED, d3d enabled (forced: no).



[W] GetFlagValues: DDraw screen locking is disabled (W2K, XP+)
[I] InitDirectX
[V] CheckRegistry: Found Display Device 0: NVIDIA GeForce 6600 GT
[I] CreateDevice: lpGUID=0x0 hMon=0x0
[I] DDSetupDevice
[I] DDraw::CreateDDPrimarySurface: back-buffers=0
[V] DDSetupDevice: successfully created primary surface
[V] DDSetupDevice: successfully setup ddraw device
[I] D3DContext::D3DContext
[V] D3DUtils_SelectDeviceGUID: using TNL rasterizer
[I] D3DContext::CreateD3DDevice
[I] D3DContext::CreateAndTestD3DDevice
[I] D3DContext::InitD3DDevice: d3dDevice=Oxaf5a0
[V] D3DContext::CreateAndTestD3DDevice: D3D device creation/initialization 
successful
[W] TestRenderingResults: Quality test failed due to value ff at (34, 0)
[I] CreateD3DDevice: tests PASSED, d3d enabled (forced: no).
[I] D3DContext::CreateD3DDevice
[I] D3DContext::CreateAndTestD3DDevice
[I] D3DContext::InitD3DDevice: d3dDevice=Oxaf5a0
[V] D3DContext::CreateAndTestD3DDevice: D3D device creation/initialization 
successful
[W]

Re: [JAVA2D] 6uN-b10: 2D Performance regression -or- problems enabling D3D pipeline

2008-01-17 Thread Dmitri Trembovetski


  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

===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.

Re: [JAVA2D] 6uN-b10: 2D Performance regression -or- problems enabling D3D pipeline

2008-01-17 Thread Dmitri Trembovetski


[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 why I get exactly 69 frames using 6uN, as my 
display is at 70 Hz, but it still doesn't explain why D3D doesn't initialize 
properly.


  Actually, it appears that it did initialize properly.
  (it re-initializes when you change to/from fs mode).
  I just didn't know that your application is full-screen
  so I thought that it re-inits itself over and over
  in windowed mode.

  Thanks,
Dmitri

===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.

Re: [JAVA2D] 6uN-b10: 2D Performance regression -or- problems enabling D3D pipeline

2008-01-17 Thread Dmitri Trembovetski


[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 v-sync disabled in full 
screen mode.


  Yes, we're planning on adding API for controlling
  vsync for BufferStrategy in Java 7.

  We can't add any new api in an update release of Java 6,
  unfortunately.


Thank you for all of your fast replies and great support, it is very much 
appreciated.


  Thanks for trying it out! It really helps to get feedback
  as early as possible (including what APIs you want to see
  added).

  Dmitri

===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.

Re: [JAVA2D] java2d and java3d fighting for opengl buffer (crashes sometimes)

2008-01-18 Thread Dmitri Trembovetski


  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 subparts :) ...)
[Message sent by forum member 'pepe' (pepe)]

http://forums.java.net/jive/thread.jspa?messageID=254624

===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.


===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.

Re: [JAVA2D] How do I turn on kerning?

2008-01-27 Thread Dmitri Trembovetski


  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 overrides other attributes so I have now tried 
this:

[code]
MapTextAttribute, Object textAttributes = new HashMapTextAttribute, 
Object();
textAttributes.put(TextAttribute.KERNING, TextAttribute.KERNING_ON);
textAttributes.put(TextAttribute.FAMILY, Serif);
textAttributes.put(TextAttribute.SIZE, 13);
g2d.setFont(Font.getFont(textAttributes));
g2d.drawString(text, 100, 150);
[/code]

but the results are identical no matter what family I use.

How do I turn on kerning?



===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.

Re: [JAVA2D] How do I turn on kerning?

2008-01-29 Thread Dmitri Trembovetski


  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 can see it.



===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.

Re: [JAVA2D] Alpha blending performance

2008-02-13 Thread Dmitri Trembovetski


  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 it's no different from
  just rendering to an opaque image filled with the background
  color.

  Typically one would have an opaque back buffer, and render
  everything into there, then present it. It is highly recommended
  to use the BufferStrategy API for your double-buffering
  implementation.

  Another questions is which java version have you tried?
  Have you tried 6uN (dev. builds available at http://jdk6.dev.java.net)

[EMAIL PROTECTED] wrote:

I'm having some serious trouble with the performance of alpha blending in Java 
-- so serious that I suspect that I'm doing something wrong. I don't know what 
I'm doing wrong, though, so I'm hoping someone might be able to tell me. Here 
follows the results of some experiments I've been doing.

First of all, I'm trying to draw BufferedImages with an alpha channel directly 
onto a window. I'm using Java 1.6 all the time. I'm trying to draw a number of 
50x50 images onto the window at 16 FPS, and performance seems to scale linearly 
with around 6% CPU per images (so at 4 images, it consumes ~24% CPU, at 8 
images ~50% CPU, and at around 15 or more images the framerate starts to drop). 
I also tried to draw one 800x600 image onto a window, and it takes around 400 
ms. Performance in this test seems to be about the same on both Linux and 
Windows, by the way.


  Yeah, that wouldn't work too well.


Second, I'm trying to use VolatileImages to draw the images onto the window 
(using GraphicsConfiguration.createCompatibleVolatileImage()). However, that 
doesn't work at all, because Java2D will only give me opaque VolatileImages. It 
doesn't return VolatileImages with either 1-bit or alpha transparency, on 
either Linux or Windows. It may be worth mentioning that I have direct 
rendering working on the Linux system.


  Translucent VIs are only available with opengl pipeline
  (since 1.5, and depending on your configuration) and the new
  d3d pipeline in 6uN.


Third, I tried to use the Direct3D rendering pipeline by setting 
sun.java2d.d3d=true. That actually works fairly well, and I seem to be able to 
draw alpha transparent images at about the same rate as normal images, and 
opaque images are drawn faster as well. However, it obviously only works on 
Windows, so I'd very much prefer not use it. A weird thing I noticed is that I 
still don't get accelerated VolatileImages for translucent images. Should it be 
like that?


  Yeah, see above. The new d3d pipeline is enabled by default, and
  it does support accelerated translucent VIs.


Fourth, I tried to use the OpenGL rendering pipeline by setting 
sun.java2d.opengl=true, which is a very mixed blessing. because performance 
became definitely wonderful on Windows. All draw operations dropped to hardly 
measurable times. However, it doesn't seem to work at all on Linux, because 
performance wasn't affected at atll, and when setting sun.java2d.trace=count, 
it indicates that it's still using the normal XPM drawing routines. There also 
seems to be a fairly serious bug when using it on Windows, because when drawing 
newly created BufferedImages, the result is some weird monochrome blue drawing. 
As long as the BufferedImages weren't created recently, they are drawn as they 
should. Am I doing something weird to cause this behavior? Oh, and by the way, 
I'm still not getting accelerated VolatileImages, which I find weird.



  What is your video board? Could you please provide output with
  J2D_TRACE_LEVEL=4 env. variable set?

  If you try the 6uN build, could you please provide output
  from that as well (on windows, too).


Also, I'm wondering about the usage of the alternate pipelines as such. It 
seems to be working fairly OK for stand-alone programs, but what about applets? 
Is it at all possible to use the alternate pipelines when writing an applet? 
Even if I can somehow get permission to change system properties within an 
applet, AWT has already been started and set up its pipelines by that time, 
right?
[Message sent by forum member 'dolda2000' (dolda2000)]


  With the new Java plugin in 6u10 you will be able to specify
  vm parameters (and a separate vm will be started).
  Although I would suggest against enabling the
  opengl pipeline unconditionally. It could be better to provide
  separate links for accelerated and sw-rendering.

  The new d3d pipeline is enabled by default, so you don't need
  to provide any flags.

  Thanks,
Dmitri
  Java2D Team

===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
[EMAIL PROTECTED] and include in

Re: [JAVA2D] How do I turn on kerning?

2008-02-14 Thread Dmitri Trembovetski


  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 added support for Arabic (etc) to the Times New Roman
font (and others) they added an OpenType 'GPOS' table which is
*supposed* to be the way to do kerning in an OpenType font.
However they did not in fact add kerning information to the table.

On a separate list I received email from Adobe that they also
found the same problem with the Vista fonts.

So really this appears to be a bug in the Vista fonts which
we'll have to see if we can workaround, but really the JDK
is doing just what the font tells it to do.

Anyway I filed bug 6663396 to track it and decide what to do.
It should show up in a day or so on bugs.sun.com

-phil.

[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 can see it.



===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.


===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.

Re: [JAVA2D] Alpha blending performance

2008-02-15 Thread Dmitri Trembovetski


  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 like people to use my code 
without any weird requirements, so if at all possible, I'd like not to depend 
on APIs or characteristics of particular JREs.


  This non-standard distribution will become standard
  in the near future, so I suggest that you at least
  try and see how your application behaves on it.


[...]

Performance in this test seems to be about
the same on both Linux and Windows, by the way.

   Yeah, that wouldn't work too well.


Really? Why is that? Is it because I fooled you into thinking that I wasn't 
using a BufferStrategy, or is there something inherently slow with drawing 
alpha translucent images in Java2D?


  That really depends on the source and
  destination - what kind of image you render and where
  you render it to.

  If you're rendering a translucent BufferedImage
  into another BufferedImage, it'd be done in software
  but it will be reasonably fast because both source and
  destination pixels reside in system memory.

  If you're trying to render a translucent BI into
  an hw accelerated surface (like VI or screen), then
  the destination pixels live in VRAM (or in case of
  X11, on the X server), so they will need to be
  first pulled into system memory so that the software
  loops can perform alpha compositing. This pulling
  pixels off VRAM or the X server (and then putting
  the composited pixels back) is a very slow operation.

  The best case is where your source translucent image
  is hw-accelerated itself and sits in VRAM - for
  that you'd either need a translucent VI,
  or a translucent managed image (a BI is a managed
  image), and your destination is also in VRAM.
  In that case the compositing is done using
  video hardware and is very fast.

  As I mentioned, translucent managed images
  will only become available (by default on windows) in the
  upcoming 6uN. In previous releases they were
  only accelerated if a non-default Java2D
  rendering pipeline is used (either OpenGL or
  Direct3D - enabled via flags). In the current
  Java 6 release the D3D pipeline is also enabled
  in the full-screen mode.

  The hw accelerated translucent VIs will be available
  in 6uN on Windows by default, and with optional
  OpenGL pipeline on X11 or windows (still enabled
  via flags).

  Does this make it more clear?


What is your video board? Could you please provide
 output with
  J2D_TRACE_LEVEL=4 env. variable set?


Sure! My video board is (according to lspci on Linux) a ATI Technologies Inc M22 
[Mobility Radeon X300]. The output is as follows:
[I] GLXGC_FindBestVisual: scn=0
[I] GLXGC_InitGLX
[I] OGLFuncs_OpenLibrary
[I] OGLFuncs_InitPlatformFuncs
[I] OGLFuncs_InitBaseFuncs
[I] OGLFuncs_InitExtFuncs
[I] GLXGC_InitGLX: client GLX version=1.4
[I] GLXGC_InitFBConfig: scn=0 vis=0x0
[V]   candidate fbconfigs:
[V] id=0x28 db=0 alpha=8 depth=24 stencil=0 valid=false (bad match)
[V] id=0x30 db=0 alpha=8 depth=24 stencil=0 valid=false (bad match)
[V] id=0x27 db=0 alpha=8 depth=24 stencil=8 valid=false (bad match)
[V] id=0x2f db=0 alpha=8 depth=24 stencil=8 valid=false (bad match)
[V] id=0x24 db=1 alpha=8 depth=24 stencil=0 valid=false (bad match)
[V] id=0x2c db=1 alpha=8 depth=24 stencil=0 valid=false (bad match)
[V] id=0x23 db=1 alpha=8 depth=24 stencil=8 valid=false (bad match)
[V] id=0x2b db=1 alpha=8 depth=24 stencil=8 valid=false (bad match)
[E] GLXGC_InitFBConfig: could not find an appropriate fbconfig
[E] GLXGC_FindBestVisual: could not find best visual
[I] GLXGraphicsConfig_getGLXConfigInfo
[I] GLXGC_InitFBConfig: scn=0 vis=0x23
[V]   candidate fbconfigs:
[V] id=0x23 db=1 alpha=8 depth=24 stencil=8 valid=false (bad match)
[E] GLXGC_InitFBConfig: could not find an appropriate fbconfig
[E] GLXGraphicsConfig_getGLXConfigInfo: could not create fbconfig

I seem to be able to infer from this that the OpenGL pipeline doesn't find a 
visual that it is content with, but what is it looking for?


  That I'm not sure - Chris would know.


If you try the 6uN build, could you please provide
 output
  from that as well (on windows, too).


I'd like to, but the Windows system isn't mine, unfortunately, and I have no 
Windows systems of my own. I'll try to get hold of it again, and get back with 
the output from it if I can.


With the new Java plugin in 6u10 you will be able
 to specify
  vm parameters (and a separate vm will be started).
 Although I would suggest against enabling the
opengl pipeline unconditionally. It could be better
 to provide
  separate links for accelerated and sw-rendering.
The new d3d pipeline is enabled by default, so you
 don't need
  to provide any flags.


Do you have any idea when this JRE is going to released? As I

Re: [JAVA2D] Image with transparent background

2008-02-21 Thread Dmitri Trembovetski


  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 quality (fineness), so I'm using a J2D 
shape to create a texture in J3D.  I've been able to display the shape 
successfully by drawing it to a BufferedImage, creating a texture from that and 
applying the texture to a quad.

The background of the image becomes part of the texture and obscures objects 
behind it.  I'd like the background to be transparent so that only the shape 
itself appears to be in the scene.  I assume I will need to make the quad 
transparent, too.  It seems that a GIF will support a transparent background 
and might be the solution I need.  (Or perhaps there's another way...)

If the solution is a GIF, can I create the GIF from the BufferedImage without 
writing to disk and just use it directly?  I'm new to image processing so I'd 
appreciate any code snippets that will take the BufferedImage to a GIF.
[Message sent by forum member 'scubed' (scubed)]

http://forums.java.net/jive/thread.jspa?messageID=260277

===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.


===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.

Re: [JAVA2D] Image with transparent background

2008-02-21 Thread Dmitri Trembovetski


[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 java.awt.Transparency).

  Thanks,
Dmitri


[Message sent by forum member 'scubed' (scubed)]

http://forums.java.net/jive/thread.jspa?messageID=260291

===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.


===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.

Re: [JAVA2D] Detecting which java2d operations are accelerated

2008-03-02 Thread Dmitri Trembovetski


  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 bi-linear interpolation can be 
accelerated by java2d?

This is for video rendering - when the opengl or direct3d pipelines are being 
used, I want the video component to be able to automagically figure out it can 
smooth the video scaling using bi-linear interpolation, but when using software 
rendering, just use nearest-neighbour.
[Message sent by forum member 'wmeissner' (wmeissner)]

http://forums.java.net/jive/thread.jspa?messageID=261887

===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.


===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.

Re: [JAVA2D] SE6U10Beta and JDesktopPane.dragMode flickering performance

2008-04-04 Thread Dmitri Trembovetski


  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 PROTECTED] wrote:

Hello,

I am trying the U10 Beta 14 on my laptop with a Swing app that has many internal frames. I noticed 
that when dragging an internal frame within the app, the border of the moving internal frame is 
flickering, the dragging feels sluggish and the CPU goes to the roof. This happens only with 
JDestopPane.putClientProperty(JDesktopPane.dragMode, outline);

If I disable the hardware accelerated graphics pipeline setting -Dsun.java2d.d3d=false the problem disappears. 


Below is a summary of my environment and the output obtained with 
J2D_TRACE_LEVEL=4

java version 1.6.0_10-beta
Java(TM) SE Runtime Environment (build 1.6.0_10-beta-b14)
Java HotSpot(TM) Client VM (build 11.0-b11, mixed mode)

[I] OS Version = OS_VISTA or newer
[I] CheckAdaptersInfo
[I] --
[I] Adapter Ordinal  : 0
[I] Adapter Handle   : 0x10001
[I] Description  : NVIDIA Quadro NVS 140M
[I] GDI Name, Driver : \\.\DISPLAY1, nvd3dum.dll
[I] Vendor Id: 0x10de
[I] Device Id: 0x0429
[I] SubSys Id: 0x20d817aa
[I] Driver Version   : 7.15.11.5685
[I] GUID : {D7B71E3E-4769-11CF-2F62-D30001C2CA35}
[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

The OS is Win Vista Business,  Version 6.0 (Build 6000)

Should I post this as a bug somewhere?

Regards,
Horia
[Message sent by forum member 'sevenm' (sevenm)]

http://forums.java.net/jive/thread.jspa?messageID=267779

===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.


===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.

Re: [JAVA2D] Java 6u10 drawing performance

2008-04-09 Thread Dmitri Trembovetski


  Another thing - is that blinking rectangle (the one that
  shows the currently selected handle) done via
  xor paint mode? If so, it would slow things down
  on systems with Direct3D pipeline enabled because
  xor operations are not accelerated (6635462).

  It would work ok for smaller areas 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 configuration?
  (if possible, please run any swing app from
  console with J2D_TRACE_LEVEL=4 environment
  variable set and post the output).

  It looks from the screenshot that if you're running on
  Vista, is that the case?

  If so, there's a known problem with Vista and
  applets right now because of Vista's bug, see this:
6670586: D3D: Applets fail to repaint and  display properly- flickering 
[Vista, DWM]

  Do you get the same behavior when Aero is disabled?

  Thanks,
Dmitri
  Java2D Team


[EMAIL PROTECTED] wrote:
I installed Java 6u10 and I'm testing my new applet and I'm having a 
problem with it. if you open this page :


http://color-schemer-pro.com/cms/w/demo/Applet.html

and try to play with the browser scrollbar you will get overlap in the 
applet, at first I thought something is wrong with my color wheel 
itself but after extensive observation I found that :


1-Even normal swing are overlapping with each other and with the page 
itself.
2-I tried to actively repaint the content pane of the applet (through 
another thread ), I managed to get the applet to clear the mess, but 
because the overlapped happened even outside the applet box(which I 
can't repaint), this didn't work.
3-I tried with many other applet and I still getting annoying 
overlapping. you can see what I'm talking about here:

http://nnaass.com/bug/overlep.jpg


Any ideas ?
[Message sent by forum member 'alaamurad' (alaamurad)]

http://forums.java.net/jive/thread.jspa?messageID=268404

=== 

To unsubscribe, send email to [EMAIL PROTECTED] and include in the 
body
of the message signoff JAVA2D-INTEREST.  For general help, send 
email to

[EMAIL PROTECTED] and include in the body of the message help.


===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.

Re: [JAVA2D] Java 6u10 drawing performance

2008-04-10 Thread Dmitri Trembovetski


[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 devices found


  Indeed, currently hw accelerated pipeline is disabled on
  Intel adapters due to drivers problems.


I guess it's not from the 3D HW accelerator .


  Yep, as I suspected, it's not related to the d3d pipeline.


I also notice this in many other applets:

http://www.ditchnet.org/applets/scribble/
https://jdk6.dev.java.net/Java2DApplet.html

those are the screenshots:
http://nnaass.com/bug/overlep6.jpg
http://nnaass.com/bug/overlep5.jpg

Don't know what to do !


  Could you please try installing Firefox and see
  if it behaves differently there?

  Also, could you try the earlier Java release please?
  Just uninstall 6u10, and install whatever comes
  from java.com . See if the behavior is different
  on your system.

  I'm just trying to narrow down the issue before
  submitting a bug report.

  Thanks,
Dmitri

===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.

Re: [JAVA2D] Why does BufferedImage setRGB consumes memory?

2008-04-15 Thread Dmitri Trembovetski


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 go again (for those uninitiated Ken sends
  something like this every couple of months it seems).

  Just because you don't seem to be able to grasp
  and use effectively the concept of Color/Sample models,
  data buffer and raster doesn't mean others can't.

  Please continue to use MIS, it won't go away.

  The rest of us can use the flexibility and
  performance benefits BufferedImages offer.

  Thanks,
Dmitri



[EMAIL PROTECTED] wrote:

The memory-leaking behavior is not relevant for me
anymore since I changed the implementation to
MemoryImageSource already, but I am still curious if
anyone has an idea why setting pixels consumes that
much memory.



I would really recommend not using MemoryImageSource. Its an API from 
the java-1.1 days and its not recommended to use it any further. Its 
just there for compatibility reasons.


Setting large amount of pixels using setRGB is not a good practise, 
best way is to directly grab the raster from a BufferedImage:

[code]
byte[] 
data=((DataBufferByte)tex.getRaster().getDataBuffer()).getData() [/code]
this is for a byte-backed BufferedImage, but looks almost the same for 
an int[] one (which I recommend for best performance).


lg Clemems
[Message sent by forum member 'linuxhippy' (linuxhippy)]

http://forums.java.net/jive/thread.jspa?messageID=269294

=== 

To unsubscribe, send email to [EMAIL PROTECTED] and include in the 
body
of the message signoff JAVA2D-INTEREST.  For general help, send 
email to

[EMAIL PROTECTED] and include in the body of the message help.




===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.


===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.

Re: [JAVA2D] Small runnable test

2008-04-15 Thread Dmitri Trembovetski


  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 your random_fill method:
   import java.awt.image.DataBufferInt;
   ...
int data[] = ((DataBufferInt)(_bimg.getRaster().getDataBuffer())).getData();
for (int i = 0; i  data.length; i++) {
r = rand.nextInt() % 256;
g = rand.nextInt() % 256;
b = rand.nextInt() % 256;
data[i] = 0xff24 | r16 | g8 | b;
}

  (in real life examples you'll need to calculate
   the index for each element based on raster's
   data)

  Note that you can only cast to DataBufferInt here
  because you create an INT_RGB image.

  Also, getting the DataBuffer of a BufferedImage
  will forfeit any possibility of caching this image
  in video memory. For this particular case
  it doesn't matter that much since you're updating
  it on every frame, but it is something that needs
  to be considered.

  You can use DataBuffer to set pixels without
  having to reference the array directly - by using
  DataBufferInt.setElem(i, val). This will keep the
  possibility of the image being cached in vram, but
  may be slightly slower than direct array access
  approach.

  Thanks,
Dmitri


[EMAIL PROTECTED] wrote:

As requested, here a small runnable test. When you run it please start the JVM with 
something like -XX:NewSize=256m -XX:MaxNewSize=256m, elsehow the memory 
message wont be of much use.

Here comes the code:

---

import java.awt.BorderLayout;
import java.awt.Color;
import java.awt.Dimension;
import java.awt.Graphics;
import java.awt.Image;
import java.awt.event.ActionEvent;
import java.awt.event.ActionListener;
import java.awt.event.ItemEvent;
import java.awt.event.ItemListener;
import java.awt.event.WindowAdapter;
import java.awt.event.WindowEvent;
import java.awt.image.BufferedImage;
import java.awt.image.MemoryImageSource;
import java.util.Random;

import javax.swing.JButton;
import javax.swing.JCheckBox;
import javax.swing.JFrame;
import javax.swing.JPanel;

/**
 * Small example to compare MemoryImageSource and BufferedImage.
 * 
 * @author kif

 *
 */
public class SetPixelTest {
private static MyDrawingArea _mda;
private static boolean _use_mis = false;
private static JCheckBox _jcb_use_mis;

public static class MyDrawingArea extends JPanel {
private static int IMG_WIDTH = 256;
private static int IMG_HEIGHT = 256;

// either use a BufferedImage ...
private BufferedImage _bimg;

// ... or a MemoryImageSource
private Image _img;
protected int[] _pixels;
protected MemoryImageSource _mis;

public MyDrawingArea() {
setPreferredSize(new Dimension(400,400));
setBackground(Color.black);

_bimg = new BufferedImage(IMG_WIDTH,IMG_HEIGHT, 
BufferedImage.TYPE_INT_ARGB);
_pixels = new int[IMG_WIDTH*IMG_HEIGHT];
_mis = new MemoryImageSource(IMG_WIDTH, IMG_HEIGHT, 
_pixels, 0, IMG_WIDTH);
_mis.setAnimated(true);
_img = createImage(_mis);
}

public void random_fill() {
Random rand = new Random();
int r, g, b, rgb;

if (_use_mis) { // MemoryImage Source
int pixel_counter = 0;
for (int y=0; yIMG_HEIGHT; y++) {
for (int x=0; xIMG_WIDTH; x++) {
r = rand.nextInt() % 256;
g = rand.nextInt() % 256;
b = rand.nextInt() % 256;
rgb = 0xff24 | r16 | g8 | 
b;
_pixels[pixel_counter++] = rgb;
}
}
_mis.newPixels();
} else { // BufferedImage
for (int y=0; yIMG_HEIGHT; y++) {
for (int x=0; xIMG_WIDTH; x++) {
r = rand.nextInt() % 256;
g = rand.nextInt() % 256;
b = rand.nextInt() % 256;

Re: [JAVA2D] Native text rasterizer and translucent graphics

2008-04-15 Thread Dmitri Trembovetski


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 clip is
  another restriction. This is only the case for
  sw pipelines, the hw ones (ogl,d3d) can handle
  lcd AA text with complex clip.

  Thanks,
Dmitri




-phil.


[EMAIL PROTECTED] wrote:
Reposting from Swing  AWT forum since it was suggested that this is 
a better place.


It looks like the new native text rasterizer is not used when the 
current graphics composite is translucent. Here is the test app that 
i'm running on Vista SP1 with 6u10 b14:


[code]
package test;
 
import java.awt.*;

import java.util.*;
 
import javax.swing.*;
 
public class TextRenderingPanel extends JPanel {
 
private static Map desktopHints(Graphics2D g2) {

Toolkit toolkit = Toolkit.getDefaultToolkit();
GraphicsDevice device = g2.getDeviceConfiguration().getDevice();
Map desktopHints = (Map) toolkit
.getDesktopProperty(awt.font.desktophints);
// It is possible to get a non-empty map but with disabled AA.
if (desktopHints != null) {
Object aaHint = desktopHints
.get(RenderingHints.KEY_TEXT_ANTIALIASING);
if ((aaHint == RenderingHints.VALUE_TEXT_ANTIALIAS_OFF)
|| (aaHint == 
RenderingHints.VALUE_TEXT_ANTIALIAS_DEFAULT)) {

desktopHints = null;
}
}
return desktopHints;
}
 
@Override

protected void paintComponent(Graphics g) {
Graphics2D g2d = (Graphics2D) g.create();
   
Map desktopHints = desktopHints(g2d);

if (desktopHints != null  !desktopHints.isEmpty()) {
g2d.addRenderingHints(desktopHints);
}
   
g2d.setColor(Color.white);

g2d.fillRect(0, 0, getWidth(), getHeight());
g2d.setColor(Color.black);
g2d.setFont(new Font(Segoe UI, Font.PLAIN, 12));
g2d.drawString(Text rendering, 10, 30);
g2d.setComposite(AlphaComposite.SrcOver.derive(0.5f));
workaroundBug6576507(g2d);
g2d.drawString(Text rendering, 10, 60);
g2d.dispose();
}

public static void workaroundBug6576507(Graphics graphics) {

Font font = graphics.getFont();
font = font.deriveFont(font.getStyle(), font.getSize2D());
graphics.setFont(font);
}
 
 
public static void main(String[] args) {

SwingUtilities.invokeLater(new Runnable() {
@Override
public void run() {
JFrame frame = new JFrame(Text rendering);
frame.add(new TextRenderingPanel(), BorderLayout.CENTER);
frame.setSize(300, 200);
frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
frame.setLocationRelativeTo(null);
frame.setVisible(true);
}
});
}
 
}

[/code]


Running this you can see that the 'e's on the second line of text do 
not come from the same rasterizer as the 'e's on the first line of 
text. Is this the expected result, and if so, would i have to create a 
temporary image, render the full-opacity text there and then render 
that image back (with translucency) to get consistent rendering?


Note that I have to use deriveFont as the workaround for bug 6576507 
as suggested in [1]. Doesn't look like the fix in JDK 7 was backported 
to 6u10.


Last thing - letter 'g' is one pixel narrower than in the real 
native rendering (from the title pane of the same frame).


Thanks
Kirill
[1] http://forums.java.net/jive/thread.jspa?threadID=28226
[Message sent by forum member 'kirillcool' (kirillcool)]

http://forums.java.net/jive/thread.jspa?messageID=268874

=== 

To unsubscribe, send email to [EMAIL PROTECTED] and include in the 
body
of the message signoff JAVA2D-INTEREST.  For general help, send 
email to

[EMAIL PROTECTED] and include in the body of the message help.


===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.


===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.

Re: [JAVA2D] update 10 and Intel drivers

2008-04-18 Thread Dmitri Trembovetski


  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 performance-wise (and by OK I mean they
  show performance similar to 4 years old low end Nvidia
  board), but the thing blocking us from enabling the
  pipeline is some severe driver stability bugs (like
  rebooting the system on heavy load), and rendering
  quality issues.

  We have filed the bugs with Intel, they're working on
  them but at this point there's no ETA for the fix.

  Even when they do fix it, then we would only enable
  the pipeline conditionally for this specific driver,
  and after some extensive testing, of course.

  Thanks,
Dmitri
  Java2D Team

[EMAIL PROTECTED] wrote:

I saw in another thread (http://forums.java.net/jive/thread.jspa?threadID=39219tstart=0) 
that some Intel hardware is disabled. Dmitri said, Indeed, currently hw accelerated 
pipeline is disabled on Intel adapters due to drivers problems.

Can you say a bit more about this - is it likely to be fixed in future releases 
of Java or will it need Intel to issue new drivers. Is there a list of which 
adapters are affected?

Peter
[Message sent by forum member 'peterhull90' (peterhull90)]

http://forums.java.net/jive/thread.jspa?messageID=269906

===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.


===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.

Re: [JAVA2D] Performance regression in 6u10 b22

2008-04-19 Thread 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

[EMAIL PROTECTED] wrote:
After installing b22 on two Windows machines i see a performance regression of about 15-20% on the same internal benchmark that i'm running. The benchmark is just stressing Substance look-and-feel on different control types and includes a lot of Java2D operations, composites, translucencies, text painting, gradients etc.

The code is the same between b21 and b22 and it's not something that i can post
in the forum. To reproduce you would need to download the Substance
distribution and run the test.perf.PerformanceSuite. It has a warmup stage when
it's repainting the same frame 10 times, and then paints it once again, timing
the painting time. It does so on three tabs and just prints out the average
painting time. The code is the same, the OS is the same, but the 6u10 build is
different.

Kirill
[Message sent by forum member 'kirillcool' (kirillcool)]

http://forums.java.net/jive/thread.jspa?messageID=270098

===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST. For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.

Re: [JAVA2D] Performance regression in 6u10 b22

2008-04-19 Thread Dmitri Trembovetski


[EMAIL PROTECTED] wrote:

Hi, Dmitri

The output of trace_level:

[I] OS Version = OS_VISTA or newer
[E] D3DPPLM::CheckForBadHardware: found matching hardware: VendorId=0x8086 
DeviceId=0x
[E] D3DPPLM::CheckForBadHardware: bad hardware found, device disabled
[E] D3DPPLM::GDICheckForBadHardware: no suitable devices found


  OK, you have an Intel chip. The d3d pipeline is
  disabled for all Intel boards so the regression
  is probably not related to the d3d changes in this
  build.

  Then it is likely caused by this fix, although I don't
  quote see how
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6679308

  Does your code render to translucent images much?


I'll try to install b21 tomorrow and run with that d3d flag.


  The flag won't do anything because the d3d pipeline isn't enabled
  on your system anyway.

  BTW, you can save the current build (just copy the jdk dir
  somewhere) before reinstalling, so that you can compare them
  side by side.

  We'll try your benchmark inhouse as well.

  Thanks,
Dmitri




Thanks
Kirill
[Message sent by forum member 'kirillcool' (kirillcool)]

http://forums.java.net/jive/thread.jspa?messageID=270144

===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.


===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.

Re: [JAVA2D] JAVA2D Huge Performance Drop from 6u5 to 6u10

2008-04-22 Thread Dmitri Trembovetski


  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 complete test case?

  Thanks,
Dmitri
  Java2D Team



[EMAIL PROTECTED] wrote:

Hi, there I'm writing a program that draws to a volatile Image by setting every 
pixels manually every frame.

When I tested my program with java 6u5 I got 460-500 fps on average, however with java 6u10 the performance drops by almost 50%, from 450 to 240. I have done several test runs with both versions, the results have been consistent throughout the test. 


this is my pc :
Athlon xp 2200+,
768 Ram,
Windows XP

This is the part of the codes that I'm working on that initializes and renders 
the volatile Image

code begins here

VolatileImage vi;
...
vi = mainFrame.createVolatileImage(256*pixelSize, 192*pixelSize);
vi.validate(mainFrame.getGraphicsConfiguration());
...
//ImgA is a BufferedImage
vi.getGraphics().drawImage(imgA,0,0,256*pixelSize,192*pixelSize,null);
mainFrame.getGraphics().drawImage(vi,ins.left,ins.top,null);

This part is for the bufferedimage (this is what I do to gain access to the 
pixels)

BufferedImage imgA;
...
imgA = new BufferedImage(256,192,BufferedImage.TYPE_INT_RGB );
pixelsA = ((DataBufferInt) 
((BufferedImage)imgA).getRaster().getDataBuffer()).getData();
...
for(int i = 0 ...)
   pixelsA[i] = . (performs pixel manipulation)

code ends

My english isn't that good, hopefully I can get my point across :).
[Message sent by forum member 'bonbon' (bonbon)]

http://forums.java.net/jive/thread.jspa?messageID=270562

===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.


===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.

Re: [JAVA2D] Performance regression in 6u10 b22


  Another observation we have made is that it appears
  that Substance Look and Feel does lots of unaccelerated
  rendering - meaning, rendering to un-accelerated
  destinations.

  Unfortunately this affects performance negatively when
  the D3D pipeline is enabled: first, we do most of the rendering
  into BufferedImages, then they are blitted into the
  accelerated destination (Swing back buffer). This last
  operation is known not to perform well on most boards
  (see another thread in this forum).

  I would suggest to reduce the number of operations you do
  to BufferedImages. If you use some temp. buffered images
  for rendering, consider changing them to translucent
  volatile images (assuming you don't need access to pixels).
  This will not affect performance when these are not
  accelerated but will help when they are.

  Thanks,
Dmitri


Phil Race wrote:

Then it is likely caused by this fix, although I don't
quote see how
  http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6679308

We did a bit of testing and one necessary correctness change
in this bug fix was made in SrcOver software blit and fill loops.
ie I know exactly which line of code makes the performance
change come and go in your app, but its not something we can undo.

The strange part of it is that the change is just a compile time
macro so that for opaque destinations, there should be no runtime cost.
ie logically if anything it should lead to less work, not more.
And for non-opaque destinations, it should be exactly as it was before.

Not sure why it affects your app - we couldn't make it show up
any of the tests in J2DBench2. Either the Microsoft compiler
is doing something that adversely affects the generated code,
or perhaps the different results in the opaque dest case cause
more work to be needed, but it seemed likely you were hitting
the first case.

-phil.

Dmitri Trembovetski wrote:

[EMAIL PROTECTED] wrote:

Hi, Dmitri

The output of trace_level:

[I] OS Version = OS_VISTA or newer
[E] D3DPPLM::CheckForBadHardware: found matching hardware: 
VendorId=0x8086 DeviceId=0x

[E] D3DPPLM::CheckForBadHardware: bad hardware found, device disabled
[E] D3DPPLM::GDICheckForBadHardware: no suitable devices found


  OK, you have an Intel chip. The d3d pipeline is
  disabled for all Intel boards so the regression
  is probably not related to the d3d changes in this
  build.

  Then it is likely caused by this fix, although I don't
  quote see how
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6679308

  Does your code render to translucent images much?


===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.


===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.

Re: [JAVA2D] Performance regression in 6u10 b22


  Hi Kirill,

[EMAIL PROTECTED] wrote:

Dmitri,

I did not see any change (on unaccelerated pipeline) between these two ways to 
create an offscreen image:

[code]
BufferedImage image = new BufferedImage(width, height,
 BufferedImage.TYPE_INT_ARGB);
Graphics2D graphics = (Graphics2D) image.getGraphics().create();
graphics.setColor(new Color(0, 0, 0, 0));
graphics.setComposite(AlphaComposite.Src);
graphics.fillRect(0, 0, width, height);
graphics.dispose();
return image;
[/code]

and 


[code]
GraphicsEnvironment e = GraphicsEnvironment
.getLocalGraphicsEnvironment();
GraphicsDevice d = e.getDefaultScreenDevice();
GraphicsConfiguration c = d.getDefaultConfiguration();
BufferedImage compatibleImage = c.createCompatibleImage(width, height,
Transparency.TRANSLUCENT);
return compatibleImage;
[/code]
Substance uses image caches to speed up the painting. So the two code 

 examples above play a very central role in the Substance painting
 pipeline. Release 4.3 uses the first approach. Should i use the second
one, and if not, what is the correct way to create translucent volatile 

 images that can be cached and rendered multiple times?

  In both cases above you create a BufferedImage, not a Volatile one.

  To create VolatileImage, you'd need to use
  GC.createCompatibleVolatileImage(). (you'd need to add some extra code
  to validate them before you use them though, but for testing
  purposes, just validate them once when you create)

  And even if you switch to VIs, for un-accelerated case (like on
  your Intel system) there will be no difference.

  Nimbus LF uses VIs for caching, and they saw pretty good
  performance improvement from that with the d3d pipeline
  enabled.

  Caching makes sense if you don't change the contents of the cache
  much. Does your code update the cached images often?

  If you run your benchmark on hw-accel pipeline with
  -Dsun.java2d.trace=count, you'll see that out of
  about 500.000 calls more than half were rendered into
  a buffered image.

  One perf.-related suggestion: make sure you don't clear the
  background (fillRect) with antialiasing enabled (a common
  mistake). So if your components need to clear the bg first,
  unset the AA, clear, then set it back.

  Thanks,
Dmitri




Thanks for looking into this.

Kirill
[Message sent by forum member 'kirillcool' (kirillcool)]

http://forums.java.net/jive/thread.jspa?messageID=270836

===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.


===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.

Re: [JAVA2D] Performance regression in 6u10 b22

[EMAIL PROTECTED] wrote:

Hi, Dmitri

In both cases above you create a BufferedImage,
not a Volatile one. To create VolatileImage, you'd need to use
GC.createCompatibleVolatileImage(). (you'd need to
add some extra code to validate them before you use them though, but
for testing purposes, just validate them once when you create)

Correct me if i'm wrong, but shouldn't i be validating a cached volatile image
befoer every use?

Yes, VI should be validated before every use.
I'm just saying that for a quick test you don't
need to do that.

Nimbus LF uses VIs for caching, and they saw
pretty good performance improvement from that with the d3d
pipeline enabled.

I don't believe that we have access to sources of 6u10 in general, and of Nimbus in particular.

I understand - I was just pointing out that it is
beneficial to use hw acceleration if available - we
have a success story to prove it =)

Caching makes sense if you don't change the
contents of the cache much. Does your code update the cached images
often?

Once the image gets into the cache, its contents are never touched.

Then in theory it should be fast once the cache is filled
since images can be cached in textures- but according to the
primitives log there's lots of unaccelerated rendering going on -
may be the benchmark basically only catches the cache fill
phase?

One good thing about VolatileImages is that they don't
increase the footprint of the application (if they reside
in vram).

One perf.-related suggestion: make sure you don't
clear the background (fillRect) with antialiasing enabled (a
common mistake). So if your components need to clear the
bg first, unset the AA, clear, then set it back.

I will look at the code to make sure that i don't do that.

Thanks for the tips.
Kirill
[Message sent by forum member 'kirillcool' (kirillcool)]

http://forums.java.net/jive/thread.jspa?messageID=270840

Re: [JAVA2D] JAVA2D Huge Performance Drop from 6u5 to 6u10


  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 b22, as for the test case, I wrote a small 
program that update every pixels as fast as possible using VolatileImage and 
measure the performance by  frames per second

result (VolatileImage):
Java 6u5  
1300+ fps 


Java 6u10b22
450+ fps

result (BufferStrategy):
Java 6u5  
1200+ fps 


Java 6u10b22
400+ fps

the source code of the test program that I included is basically the same thing 
as my actual program, the drawing routine is an almost exact copy of the actual 
one minus the program mechanics to simplify things thus this should be able to 
reproduce the problem.

Also with b22 I noticed that under certain conditions such as pixel 
manipulation, Java2D suffers huge performance hit when it gains access to the 
pixels (regardless of image type)  yet outperforms the previous version (6u5) 
in all 2D operations (except pixel manipulation)

here is the output log

[I] OS Version = OS_WINXP Pro
[I] CheckAdaptersInfo
[I] --
[I] Adapter Ordinal  : 0
[I] Adapter Handle   : 0x10001
[I] Description  : NVIDIA GeForce 7300 GT
[I] GDI Name, Driver : \\.\DISPLAY1, nv4_disp.dll
[I] Vendor Id: 0x10de
[I] Device Id: 0x02e2
[I] SubSys Id: 0x0
[I] Driver Version   : 6.14.11.6921
[I] GUID : {D7B71E3E-41A2-11CF-B978-0B2003C2CB35}
[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

code:-

import javax.swing.*;
import javax.imageio.ImageIO;
import java.io.*;
import java.awt.*;
import java.awt.event.*;
import java.awt.image.*;
import java.awt.image.BufferedImage;
import java.awt.Graphics2D.*;
import java.nio.IntBuffer;

public class test
{
private JFrame mainFrame;
private VolatileImage vi;
private BufferedImage im;
private int[] pix;
private Insets ins;
private long st,en;
private int colour,fps = 0;

public test()
{
mainFrame = new JFrame();
mainFrame.setVisible(true);
mainFrame.setIgnoreRepaint(true);
ins = mainFrame.getInsets();
mainFrame.setSize(new 
Dimension(256+ins.left+ins.right,192+ins.top+ins.bottom));
mainFrame.setLocationRelativeTo(null);
mainFrame.setTitle(Test);
mainFrame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);

vi = mainFrame.createVolatileImage(256, 192);
vi.validate(mainFrame.getGraphicsConfiguration());

im = new BufferedImage(256,192,BufferedImage.TYPE_INT_RGB );
pix = ((DataBufferInt) 
((BufferedImage)im).getRaster().getDataBuffer()).getData();

run();
}

public void run()
{

st = System.nanoTime();

while(true)
{
for(int i=0;i192*256;i++)
{
pix[i] = colour;

colour++;
//colour = 0x;

//if(colour0x)
//  colour = 0;
}

vi.getGraphics().drawImage(im,0,0,256,192,null);

mainFrame.getGraphics().drawImage(vi,ins.left,ins.top,null);

fps++;

if((System.nanoTime()-st)  1000*1000*1000)
{
System.out.println(FPS : +fps);
st = System.nanoTime();
fps = 0;
}
}
}

public static void main(String[] args)
{
new test();
}
}
[Message sent by forum member 'bonbon' (bonbon)]

http://forums.java.net/jive/thread.jspa?messageID=270705

===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
[EMAIL

Re: [JAVA2D] JAVA2D Huge Performance Drop from 6u5 to 6u10