it it is a Windows API command, then it goes through the video drivers. The video drivers provide optimized code for working with a specific video card, and was written by the manufacturer, and sipports every valid video mode for that video adapter. You frequently read where a new video driver is released to improve performance, and where editors sometimes think that the video hardware will probably fun faster after the manufacturer releases their final video software. It's all about building features into the hardware that the drivers are designed to use, but which fall outside the relm of CPU usage. You could conceivably write your own drivers if you understood the hardware well enough, and you could also bypass Windows API and call the existing drivers directly if you understood the nature of the drivers well enough. All this would promise some speedup with the existing hardware, but at the risk that you would move towards a specific hargware configuration and incompatabilities with other platforms.
Also note that more expensive video memory may be capable of allowing the CPU and the Video Card simultaneous access to the same memory address, but that most video RAM can only permit one to have access at a given moment. This could be an added bottleneck when writing to the front buffer. By writing first to the back buffer, then having the video card flip the buffers via Purebasic via windows via the video drivers, you obtain the fastest throughput that is likely possible for that machine.
Although using APs may mean some loss of speed compared to a direct effort to optimize the manipulation of the hardware, the ease of using the APIs and the acceptable performance level with them make this the preferred route. Besides, as you pointed out, DirectX was an effort to reduce the latency of the standard API calls even further, so that you could make a given PC perform much better at games and other video tasks. So learning DirectX (or OpenGL, or other graphical calls) will help you towards the end of faster and smoother screen updates.
A limitation, though is that there will always be a certain roughness to screen updates with Windows, a slight jerkiness during the updates. This is a byproduct of the operating system itself and how it multitasks. It is generally less of a problem under a Windows NT (including 2000 and XP Pro) then it is under Windows 9x/ME, which are not true multi-user, multi-tasking platforms. Further, Unix, Linux, and BeOS are simply better at multi-tasking than Windows is, but they do not have the depth of applications available for them that Windows does, and likely have far fewer processes loaded and running at the same time. I was particularly impressed at how well
BeOS performs with simultaneous processes running. You could have multiple video clips open and running at the same time with no artifacts shown such as freezes or jerkiness. If you haven't heard of
BeOS, it is much like Linux, and was offered as a free download on the internet (I haven't checked lately, but you use to be able to get it and some aps through
http://www.chet.com, and could buy a professional version if you wanted to).