Hi Dmitri,

I think that making runtime parameters available programatically -- i.e. from 
an applet or an app -- is very useful.

I think it is just irritating to have to "prime" or trick the VM into a 
particular state.

Just let us set an acceleration flag an then deal with the consequences...

Also, we have BufferStrategy, MemoryImageSource and VolitileImages.  Why so 
many different ways to make fast images.  In fact why not just make ordinary 
images as fast as possible rather than requiring a particular set of classes 
and methods to do so?

In other words, get rid of all the above and put the functionality into 
ordinary Image.

And BufferedImage -- boy is that a hairball.  I think whoever did BufferedImage 
did way too good a job.  Remember the KISS principle.  Keep It Simple Stupid...

Ken

Dmitri Trembovetski wrote:
[EMAIL PROTECTED] wrote:

Thanks Fred. Great information.

I tried -Dsun.java2d.accthreshold=0 as you described. It works fine
when I have enabled the opengl pipeline using
-Dsun.java2d.opengl=true, however if I have the d3d pipeline enabled
with -Dsun.java2d.d3d=true then I seem to loose acceleration for all
loaded images. Normally the d3d pipeline is just about as fast as the
opengl one. I have tried most of the other runtime flags, in many
combinations, however any time I have accthreshold set to 0 with the
d3d pipeline enabled my images are very slow to draw.


 This is surprising, it should behave exactly the same for
 both pipelines.

So I think I am going to go for the workaround. Which surface should I
render the image to to force it to become managed? I do not want to
render to the screen (other things are going on). Can I just render to
another Buffered Image? I don't think so, I think I need to render to
an accelerated surface. Is there a 'proper' one to use?


  As mentioned in my other email, you should render them
  to an opaque VolatileImage.

  I wonder if we could provide a mechanism for specifying
  this behavior. Like, if the acceleration priority of an
  image is 1.0, then we could try to cache it right away
  without waiting for the threshold.

  We do something like this even now - if acceleration
  priority is set to 0.0, we never attempt to accelerate
  the image.

  Thanks,
    Dmitri
  Java2D Team


Regards,

Alistair
[Message sent by forum member 'alnrelly' (alnrelly)]

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

===========================================================================

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

Reply via email to