Tag Info

Hot answers tagged

21

Fundamentally, a core goal in rendering is for each frame displayed on the monitor to present a single, coherent image. There are several different strategies which are, or were, used in order to achieve this. In the following, I mention "vsync". Vsync is the moment at which the monitor begins drawing a new screen image; it's the point at which "vblank" ...


15

Double buffering a canvas based game will certainly be a performance hit. You'd be drawing an extra amount of pixels equal to your canvas size every frame. In canvas based games drawing to a canvas is the biggest bottleneck in most cases and you want to limit that as much as possible, especially on mobile devices. Chrome has GPU acceleration (as of the ...


8

Both Double and Triple buffering solve the problem of black redraws on the screen. Triple buffering, however, solves a problem of concurrency when the current draw buffer is being memcpy-ed to the screen, and your game scene can start drawing already. This article is the best way to explain the benefits of triple buffering ... ...


7

The tearing you're talking about is caused by sending data to the monitor at a different rate than it refreshes. If it's a 60 Hz monitor and you're updating at 80 fps, you can get tearing. But that happens and can be fixed with vsync whether you're using a back buffer or not. A back buffer is just used because pushing to the monitor is slow, especially if ...


7

Double buffering was invented (if that's the right term to use) to avoid the user seeing a complex scene being drawn in front of them, instead you draw to an offscreen buffer, and then flip the one being displayed. There's two ways you can do this, the first is to simply swap them whenever your done with drawing the scene, but this has the drawback of ...


6

There is no need to double buffer html5 games. The browser already handles this for you by only updating the canvas object after your script has run. http://www.mail-archive.com/whatwg@lists.whatwg.org/msg19969.html


4

Any drawing API function called from the CPU will be submitted to the GPU command ring buffer to be executed later by the GPU. This means that OpenGL functions are mostly non-blocking functions. So the CPU and the GPU will be working in parallel. The most important thing to note is that your application can be CPU or GPU bound. once you call glFinish the ...


4

OpenGL sometimes defers your commands until later -- when you see a 0 ms runtime for a particular GL operation, it doesn't mean that operation took 0 ms, it just means that function call (which may have simply queued an operation, not did an actual GPU operation) took a small amount of time. See glFlush(). So, it depends on what work is being done where. ...


4

The fact that multithreaded rendering is a major feature in D3D11 suggests that it indeed can be useful to have multiple threads for generating the GPU command stream. :) Indeed the CPU is "just" storing a sequence of commands for the GPU to execute later, but that doesn't mean it's a trivial amount of work. Incidentally, with an API like D3D or OpenGL ...


3

OpenGL never updates the screen, technically. There is a window system API that is separate from GL (e.g. GLX, WGL, CGL, EGL) that does this. Buffer swaps using these APIs generally implicitly invoke glFlush (...) but in some implementations (e.g. the GDI rasterizer on Windows) it does a full glFinish (...):       *On the left ...


3

Do not try to keep anything persistent in the window's framebuffer. For example, graphics cards usually maintain a hierarchical z-buffer that only works if you call glClear regularly. If you have a rarely redrawn background, I suggest you render that into an FBO (or PBUFFER, if you lack proper FBO support with MSAA) when it changes. If the background drawing ...


2

This quote answers most of your questions: You cannot control whether a driver does triple buffering. You could try to implement it yourself using a FBO. But if the driver is already doing triple buffering, your code will only turn it into quadruple buffering. Which is usually overkill. http://www.opengl.org/wiki/Common_Mistakes#Triple_Buffering ...


2

I'd have to agree with JoeW further up, the question seems to be too specific, in that you state you want to solve the performance problem of lots of trees, but the question states only by partial updates and that leaves only to solutions based around that. What you don't seem to mention above is any form of LOD on the mesh, just mip-maps for the textures. ...


2

I can't authoritatively say that this wouldn't work, but it seems unlikely to be of benefit as the GPU is already a separate piece of hardware that runs in parallel with the CPU. The data just gets piped down to it as appropriate and even the final display call is often buffered up in my experience rather than being a blocking call. Therefore it would be ...


2

I have an idea of where the jittering comes from with vSync and triple buffering. The easiest way to show this is visually. The first example would be 30fps with a 60hz refresh rate vSynced with Double buffering. The pipes are new frames and periods are duplicated frames. |.|.|.|.|.|.|.|.|. This gives an even ~33ms between each new frame, which makes it ...


2

It adds latency because you've got 3 buffers involved instead of 2, so it takes one more frame for your rendered image to get to the screen. I have no idea what kind of "jitter" Carmack is talking about here, though. EDIT Maybe, just maybe, this could make sense in a highly variable framerate context: frames rendered with a given delta-time but displayed ...


2

I assume you're familiar with this experiment? Essentially John Carmack was doing something similar, recording the screen and timing pixels sent to the screen. He found that a good deal of the latency came from the screen. Other factors were the input delay from the keyboard, video drivers and or course the execution of the program itself.


1

Take a look at BufferStrategy, it's the preferred way to use multibuffering for java 2d, - and it works like a charm. Searching google for examples on how to use it should be straightforward :)


1

You are interacting with a Swing UI (the component you pass to your scene's constructor) outside the EDT thread - this might be the reason you are having issues. You could try to run the code in the EDT: @Override public void run() { Thread t = Thread.currentThread(); while (t == gameloop) { SwingUtilities.invokeLater(new Runnable() { ...


1

From what i have read the only behaviour is UNDEFINED. So i would assume there is no guarantee to what will be the contents of the buffer. Not to mention that some libs actually wrap a clear call into the swap buffers call.


1

I noticed that using doing double buffering like this : draw everything a invisible canvas copy invisible canvas to the real canvas actually slows down the rendering (lower fps), instead of speeding it



Only top voted, non community-wiki answers of a minimum length are eligible