Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

I just build a brand new computer and I am having an issue while playing Minecraft.

The new computer is an Inel i7 3820K with 32GB of RAM and 3 WD Black 1TB drives in a RAID 0 using th e Intel Matrix Storage. The graphics card is an Nvidia GTX 560 with 1024M or VRAM, it made by eVGA.

Anyhow the problem I am having is when I go near my friends base on our map (yes this is on a server) my characters/camera becomes almost unplayable. It being to get really choppy and commands and actions are delayed. At first I thought it could be just the network connection, but when I move away from his base everything speeds up again.

Granted he does have a lot of complex machines and other contraptions running in a very small area and I thought that maybe there is just a too much going on and my computer's wifi is choking but I dont think that is the case. My friends internet is worse than my by a lot and he has no problem playing from Antigua and I am in Ohio.

The only thing that could come to think is maybe it is my monitor causing the problem, I went from a 19" acer display to a 30" Dell UltraSharp. Could it be that the level of complexity in certain areas of the map combined with the resolution I am running the game at is taxing my GPU just a little too much and is causing me to lag?

This is really annoying and I would like to figure out this issue but after so many problems with previous computers I am just pretty stumped with this one. I am going to trying some other game like Skyrim or Deus Ex: HR and see if I get the same problems.

share|improve this question
add comment

6 Answers

up vote 3 down vote accepted

I'll start by saying that these are all very good answers, but I wanted to take the time and see for myself what kind of numbers I could generate on my own two large screens.

Since at least one answer mentioned the GPU's memory and the OP mentions scenes with many objects, I will be measuring different levels of VRAM consumption, and since another mentioned resolution, I will do fullscreen rendering on one screen and compare those numbers with doing fullscreen rendering on both screens. This can be thought of as a bigger monitor at a higher resolution since there is twice the screen real estate. I will also do a small example of two mirrored images, simulating larger screen space while keeping the same resolution.

Using the compared numbers, I can demonstrate what taxes a graphics card.

The Rig:

  • Quadcore 2600k @ 5GHz
  • MSI 580 GTX Lightning Xtreme
    • This version is clocked higher than stock by MSI, but I myself haven't overclocked it for this test
    • This version has 3 gigs of DDR5
    • Driver version 304.79; completely clean install
  • 16 gigs DDR3 system RAM
  • 2x 32" LED screens running at 1920x1080
    • One connected by HDMI, one connected from the DP out through a passive adapter to HDMI in
  • I will be monitoring VRAM usage using MSI Afterburner v2.2.1

The First Test:

For this first test, we are just going to sit at an idle Windows 7 Aero-enabled desktop. I did not have a utility to measure FPS outside of Minecraft.

  • 116-118 MB usage
    • Both screens on, and in 1920x1080 mode
  • 89-91 MB MB usage
    • One screen on, and in 1920x1080 mode
  • 78-80 MB usage
    • One screen on, and in 800x600 mode
  • 73-74 MB usage
    • Both screens on, and in 800x600 mode

-- This test shows that 2x monitors does NOT mean 2x VRAM usage, so one could expect that there is a lot more overhead than just framebuffering, and it's also worth noting that while in hi-res mode, one monitor uses ~77% of the memory of two, and in low-res mode, one monitor uses ~93% of the memory of two, further exemplifying the overhead cost. -- This implies that the answer that @Huskehn gives is misleading, in that higher resolutions alone do not have a practical impact on VRAM usage.

The Second Test:

This test uses VLC to perform fullscreen Blu-ray playback (Talladega Nights, for posterity). I did not have a utility to measure FPS outside of Minecraft.

  • 172 MB usage
    • Both screens on, single fullscreen and in 1920x1080 mode
    • For giggles, I increased playback to 8x in this mode, and saw a 2 MB usage increase
  • 217 MB usage
    • One screen on, dual fullscreen and in 1920x1080 mode
  • 125 MB usage
    • One screen on, and in 1920x1080 mode
  • 106 MB usage
    • Both screens on, single fullscreen and in 800x600 mode
  • 130 MB usage
    • Both screens on, dual fullscreen and in 800x600 mode
  • 94 MB usage
    • One screen on, and in 800x600 mode

-- Not much to say on this test, other than that the VRAM usage was rock steady the whole time, until I changed playback speed only -- memory usage dropped back to normal when set to regular speed which indicated that the framebuffer had increased. Another point to make is that neither of the videos became choppy or looked slow, showing how non-3D applications are trivial.

The Third Test:

In this test, I will be turning on a 32-bit Windows XP virtual machine fullscreen on my second monitor using VirtualBox v4.1.18. The VM has been given 128 MB of video memory (Which later tests don't seem to necessarily prove that the VM can only use this much), and has had 2D and 3D acceleration enabled.

I've skipped a few modes as the other tests seem to show that a predictable difference can be observed.

  • 151-156 MB usage
    • Both screens on, and in 1920x1080 mode
  • 127 MB usage
    • Both screens on, VM screen (and VM itself) in 800x600 mode, and host in 1920x1080 mode

-- I did not measure whether there was different consumption when the screen was @1080, or when the VM's resolution was internally changed to @800

The Fourth Test:

Playing Minecraft!

There's a lot of information in this one, and is probably the most important section for @Solignis.

Firstly, because of the way Windows handles fullscreen applications, I couldn't run two MC clients at maximum size simultaneously, so I ran the other inside of the previously mentioned VM and measured the results. My brother and I play side-by-side like this all the time, and we never have any issues playing! Secondly, I ran a Minecraft server in the background so that way both clients would render the same world, and the near-identical view. I ran both clients, teleported both players to the same spot, looked them in the same direction, and then closed the clients to flush anything previously rendered, then started them back up and didn't move them. I started the server first, and noticed that VRAM went from 156 MB to 168 MB. After disconnecting the first time with both clients, I noticed that now a steady 230 MB was in use. The server was also configured for maximum rendering distance.

The MC graphics settings were the following: "Fancy", smooth lightning ON, 3D anaglyph OFF, GUI scale AUTO, particles ALL, render FAR, performance MAX, bobbing ON, adv. OGL OFF, clouds ON. While the host client can run with adv. OGL ON just fine over 280 fps, this was causing the VM to crawl. I believe this is because of the currently limited support of newer OGL implementations on VirtualBox. FPS was taken from MC by the 'F3' stats.

All tests were recorded in 1920x1080 except where noted otherwise.

  • 530 MB usage @ ~300 FPS (Host)
    • Client fullscreen in host on screen 1, idle desktop on screen 2, no VM running
  • 530 MB usage @ ~305 FPS (Host)
    • Client fullscreen in host on screen 1 and 2 (duplicated screen), no VM running
  • 482 MB usage @ ~330 FPS (Host)
    • Client fullscreen in host on screen 1, second screen off, no VM running
  • 482 MB usage @ ~330 FPS (Host)
    • Client fullscreen in host on screen 1, second screen off, no VM running
  • 480 MB usage @ ~430 FPS (Host)
    • Client fullscreen in host on screen 1, second screen idle desktop, both 800x600, no VM running
  • 547 MB usage @ ~250 FPS (Host)
    • Client fullscreen in host on screen 1, idle VM desktop on screen 2
  • 408 MB usage @ ~70 FPS (VM)
    • Client fullscreen in VM on screen 2, idle host desktop on screen 1
    • FPS started around 60, then slowly dropped to 45, then climbed to 81 after all chunks were fetched
  • 803-805 MB usage @ ~200 FPS (Host), @ ~50 FPS (VM)
    • Client fullscreen in host on screen 1, client fullscreen in VM on screen 2

-- Note that MC caches a lot, and different scenes will cause different amounts of VRAM usage, so while I chose a complex scene with lots of fire and many pistons moving, this is still a near 'best case' scenario as looking around will cause a lot more things to be fetched, cached, and especially redrawn because the whole screen is changing rather than a just a few parts. This isn't to say, however, that MC won't clear its cache when it needs to. You can see a steady increase in VRAM as far-away chunks get rendered, and there was a HUGE difference between the time it took for the VM to load blocks compared to the host system. The restoration of framerate after chunks were loaded demonstrates that, for Minecraft at least, more FPS is lost in fetching things than actually displaying them. The final test showed that the 'MultiplayerChunkCache' for this setup is 961, and then it starts swapping things out, but this didn't prevent VRAM from rising. This caching can also explain why there was not a significant drop in VRAM after switching to a smaller resolution while the client was still running.

-- In regards to the number of pixels being used in relation to performance as suggested by @Diogo, the first few runs show that double/half the amount of pixels doesn't equate to double/half the performance. Using FPS as a measure of performance, only about 10% was gained by reducing the number of pixels by half, as the second screen wasn't rendering anything difficult. So then I mirrored my displays, and the VRAM usage didn't change, and the FPS changed mariginally. In the tests with both the client running on the host as well as the VM, neither the host or the VM's Minecraft dropped 50% in FPS, but, instead, only by about 25%, despite advanced fullscreen rendering on both, so pixel count isn't really a useful identifier in performance.

The Final Test:

Well...just how high VRAM can I get?!

After many minutes of wandering around my server in Minecraft on both VM and host clients, I eventually hit 1685 MB usage when things started leveling off hard. After many more minutes, I was able to hit 1869 MB, and then it would not budge. Even with pistons every which way and fiery netherrack all around me. Even after such HIGH memory usage, the game was still 100% playable on both the host AND VM; ~233 and ~52 FPS, respectively. I had done it. I tapped out Minecraft. Twice. On the same machine!

So then I started up Skyrim. When I minimized my host's MC client, my VRAM only dropped to 1837 MB.

Outside in the lands of Skyrim, I was able to attain a total of 2636 MB of usage, while the VM's Minecraft was still at ~50 FPS. I didn't measure Skyrim's FPS, but it was visibly high.

Annoyed at not hitting the peak, I then minimized Skyrim, dropping to 2617 MB, and opened up Civ 5, which uses DX 11. Once it was loaded, my VRAM shot up to 2884 MB, and I was prompted with a Windows "Your computer is low on memory..." window that pointed to a Java process (Either server or client), however my system RAM was only 9.77 GB out of 16. I loaded my saved game, and it had done it! I hit my 3072 MB max! My second screen went blank, and my first screen started flashing furiously, and was in a reduced resolution. Fearing for my card, I quickly powered off my PC, but not before seeing some warning dialog about "Unreferenced memory at 0x00...." Up until this point, FPS was still high on both screens.

The Conclusion:

If you've made it this far, then kudos for reading. This is a round about way of saying things, but the problem that @Solignis has is unlikely GPU based or CPU based, but perhaps a poor server connection or insufficient Java/heap settings. @Philippe and @libertas are on the right track with their answers.

The Minecraft tests ran in 800x600 and 1920x1080 by themselves show that despite having 432% more pixels, the performance was not affected with such magnitude.

The duplicated screen Minecraft test was a way of simulating a bigger screen (two screens combined), but using the same resolution image, 1920x1080, just using more screen space. Short of having another, larger screen with the same resolution, this is very conclusive in showing that size alone does not noticeably affect game performance.

The the dual Minecraft tests show that rendering a higher resolution image (two screens combined) will have an impact on performance, but doubling the picture did not halve the performance, or make it noticeably slow. This implies that you would already be experiencing slowness in Minecraft in order for the small impact of a small size increase to make the game very slow.

The final test was a way to see if there was a relation between VRAM consumption and performance, and I discovered that there wasn't one. Well, that is, until you hit your maximum VRAM -- then your performance instantly goes to 0. No matter how much information the GPU was keeping track of, it didn't noticeably affect framerates. I have also proven that without a doubt, unless you plan on doing ridiculous things like playing multiple games side-by-side and at once, that 3 GB of video memory is absolutely pointless in the current generation of gaming; memory is a practically useless spec on a GPU, and 1-1.5 GB will suit anyone more than enough.

Minecraft was a very good program for these tests because there is only one set of textures, whereas large games can often have differently-sized textures based on what resolution it is being ran in, which would introduce different variables to skew the tests. Being a multiplayer game was another boon as I was able to reliably render a near-duplicate image. The fact that Minecraft is light-weight enough to be ran inside of a VM was another useful benefit so I could demonstrate extreme edge-cases, have two fullscreen applications, as well as finally being able to determine if VirtualBox's "Video Memory" setting actually restricted how much memory a VM can use on its host GPU.

share|improve this answer
+1 for Science, bitches –  Mark Henderson Jul 24 '12 at 5:12
A lot of good information there. Ok I will look into to OptiFine and see about the connection to my server. When I was running my own server there was no problem but when I went to a hosted solution that is when the lag started so maybe that has a lot to do with it. Thanks. –  Solignis Jul 24 '12 at 15:06
add comment

The size of the monitor doesn't matter, but its resolution does. Because you're now using a monitor with a higher resolution than your previous one, your graphics card needs more video memory to store each frame, since the frames are larger. Due to this, you're going to see a general decrease in performance in all games you play at your monitor's full resolution - the video card simply has more work to do to produce a larger image.

As for Minecraft, make sure you have 64-bit Java installed. Without 64-bit Java, Minecraft can't utilize all of your available memory, which may be the cause of the lag issue. If this doesn't work, you might also want to try OptiFine - a mod for Minecraft that can significantly increase performance.

share|improve this answer
I have verified I am running 64-bit java. As far as OptiFine, I will look into it. Thanks. –  Solignis Jul 23 '12 at 20:42
add comment

I didn't read most of your question, but the answer to the title question is yes, insofar as "size" refers to "screen resolution" (in pixels).

Every pixel has to be processed, in some way or another, individually... and with complicated 3d rendering programs, each pixel often has to be re-calculated and re-processed several times as various effects are applied: shadows, geometry shaders, lighting, screen space ambient occlusion, culling, anti-aliasing, and so on. Each of these operations effectively has to look at a large swath of pixels (or indeed, every pixel on the screen) and modify its color elements (whether they're Red/Green/Blue or some other arrangement).

The number of pixels on the screen increases quadratically if the width and height components increase symmetrically. So, to use simple numbers (these are not real resolutions in common use): if you have a 500x500 screen and you upgrade to a 1000x1000 screen, you don't just have twice as many pixels -- you have the number of pixels you originally had, times four. So 500 * 500 (multiplication) is 250,000; 1000*1000 is 1,000,000. If we took this to its logical extreme and looked at a resolution like, oh I don't know, 32000x24000, I don't honestly know if any existing graphics hardware could play modern games at a respectable frame rate with such a high resolution. The numbers don't LOOK that big, but when you multiply 32000 by 24000, you have a lot of complexity, and a lot of data to process. An enormous amount!

The physical size of the monitor is not important. The screen resolution (number of pixels) directly affects the performance, because more data (more pixels) means more processing at each stage of rendering.

share|improve this answer
add comment

It sounds to me like it's not your graphics card or your monitor but it's Java/Minecraft. Is the server running vanilla or bukkit?

Granted he does have a lot of complex machines and other contraptions running in a very small area

Are you the only one experiencing lag around these contraptions, or do other people as well? This really good be the key here, do you have lag issues in any other settings? I highly doubt it's a hardware issue given your machine is well above the recommended for Minecraft. If other people get the same issue, then maybe some bukkit performance plugins are in order.

(I run a Minecraft server.)

As Huskehn has pointed out, make sure you are running 64-bit Java and give OptiFine a try. However let it be known that I was running Optifine and seeing major improvements when I was running a Radeon HD 5770, but when that card recently started acting funny and I got a GTX 550 Ti, Minecraft was giving me strange flickering issues until I removed Optifine and reverted to vanilla.

Also try playing with the Advanced OpenGL setting (ON was working best for me once I reverted to vanilla).

share|improve this answer
add comment

The size by itself doesn't have any impact if you are using for example a lower resolution(such as 800x600) on comparing two different monitors. However, the screen resolution will affect:

When using higher resolutions, 1366x768 for example, it means each renderized frame will have 1366*768 = 1049088 pixels instead of 800*600 = 480000 pixels that your video card must "create" to send to your monitor. Following this simple example, I could tell you that(theoretically) you would have aproximatelly 45% of performance decrease if using the 1366x768 resolution.

share|improve this answer
This would be a theoretical decrease assuming that the graphics card was working at full capacity to render the smaller view. –  ChrisF Jul 23 '12 at 20:05
add comment

If you upped the resolution (which is most likely in a switch from 19" to 30"), yes, there is a performance hit, as the graphic card has to deal with much more pixels to generate. But with your specs, it shouldn't put any problem, mostly with Minecraft. Most likely, you have a problem connecting to this precise server or with the game itself (there is a lot of times when Minecraft is a bit slow / not the best with performance). If you have the same problem with Skyrim or DeusX, you probably have a problem with your graphic card (not the specs, the card itself). Normally, you shouldn't see that much a slowing when switching to a bigger screen with a card that strong.

share|improve this answer
Ok so then I was right in thinking that card is more than adaquate for that size of monitor. Because I am thinking about getting another one (GPU) to do SLI. I thought that would do away with any lag at all. –  Solignis Jul 23 '12 at 20:10
It can, but as Huskehn said, check if you have 64bit version of Java and try using the add-on he proposed. SLI will provide you with the ability to have higher quality, but might not protect you against that precise lag... –  Philippe Gilbert Jul 23 '12 at 20:13
add comment

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.