Whichever one has the latest content is the one which will be fed into the front buffer. Rather, the 2nd and 3rd buffer are in parallel, feeding into the front buffer. I don't think it necessarily works in serial like a pipeline from 3rd buffer -> 2nd buffer -> front buffer. As per suggestion, I don't think we can make much headway here without external hardware timing validation.ĭoes this reflect how triple buffering actually works?Ī problem is that "triple buffering" seems to be somewhat of an umbrella term with slightly different meanings, but my understanding is that, yes, this is generally how it's supposed to work. a level of buffering which is laid on top of our user-level drawing code. like the extra processing sometimes done in monitor hardware), i.e. If we are seeing a one-frame lag, I suspect that might be due to something happening at the OS level (i.e. So I'm not sure that this sort of code could actually show any difference between double and triple buffering. The point of triple buffering is to avoid lags in getting the latest content to the screen. Perhaps they could be better labelled "Buffer A" and "Buffer B", to indicate that the pointer to which is the latest alternates between them, potentially at a rate which is faster than the front buffer is flipped to the screen. So if the drawing code is running faster than the screen refresh rate, often the content in the second buffer will be skipped entirely, in favour of the later-drawn third buffer. Does this reflect how triple buffering actually works? i.e.
0 Comments
Leave a Reply. |