Well, lets clarify/assume a few things. You have some data source, constantly producing data, right? While that data source happily produces data the user is also looking at a representation of that data, right? And the user can interactively select (scrolling, zooming) which portion of the data he/she gets a representation of?
Ok, first, I am not a big fan of rendering and rasterizing (drawing to an image) the data in the backgrond in such a case. For at least two reasons: Zooming on already rasterized data doesn't work well, so for zooming it is required to freshly rasterize that data. Second, if the plot is indeed very large you can not fully predict to which area the user might scroll next. So you can't reasonably well guess which area should be preferentially rendered in the background. Because of this two issues, a lot of CPU power used for background rendering is just wasted, since you render something you can't use. So, instead of rendering in the background, organize/store the incomming data in a way that it is easy to render in the background (in a thread). This, for example, might include to already decompose the data into primitive graphic elements like lines. You don't actually draw such lines, you just store easy to process information that you would draw a line. And provide a locking mechanism on the data, so that the maintenance of the data and the rendering (see below) are properly synchronized. Further, if the plot is really so large, spatially organize that graphic element data in the background in a way that you can quickly find all data within a particular rectangular 2D region (quadtree). If you have many overlapping graphic elements you might even want to organize the data in three dimensions (octree), so that you can easily cull details when the user has zoomed out very fare (because in this case many details would anyhow be lost when rendering the data). Now to the user interaction and actual rendering. You create an own Swing component based on a JComponent or JPanel. Creating an own Swing component has often been document, I won't go into this. Just make sure you get the basics and the nastier details right :-) Also implement the Scrollable interface. I assume you put that component in a JScrollPane. The paintComponent() method of your component will be called when Swing thinks your component or a part of your component needs to be redrawn. The key here is "part of your component". Swing indicates what part needs to be redrawn with the clipping region (don't forget to take the Graphics2D origin into account, it might not always be 0,0). So in your paintComponent() you use that information (and the current zoom factor) to identify the part of your graphic element data that needs rendering. That part should be much less then your whole data. Then, right in paintComponent() you render it to the provided Graphics2D. I assume you have some extra buttons for zooming in or out (or some mouse events). Anyhow, whenever the zoom factor changes you remember the new zoom factor, then call repaint(). At some point in time repaint() will result in a call to paintComponent(). And since your paintComponent() takes the zoom factor into account (well, it should), it will render the plot with the new zoom factor. Also, whenever the incomming data has changed significantly, you call repaint, too. Don't do it to often, and don't do it for every tiny change. Accumulate a bunch of changes, then call repaint(). However, if you really think you need 15fps and every tiny change in the data needs to be immediately visible, than forget everything I wrote and change to active rendering. That's the basic architecture. If that is still not responsive enough, consider caching the renderings you did in paintComponent() in BufferedImages. And before you render some area you check your cache if you have already all or parts of that area in your cache. If you have, you just copy that part from the cache to the screen. You need proper cache management, like remembering which zoom factor was used for a particular rendering, or if the incoming data would invalidate a cached rendering. Careful planning, a well designed data structure, knowing Swing's paint mechanism (with all its barely documented idiosyncrasies), a clear understanding of world, component and screen coordinate systems, and probably a thousand odds and ends are needed to make this fly. Or you drop that Java2D junk, where you are never sure if you get hardware acceleration or not, and use some commercial data visualization system or write directly for a particular OS and native graphics system, so you are not at the mercy of a VM with rubbish documentation. [Message sent by forum member 'ewin' (ewin)] http://forums.java.net/jive/thread.jspa?messageID=301687 =========================================================================== 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".
