How resource-intensive is the java.awt.Graphics2D object at different screen resolutions?

Question

I'm currently making a 2D RPG in pure Java (yes, I know other frameworks/engines exist xD).

I just created a resizing algorithm and I've noticed that different resolutions result in different FPS counts.

Before I get into the details, I have implemented a few optimization methods.

• All tiles are batched together into a single image as they are loaded into memory
• All images are loaded into memory so no disk loading is happening while the game is rendering.
• The game renders everything in a (screenWidth by screenHeight) chunk, otherwise the object is not rendered. This is to prevent unnecessary rendering.
• The game updates at a constant 60 times per second, while the FPS varies with no upper cap.

Now that that's all out of the way, here's the problem.

When the game is at its native resolution (640x360), I get about 840 FPS. When the game is maximized to full screen(1920x1017), I get about 100 FPS.

I tried to debug this by taking out all parts of the render method individually (eg. tilemap, map objects, player, etc). and nothing seemed to make a significant impact. Eventually, I narrowed it down by stripping my render method AND my update method, leaving me with just graphics.fillRect(0, 0, WIDTH, HEIGHT) where width and height are the screen dimensions.

• With a screen resolution of 640x360, I get about 2700FPS.
• With a screen resolution of 1920x1017, I get about 290FPS.

Therefore, by process of elimination, I have figured out that the bulk of the problem is not due to my render method or my update method, and that it must be caused by the graphics object needing to simply render more pixels.

Could someone let me know if there is any way to eliminate these differences in the FPS with different resolutions (keeping in mind the optimizations I have already put in place) or if the differences are inevitable due to the nature of the java.awt.Graphics2D object?

---

Edit: I ran my application through JProfiler (which I'm completely new to, so please bear with me for any difficulties).

Here is a screenshot of the JProfiler looking at CPU views -> Hotspots when my game resolution is 640x360.

and here is one when my game resolution is 1920x1017.

As you can see, java.awt.Graphics2D.drawImage, java.awt.image.BufferStrategy.show and java.awt.Graphics2D.fillRect take the most space. This is what I suspected, as I knew the image rendering would take some time. However, I noticed an interesting trend that occurred in both screen resolutions:

• java.awt.Graphics2D.fillRect takes approximately twice the amount of average time per invocation than java.awt.Graphics2D.drawImage.

I know that it is the average call time, so of course some images will not always be the same size as the screen, but it still made me curious if that had something to do with it.

As Pikalek said, a higher resolution has more data to push, but is there something else that might be causing these differences in FPS? Poor optimization in some spots perhaps?

---

One more edit, sorry...

I ran the program after removing graphics.fillRect(0, 0, WIDTH, HEIGHT), and the FPS differences did not make much of a difference. Here are the results with everything rendered.

• Resolution of 640x360: Approximately 960FPS
• Resolution of 1920x1017: Approximately 115FPS

Answer 1

1920 * 1017 is just a shade under 2 million. 640 * 360 is about 230000. There's nothing to debug here : you're drawing ~10 times as many pixels so you should expect a roughly commensurate performance drop.

If the player wants to play at that maximum resolution, should you implement some form of an upper FPS cap for all resolutions so they don’t have to think its some sort of code-based issue when they see the 10x increase/decrease in performance? Would this fix have any negative implications?

Most games typically upper-bound rendering speed to either a commonly-used fixed value, such as 60fps, or to the monitor's refresh rate. Any of your players running on battery power will also thank you for doing this.