Hi Ken,
Ken Warner wrote:
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...
I think such approach has a number of disadvantages. For example,
you can't change the setting at run time if you need to, and
you will not have a fine granularity - all of your
images will have the same threshold, which may or
may not be desirable.
Not to mention that these properties are Sun
implementation-specific.
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?
First, please forget about MemoryImageSource, this is
a legacy API from Java 1.1 days. Just don't use it.
Second, all these image types serve different purposes.
See http://weblogs.java.net/blog/chet/archive/2004/08/toolkitbuffered.html
In other words, get rid of all the above and put the functionality into
ordinary Image.
I believe it would be pretty hard to make such
"everything for everyone" type of image, since different
uses place different restrictions.
For example, you would want to have hardware-accelerated
rendering to such image, right? That means that it will
have to be placed in video memory. But suppose that someone
wants to work with image's pixels directly - that would be
extremely slow for video-memory-based images.
And so on.
I am not saying that the current scheme is perfect,
but I don't think having single image "type" would
make much sense.
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...
What aspects of BufferedImages do you not like in particular?
Thank you,
Dmitri
Java2D Team
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".
