6 ms·
Not only that but you're guaranteeing yourself one or two extra frames of input lag due to the double/triple buffering.
by hhmc 9y ago
Not only that but you're guaranteeing yourself one or two extra frames of input lag due to the double/triple buffering.
- LeoNatan25 9y agoDouble buffering is always enabled; there is no such thing as “single buffering” in modern computer graphics. What you are talking about is enforced v-sync to prevent tearing on the normal desktop environment.
- wtallis 9y agoAnd triple buffering never means more latency than double buffering with vsync. Unless you're talking to Microsoft, who didn't have real triple buffering for a very long time so they took to using the term to refer to a FIFO queue of rendered frames.
- randyrand 9y agoSamsung Galaxy phones are single buffered when in VR mode. They 'race' the beam by rendering to the left eye buffer while the right eye is being scanned out. then switch. Just a neat fact.
- londons_explore 9y agoSo if rendering takes too long, you see a partially rendered frame?
- randyrand 9y agoin theory, yes. in practice they detect that and quickly show the previous frame reprojected.
- deleted 9y ago[deleted]
- rsync 9y ago"They 'race' the beam by rendering to the left eye buffer while the right eye is being scanned out." Doesn't that mean they have no framebuffer ? My understanding of "racing the beam" is that it is only required when you have no framebuffer at all - you are literally cramming the bits, in real time, onto the display circuitry. If you have even a single framebuffer, you write to that and it handles painting the actual pixels to the display circuitry.
- randyrand 9y agorace the beam can have multiple usages. Its usage makes sense here IMO. for the gearvr, the scan out circuitry operates independently and reads out the bits from a buffer in memeory. There is still a buffer.
- kllrnohj 9y ago> Double buffering is always enabled; there is no such thing as “single buffering” in modern computer graphics. Technically there is, it's called front-buffer rendering and there's specs for it (look up EGL_SINGLE_BUFFER or EGL_KHR_mutable_render_buffer). The only practical usage of it, and the only reason the spec exists at all, is for time-warping in VR where the warp is done race-the-beam style so to speak on a per eye basis (as in, while the left eye is being scanned out do the time warp for the right eye) Granted this is unrelated to OS desktop composition, but hey, the more you know :) In terms of OS desktop composition windowed vs. fullscreen this is actually something mobile solved, or at least Android did I don't know if iOS is the same or not. By shifting final composition to the hardware compositor and using extensions such as EGL_EXT_swap_buffers_with_damage only the area of the screen that was damaged gets updated & re-composited. Desktop has been pretty stubborn and slow to adopt similar systems, Intel only recently added a HWC fast path at all and only for video playback.
- LeoNatan25 9y agoCool, thanks! As far as I know, windows on iOS are similar to fullscreen windows on Mac, as in each app has its own surface where it renders, and SpringBoard has a window which serves as a host for BackBoard to draw.