You mean an X application running in the TurboVNC session? No, because there is no way (*) to even make X applications aware that they are running in a remote display environment. Even if that were possible, the RFB protocol does not have any sort of acknowledgement mechanism that would allow the VNC viewer to notify the VNC server that a framebuffer update has been drawn. We do have RFB extensions that control the amount of data that is sent over the wire, and those extensions essentially already do what you are proposing. If your application keeps drawing frames at a faster rate than the frames can be sent, then some of the frames will be discarded (“spoiled”) and will never make it to the client. (Essentially the server coalesces all updates that have occurred to the virtual framebuffer since the last framebuffer update was sent, so only on fast networks will all updates from the X application actually make it to the client.) That is how most remote display solutions work. I can’t think of any example in which applications running in a remote desktop session have any knowledge of the network conditions. That would defeat the purpose of being able to transparently run those applications either remotely or locally without modifying the applications.
This is one of those situations in which it would be more helpful to discuss what you are ultimately trying to achieve at the high level. There may be another way to achieve your goal.
(*) The remote display server could potentially set an X atom for the X application to read, but this would not be synchronous. The application would have to poll the value of the atom in order to obtain timely information about any aspect of the server’s operation, and it goes without saying that there is no standard protocol for such communication. Whatever the TurboVNC Server did in that regard would not be supported by any other VNC server.