(this would have been a comment expanding on TechTimmy's answer, but it grew too long)
It is often the case the virtualised applications response slowly when the remote connection is looking at the host directly rather than remoting to the VM directly.
If you remote to the VM directly RDC can use all its options to reduce bandwidth use as it knows what updates have been made and to a certain extent what they are (just text, a chunk of graphic, a window moved, etc...) so it can easily apply very specific optimisations in order to send the minimum amount of data back to update the client screen.
On the host machine the remote desktop server does not have this knowledge. The virtualised machine looks to it like a large regularly updating bitmap, it can not hook into the graphics layer of the OS as remote desktop's server component does when running directly in the VM. While it could theoretically analyse the changes very thoroughly to determine the exact minimum needed to transfer this would be so excessively CPU intensive as to be impractical (it would save bandwidth but add significant latency and slow down other processes on the host too) so a compromise has to be made. The response will never feel as fast as remoting to the VM directly as there will be more bandwidth used and more latency due to the server having to think more when trying to optimise what it sent and in some cases has to guess when an updaet might have been made and scan for updates.
To cut a long story short: you should always remote directly to the VM where possible when using Remote Desktop or any protocols like it. This is not specific to either VirtualPC or Remote Desktop, though you might find some combinations of remoting protocol and VM display management are more responsive than others.