Chet Haase

Also note: when you do use a BufferedImage (which, for instance, is created for you if you load images via ImageIO, or which you can create from scratch in various ways), then you should pass null as the ImageObserver argument to drawImage:

drawImage(bufImg, x, y, null);

Chet.

Congratulations to the winners (Dang! I was hoping I'd be a winner!) and thanks for the discussions this week.

Maneesh: We may check in occasionally, but we don't get usually get a lot of time to peruse and respond on forums. Instead, you might want to tune in our our Java blogs (mine is in my .sig below, Romain's is http://www.curious-creature.org); we discuss a lot of core Swing, Java, graphics, Java 2D, performance, animation, and other relevant (and irrelevant) topics there. There are a lot of other good Java blogs to tune into as well. Check out http://java.net for links to interesting Java articles, blogs, and projects, and http://javadesktop.org for links to Desktop Java-specific links. And be sure to check out the book site as well (http://filthyrichclients.org), where we host all of the demos from the book (82 at last count), the 2 animation utility libraries, and related information.

Good luck with your Desktop Java coding efforts. May your code be clean and your apps be filthy.

Chet.

The effects in the book are not specific to particular component types, but are rather general graphical and animated effects that can be applied to any Swing component or the overall application. Check out some of the demos on the book's site (see my .sig below) or the outline of the book (also on the book's website) to get a better idea of what's in store.

Chet.

The questions you ask can be answered by books, or a series of articles at the least. It's not possible to answer the questions in a simple forum thread (or at least it would take more time than I have for this answer...). You might check out some of the existing references for Swing (including the online tutorial and various articles).

Chet.

It depends on the size and scope of your application, and whether it needs, or can take advantage of, the facilities provided by those frameworks. The demos that we did for the book don't use any app framework (Eclipse RCP, NetBeans Platform, or the Swing App Framework). But our demos are intentionally small and focused in scope, so there wasn't much point to it. Also, the demos needed to focus on the individual effects that they were trying to present, and dragging in orthogonal issues like RCP would have detracted from the core issues.

Slightly larger apps (or even our demos) could benefit from simple usage of somelike like the Swing Application Framework, to handle such basic things as app/frame setup and teardown. For example, the boilerplate code in all of my demos where I post some Runnable that calls createAndShowGUI() on the Swing event thread is made easier by the Swing framework's Application facility.

Much larger apps would benefit from the module and update facilities (among other things) in the RCP alternatives.

But, as I said, it depends on your app.

Chet.

Patrick,

I think I'm following this more now. Here's my take on it:

- As you said, you probably don't want to install a RepaintManager as a plugin provider. I think there's one per top-level window, so it'd be a bit rude to install yours when the rest of the app might want something different. It would be like staying at someone's house for a weekend and painting their house purple because you happened to like it.

- You could buffer your own component (thus getting buffering at the component level, instead of at Swing's window level), but you're starting to blow memory and buffer management headache that you really don't need to.

- You should (I think) use the clip. Whenever something changes in your component that requires you to tell Swing to repaint, the easiest way to cause the repaint is to call repaint() on the component. That will cause the entire component to redisplay itself. But if you only need to repaint a small portion of that component, then call repaint(x, y, w, h) instead. This will cause Swing to set the Clip on the Graphics object prior to calling the paintComponent() method. And if you're clever about checking the clip, you can avoid repainting items that fall outside of the clip. (Note that this optimization makes the most sense if the items not rendered are actually expensive to render, otherwise it may not buy you much since Java 2D can draw stuff pretty fast). There's more about this in the "Use the Clip" section of Chapter 5, for those that have the book. But that's the basic approach: only schedule repaints for the areas that need it, and pay attention to the Clip that Swing hands you.

Chet.

For production softwares, what kind of richness Swing can bring that Web 2.0 frameworks wont be able to ?

You might want to check out our answers in various other threads in this forum - this same question has been asked in a few different ways in the last few days. Some short answers: performance, interaction, local access, different application model, ...

Also, if Swing is a desktop solution kit then why dont we see a lot of interesting widgets or interfaces recently ?

You mean like a book that shows how to do really cool stuff with Swing? Hey, that sounds like a great idea...
I actually don't understand the question. Swing's been under solid development for years now, coming out with new, cool stuff all the time. Some of its power wasn't necessarily obvious to the uninitiated, which was one of the inspirations for our book - it shows how to make very rich Swing apps using facilities that are there already (plus new utilities built on top to make it easier).

Chet.

It's worth noting that if you have custom content in a component, such as the vectors you describe, then a change to that content may be something that Swing doesn't know about, so you may have to cause a repaint() to occur manually. But as long as you're not changing that content, then Swing should have no reason to repaint that region.

Chet.

Patrick,

I'm not following what's different about your situation from any other Swing component - you have contents in a JPanel and the contents are rendered with Graphics2D. How is this different? I'm sure I'm just missing some details here, maybe you could fill them in for me.

As for JScrollPane optimization, it is not separately buffered (the only
buffer Swing uses is one the size of the window that maps exactly
onto the pixels on the screen). But any scroll operation consists of a simple copy of the area that has not changed plus an update of the new area. See the explanation of copyArea in chapter 3 (I think) for more
information about this.

Chet.

Also, note that the demos posted on the book site (see my .sig below) might be easier to learn individual effects and techniques from than taking on all of Aerith. Aerith is great for showing the effects in context, but there's so much there there that it might be harder to puzzle out the individual contributors to the whole. So my advice would be to poke through the individual demos (explained by the text in the book) to learn the what/how/why and to play with Aerith to see many of them in action and context.

Chet.

Yes. That was one point of confusion in my mind. The mouse scenario I had cited was an example which I thought would trigger paint/repaint as the UI needs to be repainted. Maybe instead of the mouse I should have given the scenario of some swing app running and the user toggling to some other app.

Even that case is optimized. As of Java SE 6, Swing uses a back buffer whose contents map exactly to the pixels you see on the screen. So if you do anything to destroy the screen contents (toggling to another app, dragging a window on top of the Swing app, etc.), then Swing merely re-copies the pixels from the back buffer and doesn't trigger a repaint (so no calls to paintComponent()).

Let me see if I got this thing correct. If I have a JTable being rendered on the UI, unless the table model is changed, the paingComponent() wont be called even if I say minimized and maximised the window? Is this applicable also if I have a panel whose paintComponent I have tweaked to say display the olympic rings as a background? In a nutshell, is swing painting is optimized to figure out model changes and only then call repaint?[/QB]

Yes. There are other ways that repainting can get triggered (including changing your screen resolution, manually triggering it in the app with a call to repaint(), or resizing the window), but in general Swing only bothers to repaint when something has changed in the component (or its model) that changes appearance. Mousing over a JLabel will not cause a repaint, calling its setText() method will.

Of course, running animations in your UI (either independently or trigger by UI interactions like mouse hovering) changes the equation. But I think your question was more about what default repainting was like.

Chet.

Yes. That was one point of confusion in my mind. The mouse scenario I had cited was an example which I thought would trigger paint/repaint as the UI needs to be repainted. Maybe instead of the mouse I should have given the scenario of some swing app running and the user toggling to some other app.

Even that case is optimized. As of Java SE 6, Swing uses a back buffer whose contents map exactly to the pixels you see on the screen. So if you do anything to destroy the screen contents (toggling to another app, dragging a window on top of the Swing app, etc.), then Swing merely re-copies the pixels from the back buffer and doesn't trigger a repaint (so no calls to paintComponent()).

Let me see if I got this thing correct. If I have a JTable being rendered on the UI, unless the table model is changed, the paingComponent() wont be called even if I say minimized and maximised the window? Is this applicable also if I have a panel whose paintComponent I have tweaked to say display the olympic rings as a background? In a nutshell, is swing painting is optimized to figure out model changes and only then call repaint?[/QB]

Yes. There are other ways that repainting can get triggered (including changing your screen resolution, manually triggering it in the app with a call to repaint(), or resizing the window), but in general Swing only bothers to repaint when something has changed in the component (or its model) that changes appearance. Mousing over a JLabel will not cause a repaint, calling its setText() method will.

Of course, running animations in your UI (either independently or trigger by UI interactions like mouse hovering) changes the equation. But I think your question was more about what default repainting was like.

Chet.

Your mail seems to imply (or ask) whether simple mouse movements will entail repaints (calls to paintComponent()). This is not the case unless you have some kind of display change that's triggered on mouse motion (not a common case unless you have animated effects triggered on mouse-hover events or something). Swing is optimized for only repainting things that have actually changed appearance, so if moving the mouse around the screen doesn't cause anything in your app to change, then there will be no calls to paintComponent().

Chet.

What is unique about this book?

A picture of Duke by the poolside on the cover?

A punny title that apparently doesn't translate well into French?

The sheer number of footnotes?

Chet.

The Timing Framework is a relatively recent project (just went 1.0 last week), so I doubt there are tools out there yet unless they're just in development or being prototyped. However, the idea of a tool was always in the back of our minds as we were working on this and related projects. We needed some infrastructure first (ala the Timing Framework) to make the job easier. Now that we have that, all we need is time...

Chet.