> [EMAIL PROTECTED] wrote:
> > This is a good discussion..
> >
> >> [EMAIL PROTECTED] wrote:
> >>> Explicitness is the way, IMO.
> >> Again, I disagree. All we can do is explain how
> >> _Sun_'s JVM
> >> behaves. We definitely should have better
> >> documentation
> >> (like performance guides and such), but stuff like
> >> this doesn't
> >> belong to the specification in my opinion.
> >
> > I meant explicitness in the code, access to "lower
> levels" or at least methods that query/specify
> aspects of this - NOT explicitness for this stuff in
> the specs.
>
> You can't have "access to lower levels" unless you
> have a public
> API, which will be part of the spec.
Yes, I know. And that's what I mean: Read through (this post)!
> What I meant about "hacky" is exactly that I think
> the "dual draw for acceleration" is really hacky,
> and is in no way suitable for spec addition!
>
> I'm not sure why you consider this hacky, it's
> just a
> heuristic for detecting when image is copied from
> "enough" times. Two times works just fine for 99% of
> the
> cases.
I think you misunderstand me. That's all fine and all, but such heuristics
can't be part of a spec. And I think we agree on that. That's sincerely not the
point.
> Another way to test is to run your application with
> -Dsun.java2d.trace=log
> and see what is being printed when you call
> drawImage for these images.
Excellent - I've been hoping for something like that.
Actually, what I've been longing for, is some kind of callback interface, or a
kind of logger/listener interface, or a set of such interfaces, that one could
register with the Java2D/AWT engines - basically like on registers listeners
with any component. The engines would then invoke these methods. It would
probably have to be some generic stuff, as one can't foresee all types of
"events" that could happen, so possibly just event string Id, event description
string (a non-dynamic string), and event objects ("sources"), which e.g. would
be the BI instance and its corresponding VI instace, or e.g. the JFrame and its
Graphics2D object, etc. Everything was logged, depending on what type of
interfaces you registered (or maybe which event id types you requested). This
would give huge options for folks like me.
> What GraphicsConfiguration do you pass to
> getImageCapabilities?
The one I get from its containing component's paint method:
this.getGrahicsConfiguration().
> Swing's backbuffer (which is what your component
> renders to) is either
> a VolatileImage or BufferStrategy (depending on
> some factors),
> so yes, it should be accelerated in most cases.
Well - judging from that ImageCapabilities object, it never is. The accel and
truevolatile always return false. But it goes rather fast, though. I fill a
1920x1200 surface with a random color, and paint a 100x100 BI (the one that
continuously return false/false) 100 times on random locations within that
frame. This takes 12-15 ms. The repaint time, the time between exit of paint
and enter again (paint() invokes repaint()), is ~0.5 ms.
> Because when BufferedImage became "managed" there
> were already
> thousands of applications out there, which
> instantly benefited
> from it becoming "managed". If we added a new class
> those
> applications will have had to be rewritten to take
> advantage
> of this new "managed image".
This I do understand.
So that's why I suggested an alternate approach, where the BIs that was
instantiated with all the methods that existed prior to the managed images
idea, were managed as you do: "do fast", as long as you don't get the actual
data.
HOWEVER, you could have introduces some other means for getting BIs. Even just
a new constructor. OR a new ManagedImage that extended BI. THESE images could
have behaved more explicit in regard to how they were managed, and also lets
its data be accessible even though it was managed, on the risk that the user
would have to understand that he had to "revalidate" the data after a change.
Thanks for your help,
Endre.
[Message sent by forum member 'stolsvik' (stolsvik)]
http://forums.java.net/jive/thread.jspa?messageID=299190
===========================================================================
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".
