'animations' as seperate from state loop

I want to redesign a game using an OO state machine, just wondering, from the standard examples i have seen if the screen is updated after the rendering state then how would i incorporate some small looped animations into this and still stick with the same order of flow and not start cluttering up the main() with conditios about drawing or not drawing screen.

i mean for example, in my game i go into an options menu state, when i hit the buttons in options menu the appropriate options window opens, but it is expanded onto the screen from the centre, using a loop to grow the box, thus i need to render, then update screen at end of each loop as boxsize grows.

My only issue is then at end of loop in main() i would still be stepping into a call to update the screen, which in the case above would not be neccesary, but should i just not worry about it? or can anybody suggest alternative approach?
cheers.

One way is that each derived object inherits from an abstract base class that has at the very least a pure virtual Update() and Render().

yes, that is the design i am using, but my problem was that in the main loop when the state calls are made like

current->handle_events();
current->do_logic();
current->render();
current->draw();

if i go into the Save_State for example i need to play one of these animations to pop the window up, but originally i was thinking rendering and drawing have to be done in one function to achieve this during my savestate, and then i would still be calling a draw() needlessly when back in main loop.
Anyway its just me not grasping the speed that things happen at in the loop, i think can just render then draw the first frame, then next loop would render then draw the next larger frame over it and so on until the window fully opened, the rendering function for savestate example increments the boxsize blah blah.

i was avoiding this thinking about what if other events happened, but then its very fast, and they would be queued anyway so no bother.