Is it possible to offset the Vsync timing of Android on hardware level?

[Android Central Question]

To clarify, I would like to offset the actual timing of when the next screen refresh happens.

I am creating a multiplayer game where the server sends packets to clients at 60Hz and I would like these clients to receive these packets couple ms before the next frame starts.

I presume each client will have their Vsync times out of sync relative to each other. This may make the game more responsive to some players than others when they have equal pings to the server

I am using Unity and developing for Android/iOS. Unfortunately, mobile platforms forces Vsync on. So I'm hoping Vsync offset is a possible solution.

For example, ignoring all the problems of unpredictable ping delays and apps running at consistent 60FPS:

Lets assume that the packets arrive AT EXACTLY 60Hz to clientA and it happens to arrive 2ms right before the frame starts. So clientA has the packet ready to be processed by the next frame.

ClientB who also receives packets AT EXACTLY 60Hz but for him it arrives 2ms AFTER the frame starts. That means, the frame already started, so he has wait for the next frame to come to process the packet.

Hence, clientB lags consistently behind clientA by 16.6666ms.

Unless, there is a way to offset the Vsync at hardware level. Since clientB's frame starts 2ms before the packet arrives, if we can offset or delay frame start by 4ms. Then the packet would arrive 2ms before the frame starts and would be ready to be processed by that time. Then of course next the coming Vsyncs happens at the adjusted times.

I know some of you may say 16.6666ms is not a big deal, but this is just a simple example, in my fast paced app, it can make a world of difference.

Thank you in advance.

 

[Rukbat]

First, regardless of ping times, the server (unless it has multiple connections to the internet) handles one packet at a time. A single Network Interface Card can only handle one packet. So one of them will get the response sent sooner than the other. (Turn on 2 televisions and listen to the audio - same cable, same show, out of sync. That's how digital works - one packet at a time.)

Second, human response time is around 750ms for an adult, and maybe as low as 500ms for a younger person. 17ms is nothing. If you find someone with a 17ms reaction time, put a Superman suit on him. (Visual response time is faster - about 67ms. But that's just to see - then we have to realize what is we saw, and that takes time too.

You can possibly (it depends on the chip set) detect the start of the flyback time, the time the screen isn't being "painted", but I don't think you can cause it to change. (We used to do that, back in the 70s, but that was a whole different video technology with those chips, and they were designed to be synced.)

But if you have 2 players playing each other on the same LAN, running to a local server on the LAN, there's still going to be a timing difference between when player A gets sent his "new screen packet" and when player B gets his - so having the end of that packet start the scan is still going to have them starting at different times. Put it on the real world, where ping times change (if you run pint -t and just watch the returns, you'll see that the same computer on the same cable is getting different ping times to a distant server) by more than 17ms if you have a path with 10 or so nodes (use traceroute [or tracert in Windows], it's a bit of overkill to worry about timing down to a part of a 17ms window.