I don't even understand how a high rez timer timer does capture the time to get from bottom of loop to top, you're saying that the jmp instruction is taking less that one tick? And QPC can see 1 clock tick right?

The conceptual process looks like this

while(!done) {
  CurrentTime = GetTheCurrentTime();
  ElapsedTime = CurrentTime - PreviousTime;
  PreviousTime = CurrentTime;

  Update(ElapsedTime);
  Render(ElapsedTime);
}

You get the current time at the top of the loop, subtract it from whatever the time was at the top of the last iteration of the loop. That's your elapsed time. You're measure the time it took to go from the top of the loop, through all the instructions in the body, and get back to the top. There's no need to concern yourself with trivial details like the cycle count of a jump instruction.

so because my render function takes more time than acceptable refresh it completely destroys the look of the animation.

This sounds like a problem that you should fix. Updating animations (and game logic) via delta time is correct. But using a fixed timestep to do that is not going to solve the problem where it takes too long to render. What makes your game run like a slideshow is the fact that it takes 120ms to render stuff. That's like... 8 frames per second. If you subtract out the time spent rendering, your animations will make smaller adjustments between any two presented frames. But they will still only render at 8 FPS, and when you eventually fix the renderer or switch to a real one, all of your assumed times will be wrong.

I understand the loop, the way I had it didn't include the Update and Render functions on purpose because I thought that it wasn't what I needed. I was in a way right because in my case I don't really need Render and Update timing. What I was asking is why can't I see the delta of the jump instruction reflected by QPC. But in any case it's not important I suppose.

<But they will still only render at 8 FPS> No, they will render at whatever fps I instruct. 8 FPS would be realtime render, the buffered animation can be played at any fps (up to capture limit) after the fact.

Edit: I mean playback, playback at any fps I need.

I don't need real-time rendering, I should have mentioned it initially, I need smooth animations, real time rendering is obviously not happening with 120 ms cycle. I don't think this is something unusual. I need for example a graphic to play in the top right corner on game load, something like a snake eating it's tail. I don't have to render it out in realtime, just render it at game load and then playback at any fps when needed. What my mistake was is that I was in fact trying to render in real time by using time delta.

Thanks