Uhm, das ist eine ganze Menge.
Die einfachste, aber wahrscheinlich naheliegende Antwort ist, dass die Programmierer hinter diesen GUI-Apps wirklich schlechte Programmierer sind. Du kannst Code schreiben, der die skurrilsten Dinge macht, und es wird schneller gehen, aber nur wenige Leute scheinen sich darum zu kümmern oder sie halten es für eine teure, unprofitable Zeitverschwendung.
Um Dinge direkt von der Lade-Berechnungen auf die GPU zu setzen, wird nicht unbedingt Probleme beheben. Die GPU ist genau wie die CPU, außer es ist weniger allgemein und mehr ein paralleler Prozessor. Es kann Grafikberechnungen außergewöhnlich gut machen. Was auch immer Grafik-API/OS und Treiber-Kombination Sie haben, ist nicht wirklich so wichtig ... OK, mit Vista als Beispiel, änderte sie die Desktop-Kompositions-Engine. Dieser Motor ist viel besser kompostieren nur das, was sich geändert hat, und da der Nummer-1-Flaschenhals für GUI-Anwendungen neu zu zeichnen ist, ist eine nette Optimierungsstrategie. Diese Idee der Virtualisierung Ihrer Rechenanforderungen und aktualisieren nur die kleinste Änderung jedes Mal.
Win32 sendet WM_PAINT-Nachrichten an Windows, wenn sie neu gezeichnet werden müssen, dies kann ein Ergebnis von Fenstern sein, die sich gegenseitig verschließen. Es ist jedoch Sache des Fensters selbst herauszufinden, was sich tatsächlich geändert hat. Mehr als das änderte sich nichts, oder die Veränderung, die gemacht wurde, war trivial genug, so dass es nur auf der Oberfläche, die Sie hatten, vorgeformt werden konnte.
Diese Art der Grafikverarbeitung existiert heute nicht unbedingt. Ich würde sagen, dass die Leute davon absehen, wirklich effiziente und virtualisierte Rendering-Lösungen zu schreiben, weil das Nutzen/Kosten-Verhältnis eher niedrig/hoch (schlecht) ist.
Etwas Windows Presentation Foundation (WPF) tut, was meiner Meinung nach weit überlegen ist zu den meisten anderen GUI-API ist, dass es Layout-Updates und Rendering-Updates in zwei getrennte Durchgänge aufteilt. Und während WPF Code verwaltet wird, ist die Rendering-Engine nicht. Was beim Rendern passiert, ist, dass die verwaltete WPF-Rendering-Engine eine Befehlswarteschlange erstellt (was DirectX und OpenGL tut), die dann an die native Rendering-Engine übergeben wird. Etwas eleganter ist hier, dass WPF versucht, alle Berechnungen beizubehalten, die den visuellen Zustand nicht verändert haben. Ein Trick, bei dem Sie kostspieliges Rendering vermeiden, erfordert Dinge, die nicht gerendert werden müssen (Virtualisierung).
Im Gegensatz zu WM_PAINT, das einem Win32-Fenster das Neuanstrich anweist, würde eine WPF-Anwendung prüfen, welche Teile des Fensters neu gezeichnet werden müssen und nur die kleinste Änderung neu zeichnen.
Jetzt WPF ist nicht oberste, es ist eine solide Anstrengung von Microsoft, aber es ist noch nicht der heilige Gral ... der Code, der die Pipeline läuft, könnte noch verbessert werden und der Speicherbedarf einer verwalteten App ist immer noch mehr als ich wollen. Aber ich hoffe, dass dies die Art von Antwort ist, nach der Sie suchen.
WPF ist in der Lage, einige Dinge asynchron ziemlich anständig zu tun, das ist eine große Sache ist, wenn Sie einen wirklich ansprechenden niedrige Latenz/low-cpu UI machen wollen. Asynchrone Operationen sind mehr als nur das Abladen von Arbeit an einem anderen Thread.
Zusammengefasst Dinge langsam und teuer GUI bedeutet zu viel neu zu streichen und die Art der Neulackierung, die das heißt die gesamte Oberfläche ist sehr teuer.
Ich bin auch sehr daran interessiert. Es kann nicht sein, dass die GUI nur mit der CPU gerendert wird, weil Desktop-Grafiken _incredibly_ langsam rendern, wenn Sie keine richtigen Treiber für Ihre Grafikkarte haben. Wenn du aber gfx-drivers hast, geht die desktop-gfx irgendwie schnell aber niemals so schnell wie eine directx/opengl app. –
Die einzigen Algorithmen, die wahrscheinlich langsam sind, sind die Software Rendering-Algorithmen, aber GUI's bewegen sich weg von diesem –