The point of the delta time computation is to know how much real time passed since the last time you did an update. You want that time to include time spent "rendering" (whatever that means to your program). Otherwise you're not actually measuring the real time between two updates. This will not cause your delta time to "bloat out of control." It will cause your delta time to be correct.

This should not "destroy" your animations unless you are also doing those incorrectly. You should be spending much less than 1/60th of a second rendering (ideally, one frame -- both game logic update and rendering -- takes 1/60 of a second at the longest in order to get to 60FPS).

You do not need a fixed time step for this (those are for fixing different issues), and you don't need to "cancel out" the time spent rendering. That is exactly the opposite of what you want to do.

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.

The real solution to this is probably to stop doing software rendering. It's a good educational project, but making one that is both capable of robust visuals and runs at acceptable framerates is quite a challenge.