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. 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 think someone already filed an RFE for that. > You can find if an image is currently cached by > > using Image.getCapabilities(). > > > > Okay, then ALL of my images aren't. The images > alternate back and forth between using the direct > ImageCapabilities, which seem to return false > _hardcoded_, and some > CachedDirectDrawImageCapabilities (or what it was), > whose source isn't in the JDK. They all return false > for both. (I edited the original post slightly, but you apparently reply using the email interface..) I meant that first the BI has Capabilities of class "java.awt.ImageCapabilities", then it becomes "sun.awt.image.CachingSurfaceManager$ImageCapabilitiesGc".. What does this signify? However, they return false for both Accelerated and TrueVolatile in both cases. Question here: When I draw onto the "Swing surface", the Graphics object that I'm presented with in the paint method of e.g. a JComponent, will BIs become accelerated? Is that Graphics2D instance a VolatileImage or a BufferStrategy? I would think so, how else could this stuff be truly accelerated? .. but I don't quite get the logic.. Or maybe it is something else entirely? > > Frustration point: See - I don't know if I manage > to convey this - but coming from the Commodore 64 (!) > to this stuff here is hellish. You hide way to much > details, and basically state "oh, let just us handle > it - You just relax, we know this BEST!". But I want > to be part of this discussion, so to speak. I e.g. > really can't fathom the point of hiding away Swing's > BufferStrategy, when that obviously would be the good > way of making Swing fast. If it isn't, then you > should let me too have access to the better way you > use. And I understand even less why I can't at least > override your default, by setting it. > > > > I understand. What I don't get is why you use > swing if you're talking about > 'fps' and need for speed. Swing's repainting model > isn't suited for this kind of graphics. > If you want more control over rendering you should > just use BufferStrategy > and do your rendering. Well, I want Swing for widgets and LayoutManagers and such, and then I want a hole in the middle where I can draw, really really fast. But this isn't quite what we're talking about, is it? The BufferedImages and such are still "magicy"? This is probably a dumb question, but I don't get it: Is Swing still a free-standing library, as it was intially? (According to O'Reilly's Java2D 2nd ed. One could download it separately - it only utilized AWT). That would ultimately mean that one could run Sun's Swing on top of another JVM that had AWT fully implementer. Or has the borders become blurry, with Swing doing native, or at least invoking behind-the-scenes stuff with the SunGUIToolkit or whatever those classes are called? Follow-up: At which point is the interface between AWT and Swing? What is the latest point where I am "on the low level", drawing-wise? Frame.paint()? JFrame.paint()? Because at JComponent.paint(), Swing has somehow taken over, right? > > >> After the ImageIO reading, I'd love if I could > >> state to the BI that "The data has changed, > re-copy > >> the current data to backing vram/volatile > >> image/whatever" (Or at least that the ImageIO > itself > >> did this magically, since everything else of the > BI > >> stuff is magical). > >> Like I mentioned, we may be able to use > >> setAccelerationPriority for that. > > > > It won't be accelerated until the second draw, > which means one slow draw. > > You misunderstood. If you set the acceleration > priority to 0 the > image will be accelerated on he first draw. That > is, when you call > drawImage it will first be uploaded into a texture > and then > copied from that texture (or rather texture mapped) > into the > destination. Some time will be spent uploading the > image into the texture > but its insignificant. Yeah, that was what I meant, though.. Like the FIRST drawing will get the hit of copying the BI to the VI, before being drawn. It would be nice if even that could be avoided. > > I don't even understand the problem of this. A > database-backed object will become stale when > changing the data, and the change won't become > visible/permanent in the database unless we take > appropriate action. We understand this. A accelerated > BI can become "stale" too. I think we'd manage to > understand that too. > > > > May be you do, but many others won't and will > wonder why their image is > not updated on the screen. > Since this managing of > images isn't part of the > API we can't guarantee how other JVM providers will > handle this. Yeah, okay. I've always thought that the concept of "secretly" or "magically" doing this managing was a bad idea. Why not instead make a new extension to BI that was explicitly called ManagedImage. Thus you could make these effect explicit, by stating that if you grab the data buffer and change it, you must invoke such and so and blah blah blah - all this would be OBVIOUS even. > In order to provide this api we'll have to expose > and document the > internal management mechanism which may not be a > bad thing, but > it will limit us in our future attempts to improve > it. > For example, Direct3D doesn't really tell you > what's happening under > the hood when you create a "managed texture". They > just tell you > in which scenarios you should use it. Same with us. I feel I don't have access to any other stuff. You've made BIs magic, but not made this explicit. > >> My thought: It would be good if the managed image > >> aspect became a bit more explicit: In addition to > >> flush(), which obviously is exactly such an > explicit > >> method denoting "I won't be using this BI for > drawing > >> for a while (or ever again), please ditch the > backing > >> VRAM", also an "I'm going to begin using this > image > >> again, please allocate backing VRAM", and finally > a > >> "The data of this image has changed - re-copy to > >> backing VRAM, please" method. Maybe also a "is > this > >> BI still managed, or have I done something that > >> defeats it?", in which case I could invoke the > former > >> method. Or maybe just combine the two latter into > "if > >> I've done something to defeat acceleration, then > now > >> re-copy the data into the backing VRAM". > >> > >> Understood. > > > > Thanks! Might some of it plausibly be implemented > too? At least be taken up for discussion? > > I would like to have something like this added in > 7, but > not sure if I'll have time to get to it. > We'll see. > Could you please file an RFE with this request? > "need better management of hw acceleration of images" > or something > to that effect. I could file it myself but it's > usually better > if someone from outside files it so that it has > more "weight". This is SERIOUSLY not the case! This is much better coming from you. I'm a worthless customer (seriously), you're "at least" a developer on the actual team! RFEs seldom lead anywhere, IMHO. > > Is this actually what you do for BIs, or do you > have some fingers beneath the hood? > > It's very similar. You can take a look at it > yourself if you like, > java is opensource =) > http://hg.openjdk.java.net/jdk7/2d-gate/jdk/file/ > Specifically, the logic for caching images is in > > ttp://hg.openjdk.java.net/jdk7/2d-gate/jdk/file/cd88b4 > ad7f25/src/share/classes/sun/java2d/SurfaceDataProxy.j > ava > and > src/windows/classes/sun/java2d/d3d/D3DSurfaceDataProx > .java . > The only difference is that that code operates on > SurfaceDatas > which is where the pixels are stored instead of > "Bufferedimages". > It's a little hard to see the logic in just those > two files, > but the general idea is exactly the same. Thanks a bunch, I will look into it! I "just" need to connect the dots regarding a) What type of surface the Graphics2D object presented to the different paint() methods is, b) How the internal BufferStrategy stuff of Swing works, and c) How a and b interacts with BIs and VIs. And possibly also what the BufferStrategy really is.. Thanks again, Endre [Message sent by forum member 'stolsvik' (stolsvik)] http://forums.java.net/jive/thread.jspa?messageID=298816 =========================================================================== 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".
