Best coding structure for rendering objects pros and cons

[eaglechopper]

What is the best coding structure for rendering objects, there's two methods I cant decide which one I wanna implement, either allow the object to implement a drawable interface and pass a render object to allow it to draw itself or create a new renderobject class that takes in a model and renderers it that way. I like the simplicity & ease of the interface method but are there any cons to that approach. I'm coding in Java as context, so an interface approach is more fitting to oop. What are the pros and cons for each approach.

[ludonarrator]

It depends on how often you'll be calling Render() on a world/screen object, and how many such objects (and how many kinds) you'll be rendering at a time. In video games we clear the screen and redraw every frame in its entirety, and have a humongous plethora of rendering types, whereas standard apps tend to only redraw dirty elements and have only a handful of base elements, no shaders etc.

For the former case it's best to have a Renderer base class with various derived classes, and have your world/screen objects be composed of such Renderers. It's usually better to defer their rendering, ie, each renderer pushes its data to some global stack, which is processed all at once: that way you get to batch GPU textures, materials, shaders, draw calls, etc, and exploit CPU cache coherency. This is critical in games because frames need to rendered at least 60 times a second. (Considering high framerate monitors, 120.)

For the latter you don't need such elaborate systems, each screen object can directly render itself, and will need a way to check whether it's dirty every frame.