Earlier quoted context omitted.
Did you check? I tell my QA people all the time: If you come to me with "I think" or "I believe", it sounds like you've got some reading to do.
I didn't write "I think" or "I believe". If you want to know my epistemic status: I know about windows based on observable surface behavior and bugs related to accelerated cursors, but I haven't looked at the source. I know about wlroots because I saw the pull requests related to that and a flag to disable it in sway. The last statement regarding other platforms was an educated guess based on gfx card history: accele…
You can actually test this pretty easily by monitoring GPU usage. When nothing on the screen changes, GPU usage should be pretty much zero, even at the lowest P-state (because the compositor isn't rendering new frames unless something changed). You can move the cursor around and GPU usage will stay at the same level, but do something that actually requires new frames to be rendered, like for example dragging a selection rectangle on the desktop, and you'll see GPU usage go up a bit. (And if you do the same in applications using GPU-accelerated frameworks you'll often see the GPU rev up a few P-states, for example scrolling in the Steam library list is enough to cause a transition for P2 for me, likewise many websites kick it up to P2 when you move the mouse or scroll). Another way to see how the cursor is not using the regular rendering pipeline is to move a window around. You'll invariably see that the window lags behind the cursor by 1-3 frames. Other ways where this becomes noticeable is when the graphics stack breaks down, but the cursor still works.