Yes, you're right.
Your graphics cards send out rasterized information to the monitor, even if its a CRT/LCD/Plasma, and the monitor converts it into information it can use.
The problem however, which I failed to demonstrate above, is that this process is entirely controlled by the graphics card.
In earlier years, programmers had direct control of the raster and used it as a tool to make cool effects and special graphics modes.
Today however, its an obstacle we have to overcome because its functionality can be decoupled by the drivers, hardware or software.
It makes sense to draw everything before Vsync, but you can't be sure that every hardware configuration works the same.
I can see a future where they get rid of the whole rasterization process, and just upload whole frames to the monitors. In your programming, you'll just have to throw a RenderFrame() at your decided interval, and not worry about timing issues.
Bah, Im ranting.. please ignore me :)
Your graphics cards send out rasterized information to the monitor, even if its a CRT/LCD/Plasma, and the monitor converts it into information it can use.
The problem however, which I failed to demonstrate above, is that this process is entirely controlled by the graphics card.
In earlier years, programmers had direct control of the raster and used it as a tool to make cool effects and special graphics modes.
Today however, its an obstacle we have to overcome because its functionality can be decoupled by the drivers, hardware or software.
It makes sense to draw everything before Vsync, but you can't be sure that every hardware configuration works the same.
I can see a future where they get rid of the whole rasterization process, and just upload whole frames to the monitors. In your programming, you'll just have to throw a RenderFrame() at your decided interval, and not worry about timing issues.
Bah, Im ranting.. please ignore me :)