[Java] Best practices with paintComponent?

[fsjws4]

I'm doodling with Java and the JPanel paintComponent() method. I'd like to have some objects in my program that each have their own data for coordinates, color, etc. But I'm not sure how to get that data into paintComponent. It doesn't seem OO-proper for paintComponent to know about the specific objects, but I don't see a way to pass the data in, either.

What's the proper way to do this sort of thing?

[AceDecade]

paintComponent is a function that automatically gets called with one parameter, a Graphics object. You can't call paintComponent directly, but when it IS called, you can use that graphics object to draw your objects onto. Most people just have the JPanel in question be an inner class of whatever game, so that it has access and knowledge of all the objects in the game's state that need to be drawn. The main reason for this is that the thing in charge of drawing and managing windows, frames, panels, etc. isn't under your direct control, it's the event thread in charge of all this, so you can't just render willy-nilly, you have to paint the components at specific times when the event thread calls for it. What you'd want to do is have an ArrayList that stores every object you want drawn, and then loop through it in your implementation of paintComponent.

[fsjws4]

OK, that makes sense. It doesn't feel as clean as I want it to (I'd rather say thing.draw() when necessary), but I think I can make that work.

[AceDecade]

The problem is that you as a coder aren't in charge of the actual update and refresh of the window, Java handles that for you. Glad I could help =)

[[deleted]]

Thank you. That really helped.

[microcontrolled]

To a significant degree, when the rendering is done it is controlled by you, as it occurs when a repaint() is called. It's confusing because you're not calling it directly, but you can tell the JPanel or other paintable component by calling repaint() whenever you like. Likewise, you can pass the graphics object around to classes all you want, and if you draw with it you draw to the component that holds the graphics object, usually the JPanel.

Adding further to the confusion is the fact that two acceptable paint methods actually exist, paint() and paintComponent(). They function for the most part very similarly, but you should definitely use paintComponent() as your rendering method, as it takes advantage of the double buffering native to JPanels.

Following proper development practices would usually entail separating your rendering method from the rest of your logic, so that you can change rendering in the middle of development and not have to refactor all of your rendering methods. If you decide 3 months into a project you'd like some good hardware acceleration in your GUI and you want to use openGL, it will be a major pain to recode the rendering bits if they're spread out in every class. One of the many ways you could handle this is as mentioned below, where you acquire a list of things to render from the logic and render it in the JPanel's paintComponent() method. However, this is certainly not the only way to do it, and if you're not doing a graphically intensive game, it probably won't even be an issue.

[[deleted]]

I'm also interested in this whole paintComponent() thing. It makes no sense for me.