X definitely has screen tearing, otherwise we wouldn't have the Present extension.
Core Xlib is entirely ignorant of vsync or anything relating to completed frames. It's an immediate mode rendering model in that everything you draw just gets thrown on-screen by the display server whenever.
Compositors were then bolted on w/redirect and damage extensions and basically randomly snapshot the client window contents before compositing a desktop frame, within that snapshot you can easily have tearing of half-drawn updates.
Further extensions and hacks have tried to fix this like Present and frame clocks from the gtk/gnome folks, but it's all opt-in by X clients and non-uniformly supported by compositing WMs or not at all in classical non-compositing WMs where the X server just draws things directly on-screen as the protocol requests arrive from clients.
These are all driver issues. Xorg and commercial servers on Windows don't have these problems. Intel and AMD drivers don't either unless misconfigured. It is not X's responsibility to handle low level hardware implementation details.
There is nothing in Xlib (that I'm aware of) that has a notion of complete frames - i.e. no buffer swap, no "frame complete" signal. How would the server know when a frame is complete then?
It's definitely there in the Xorg xserver [1]. My memory is fuzzy as it was a long time ago but I distinctly remember wasting a day trying to use this extension and becoming frustrated with its ineffectiveness. Maybe it was just for lack of any vsync mechanism to schedule the swap?
Core Xlib is entirely ignorant of vsync or anything relating to completed frames. It's an immediate mode rendering model in that everything you draw just gets thrown on-screen by the display server whenever.
Compositors were then bolted on w/redirect and damage extensions and basically randomly snapshot the client window contents before compositing a desktop frame, within that snapshot you can easily have tearing of half-drawn updates.
Further extensions and hacks have tried to fix this like Present and frame clocks from the gtk/gnome folks, but it's all opt-in by X clients and non-uniformly supported by compositing WMs or not at all in classical non-compositing WMs where the X server just draws things directly on-screen as the protocol requests arrive from clients.