Во первых Microsoft не делает видеокарт, она пишет Операционные Системы. Так что нововведения в 'API видеокарты' ее абсолютно не интересуют, т.к. она пользуется API на уровне именно драйверов.
Во вторых, GDI сам по себе предназначен для вывода окошек и интерфейса пользователя. Там высокие скорости не нужны. Для всякой мультимедии (видео и игры) используется другой стек со своими драйверами - DirectX. Эти драйвера более приближены к аппаратуре, и они позволяют приложениям пользователя получить максимум от каждой конкретной видеокарты.
Например Direct3D использует промежуточный язык (шейдеры), на котором пишется обработка видеопотока (пишется прикладными программистами), и эта программа напрямую попадает в драйвер видеокарты, где уже сам драйвер ее транслирует так, что бы максимально воспользоваться возможностями видеокарты. Вплоть до того, что программа транслируется в код графического процессора самой видеокарты и загружается непосредственно в нее. 
В последнее время некоторые производители видеопроцессоров открыли доступ к ним напрямую из пользовательских приложений (см. CUDA)

Всем большое спасибо за объяснения! Будем ждать новых версий GDI с расширенным функционалом! 

Минутку. Я тут подумал... зачем вообще нужен контекст, когда можно говорить драйверу (через GDI, разумеется) DrawAnything(0, 10, 20). А драйвер-то заточен под определенную видеокарту, и ему не нужна информация о ней, которая, как я выяснил, является контекстом устройства.

Я так понял, что вы говорите о контексте устройства (Device Context). Он нужен в первую очередь, что бы определить к какому именно драйверу производится обращение. Дело в том, что вызовы GDI одни и те же для всех разновидностей того, на чем можно рисовать. И это не только видеокарта. Это может быть принтер, могут быть разные видеокарты (или разные дисплеи на одной видеокарте) или вообще не физическое устройство, а некая виртуальная сущность (например битмэп в памяти, удаленный рабочий стол, метафайл и т.д и т.п.) 

Все понял, спасибо всем!   

Ну и зачем? На этом GDI свет клином не сошелся. GDI нужен только для "офисных" нужд - создание окошек, вывод текста и простой графики. Большее от него и не требуется. А всякие хитрые эффекты вряд ли будут поддерживаться GDI, так как их придется уже самой МС реализовывать для устройств отличных от видеокарт. Когда нужны эффекты, то подключаются менеджеры окон и рабочего стола. И уже через мощные API (в Windows - DirectX, в остальных - OpenGL) делают все это.

Понятно. Т. е. GDI нужен для "кросс-устройственности", так? Чтобы одним и тем же кодом можно было рисовать и на принтере, и на видеокарте.

На данный момент, он нужен в основном для обратной совместимости

Если я правильно понял то цепочка следующая:

Приложение->GDI->драйвер->железо.

Но я все равно не догоняю какую роль тут играет контекст устройства?
Кто ни будь может на пальцах, желательно с примерами из жизни кукольных персонажей, объяснить что такое дескриптор и зачем мы его используем?

дескриптор - в переводе это "описание". Это некая структура, которая содержит всю необходимую информацию для работы с чем-либо. Обычно, дескриптор скрыт за обезличенным указателем (handle в Windows) или числом (дескриптор файла в POSIX системах) с целью ограничения неконтролируемого доступа "пользователя".

Дескриптор в случае работы с графикой можно представить в виде художника с холстом. Ты ему говоришь: "нарисуй черную линию толщиной 1 мм от хх до уу"; и он ее рисует. И тебе совершенно по барабану в этот момент, рисует он карандашом, кистью, лазером или долотом.

Именно для этого и созданы дескрипторы - скрыть реализацию и предоставить одинаковый инструментарий для управления однотипными объектами (устройствами). В объектно-ориентированном программировании это называется инкапсуляцией.

В принципе, дескриптором можно представить указатель на базовый класс, например, ввода-вывода. Когда ты открываешь файл создается экземпляр класса File, когда сокет - класса Socket, когда pipe - Pipe. Но все они имеют общего предка. Ты можешь применять к нему стандартные методы и будут вызываться соответствующие методы классов (так как они виртуальные). Таким образом, тебе совершенно все равно откуда читать и куда писать - в эти моменты ты используешь общий функционал.

Спасибо, очень подробно и понятно, а про контекст устройства так же можно?

IGanja, да.

продолжим аналогию с художником... ты ему сказал нарисовать десяток линий, пару штриховок и две закраски. Он это сделал на холсте. тебе художник больше не нужен и ты освободил его... через какое-то время холст выцвел и тебе пришло сообщение WM_PAINT. Ты опять вызываешь художника, даешь ему нужные команды, он рисует. Затем ты его снова освобождаешь (чтобы его услугами мог воспользоваться кто-нибудь другой)...
Кстати, по приходу сообщения WM_PAINT ты должен перерисовать не все. Координаты областей для перерисовки можно как-то получить (я не самый большой специалист по WinAPI).