a DRI process should ensure that the rendering was clipped to the area reserved for its window. The synchronization with the X Server was done through signals and a shared memory buffer called the SAREA. The access to the DRM device was exclusive, so any DRI client had to lock it at the beginning of a rendering operation. Other users of the device —including the X Server— were blocked in the meantime, and they had to wait until the lock was released at the end of the current rendering operation, even if it wouldn't be any conflict between both operations. Another drawback was that operations didn't retain memory allocations after the current DRI process released its lock on the device, so any data uploaded to the graphics memory such as textures were lost for upcoming operations, causing a significant impact on graphics performance. Nowadays DRI1 is considered completely obsolete and must not be used. DRI2 Due to the increasing popularity of compositing window managers like Compiz, the Direct Rendering Infrastructure had to be redesigned so that X clients could also support redirection to "offscreen pixmaps" while doing direct rendering. Regular X clients already respected the redirection to a separate pixmap provided by the X Server as a render target —the so-called offscreen pixmap—, but DRI clients continued to do the rendering directly into the shared backbuffer, effectively bypassing the compositing window manager. The ultimate solution was to change the way DRI handled the render buffers, which led to a completely different DRI extension with a new set of operations, and also major changes in the Direct Rendering Manager. The new extension was named "DRI2", although it's not a later version but a different extension not even compatible with the original DRI —in fact both have coexisted within the X Server for a long time. In DRI2, instead of a single shared (back) buffer, every DRI client gets its own private back buffer —along with their associated depth and stencil buffers— to render its window content using the hardware acceleration. The DRI client then swaps it with a false "front buffer", which is used by the compositing window manager as one of the sources to compose (build) the final screen back buffer to be swapped at the VBLANK interval with the real front buffer. To handle all these new buffers, the Direct Rendering Manager had to incorporate new functionality, specifically a