I have appended a great deal to my answer below, but I have kept my original answer intact for reference.
TL:DR: Virtual Machines are a tool, and while they offer the easy ability to use one OS within another you have to be very much aware of what your intended primary use of the computer will be in order to make full use of the system.
Your question seems to be strongly slanted towards the graphical and interface performance possibilities of using a virtual machine and so I will answer regarding the possibilities there.
The main problem is that in order to safely manage the guest operating systems access to devices (and thus prevent the guest OS from trampling over the host and breaking things) all the devices that you want to use must be "emulated".
What this means is that the graphics card that your guest OS can see is not the same graphics card that your host OS can see. You may be able to enable features like 3D rendering in the guest, but this is handled by an intermediate driver in your guest which passes the requests up to the host in a safe manner in order for the 3D to be rendered there.
It is very doubtful that features like those necessary to play blue-ray discs securely to a supported HDMI display are emulated by the guest graphics card drivers and so this will likely not work.
Basically anything that requires hardware support on your host is not likely to work well, if at all, in your guest. I do not know how WiDi works, but if it requires direct access to your video card memory in order to share it to a television then it will not work unless you use it from your host (Linux) operating system.
Other than that in terms of performance a VM can get close to what it would be if it were the main OS, but there will always be penalties in terms of hard drive device access or contention with other resources that the host is using.
In the Beginning...
In the beginning we had a computer, that computer could only run one operating system. That operating system tended only to run well on the particular processor and other hardware that was in the machine, with other operating systems only able to run badly, if at all, on the native hardware available.
In order for people to be able use the software for one particular platform on another platform (for example, using Pre-OSX MacOS software on a Commodore Amiga) required more than just "installing the software". These two machines used completely different processor architectures and ancillary hardware. There was simply no way one OS could run on the hardware of another machine.
Emulation is like a cousin to Virtualization, they are actually related and have similar goals. One begat the other as it were.
What these differing hardware platforms meant was that if you wanted to use one piece of software from another OS on your machine then everything about that machine had to be analysed to find out how it worked, and then a piece of code written that functioned in the same way as the hardware part did. This had to be done for every piece, the processor, the graphics controller, the memory controller, everything.
Then all these pieces are put together and as each piece is emulating a bit of hardware we called this an emulated machine. We then run an operating system on top of this emulated machine.
The problem is that this approach is slow. Quite simply you were lucky if you could achieve 1/10th of the speed of the original hardware. You literally needed a machine several times faster than your target emulated machine in order to run the emulated computer at anywhere near full speed.
So what changed?
Well, here's the cool thing. Not much really. The only big change was that hardware platforms standardised. We stopped getting custom hardware for every OS and the OSes all moved to, or were created on, a single standard platform.
The components that make up a Mac these days are, by and large, the same components that make up a PC. Linux always ran on PC hardware so nothing new there.
For a good long while emulation was still the norm if you wanted to run the software from one OS on another. Or you could dual-boot and run either operating system as you wanted, but this made it painful and annoying if you wanted to go from coding in Linux to playing games in Windows.
There came the idea that as the underlying hardware is the same, why can't both OSes share it?
We ended up with QEMU and WiNE and similar software solutions. QEMU had long been a favourite for hard emulation of machines, while WiNE allowed Windows applications to run on Linux by trapping and patching their OS API calls and letting the code run natively on the processor.
QEMU did something similar to WiNE, but did at a much lower level. It is still effectively an emulator, but for every hardware call that was made they used a "patch and redirect" method so that any calls went to their own emulated hardware platform instead. because most working code in a program did not actually involve hardware calls (most are simple streams of calculations with a call at the end to display results).
This resulted in an instantaneous speed boost for almost every program in the now not-really-emulated machine. Programs ran with slowdowns dependant more on how much they accessed the "virtual" hardware rather than on how well the machine could be emulated. Rather than running at 1/10th of the speed they were now running at nearly the same speed as if they were natively.
So, if we're running on the processor now, why doesn't my graphics card work?
The only problem with these new Virtual Machines is that by their very nature an Operating System assumes that it has direct control of all the hardware that is in the computer, so that they can provide features like memory management, and control access to hardware.
What this means though is that Virtual Machines cannot get completely away from emulation, at least in method. They still have to emulate certain functions in software, for example a graphics card, or network card must be presented to the OS running in the virtual machine so that the "Guest" operating system thinks it has full control of that hardware. The main OS (by requirements of security) must guard itself against programs directly accessing hardware and this places restrictions on the guest operating system.
In order to do this they have to emulate "virtual" pieces of hardware for everything in the computer. All the code is run natively by the processor now, so it is not slow, but each one of those pieces of virtual hardware must be written in software, and this incurs both a small penalty in performance and potentially a large penalty in terms of functionality.
What that means is that your virtual graphics card cannot and will not have the same features as your real graphics card. In order to get the most performance the virtual hardware can be written to support most used features, and 3D rendering is now possible in a virtual machine, but it's still not the same as real hardware.
What this means is that the host operating system gets the best hardware options, while the guest operating system gets generic hardware options.
A virtual machine is not as good as real hardware, it is only a tool to make it easier to work with the tools from one system on another.
So what do I do?
You have to choose what you want the main purpose of your computer to be.
If you want to play the latest games on your high-powered graphics card and use that same graphics cards power to play full 1080p movies to your 400" HDMI TV but only occasionally want to do some Linux programming, then Windows may be your best bet with Linux as a guest.
If you want to work on the Linux kernel, making hardware drivers for devices in your computer, and occasionally write some software for Windows and test it on a good approximation of a "standard" Windows system then it may be you are better of with Linux as a host and Windows as a guest.
If you like the ease of use of a Mac but want to program for Windows (or there is a software package you want that is Windows-only) then that is an option too.
I'm not saying that Linux can't play games, or that MacOS isn't for programmers as that would simply be a pack of lies. It's just that the one person who can say which OS may be more suited to what you want to do is you.
You really have to understand what you want your machine to do first. Only then can you work out what a virtual machine can do for you.
To answer your questions:
Will the graphics and video rendering quality will be just as good?
No. The emulated graphics card may provide some features of the host graphics card, but it will likely not support complex features such as hardware video acceleration or CUDA programming features.
Will there be any hardware issue such as using HDMI or WiDi?
Again, these extra features will likely not be a feature of whatever emulated/virtual hardware that is available.
Will applications run just as smoothly as long as enough RAM is allocated?
Most applications (so long as they do not require specific hardware features) will run nearly as fast as they would on real hardware, so long as you do not starve either the host or guest of memory.