Life before WPF:
It will be inevitable not to look back and see that standard window applications reply on two well worn parts of the Windows OS to create its user interface.
a) User32: provides familiar windows look and feel for element.
b) GDI/GDI +: provides drawing support for rendering shapes, text, images etc,
Does WPF render using DirectX or User32?
WPF changes all this and is fundamentally different from window forms. WPF’s underlying technology isn’t GDI/GDI+, instead it uses DirectX. So WPF uses DirectX no matter what type of user interface we create. So it’s like whether we are creating complex 3D graphics or just drawing a button, all the drawing work have to pass through DirectX pipeline. Since WPF relies on DirectX, now we can take advantage of hardware acceleration as well, which means this will hand off much work as possible to the GPU(graphics processing unit) which is dedicated processor on video card, and our CPU(central processing unit) could do some rest.
Does WPF rely on User32?
WPF still relies on User32 for certain services, such as handling and routing input and sorting out which application owns which portion of screen real estate. However, all the drawing is funneled through DirectX.
This is the most significant change in WPF. WPF is not a wrapper for GDI/GDI+. Instead, it’s a replacement—a separate layer that works through DirectX.
Can WPF run without DirectX?
WPF has a dependency on the DirectX runtime. However, both DirectX and
WPF have their own software fallback modes so that, in the absence of
suitable graphics hardware and/or drivers, software rendering will be
used instead. Some graphically intensive features will also be
unavailable when software rendering. WPF allows you to check the
rendering tier that it's running under and tailor the UI to suit
the current environment.
Also I suggest you have a quick read of HAL vs HEL to understand that different Graphics cards determine what can be done via DirectX Hardware or software.
Figure 1. The architecture of DirectX and its relationship to Win32.

In Figure 1, you may notice that there are two layers under DirectX called the HEL (Hardware Emulation Layer) and the HAL (Hardware Abstraction Layer). Here's the deal: DirectX is a very forward-looking design, so it assumes that advanced features are implemented by the hardware. However, if the hardware doesn't support some feature, what happens? This is the basis of the dual-mode HAL and HEL design.
The HAL, or Hardware Abstraction Layer, is the "to the metal" layer. It talks directly to the hardware. This layer is usually the device driver from the vendor, and you communicate to it directly through generic DirectX calls. The bottom line is that HAL is used when the feature you're requesting is supported directly by the hardware and thus is accelerated. For example, when you request a bitmap to be drawn, the hardware blitter does the work rather than a software loop.
The HEL, or Hardware Emulation Layer, is used when the hardware doesn't support the feature that you're requesting. Let's say that you ask the video card to rotate a bitmap. If the hardware doesn't support rotation, the HEL kicks in and software algorithms take over. Obviously, this is slower, but the point is that it does not break your program. It will still work—just slower. In addition, the switching between the HAL and HEL is transparent to you. If you ask DirectX to do something and the HAL does it directly, the hardware will do it. Otherwise, a software emulation will be called to get the job done with HEL.
Refs:
http://vishalnayan.wordpress.com/2011/05/20/windows-presentation-foundation-what-why-and-when/
http://www.yaldex.com/games-programming/0672323699_ch05lev1sec1.html