Ihr müsst sauber trennen:
Davon betroffen sind:
• 2D-Programme, die eine Zeichenausgabe über das GDI realisieren (und damit auch unter XP laufen)
Einschränkung:
Der aufgetretene Fehler betrifft jedoch nur die direkte Ausgabe der Zeichenbefehle an das Ausgabegerät (Monitor). Wird zunächst in einen programmeigenen Puffer (virtuelle Zeichenfläche) gezeichnet und dann das gesamte Ergebnis auf den Device geblittet (kopiert), dann ist das Versagen nicht ganz so spürbar. Trotz allem ist auch hier eine leichte Verzögerung bemerkbar. Es betrifft auch nur einige ausgewählte Zeichenbefehle für Primitives wie Linien, Kurven, Polygone und Ellipsen/Kreise. Texte und Rechtecke funktionieren hingegen einigermaßen.
Was heißt dies nun konkret?
Es betrifft im Prinzip Editierfunktionen und alles, was an Dingen auf einer Zeichenfläche in Echtzeit gezeichnet wird. Zum Beispiel das Verschieben von Zeichenobjekten. Der komplette Aufbau, z.B. beim Scrollen ist oft nicht betroffen. Nimmt man z.B. in CorelDraw ein etwas komplexeres Ornament und markiert dieses, dann kann man fast schon zugucken, wie sich die Markierungspunkte bzw. Knotenpunkte gemächlich aufbauen. Es passiert auch im Photoshop, wenn man mit mehreren Vektorlayern (z.B. Texten) arbeitet und diese verschieben will. Das mutiert ab einer gewissen Menge und Textlänge/Schriftgröße zum argen Geduldsspiel. Betroffen ist auch das Bearbeiten von größeren Vektor-Cliparts in Office-Produkten. Das nur mal als ein paar wenige, aber relevante Beispiele.
Die Ausgabe der GDI-Befehle im direkten Modus unter W7 erfolgt ja nicht mehr in den DWM (also per redirect zunächst in eine Kopie des Fensters im Systemspeicher) wie unter Vista, sondern direkt in den "non-local video memory" (aperture space), auf den auch die GPU zugreift. Und genau da dürfte der Hase im Pfeffer liegen, wenn es ein Treiber-Bug ist. Verschiebt man das Ganze nämlich erst einmal in einen eigenen Puffer (so wie unter Vista), dann gehts wieder.
Aero oder nicht?
Deaktiviert man nun Aero, dann bleibt der Ablauf zwar der selbe, die Grafikkarte nutzt aber keine Beschleunigung (hardwarebeschleunigtes Blitting) für die Ausgabe der GDI-Inhalte mehr. Außerdem läuft die Kontrolle und Ausgabe dessen, was von einem Programm in den aperture space geschrieben wurde etwas anders ab. Man könnte es auch so sehen, dass sich die Abfragezyklen über geänderte Inhalte ändern (Scheduler). Das kann zum Vorteil oder Nachteil werden, je nach Treiber. Im Übrigen empfiehlt der Artikel ja nicht das komplette Abschalten von Aero, sondern gibt sogar eine kleine Anleitung, wie man nur über die betroffenen Programme während deren Laufzeit automatisch Aoro temporär deaktivieren kann.
Nicht davon betroffen sind:
• 2D-Programme, die eine Zeichenausgabe über Direct2D realisieren (und nicht unter XP laufen)
• 3D-Programme
• Programme die OpenGL nutzen
Kleine Anmerkung:
TH bringt ja, wie im Artikel erwähnt, eine Fortsetzung, also abwarten und Tee trinken. Dort wird es dann sicher auch praxisrelevante Beispiele, eine weiterführende Analyse, einen genauen Überblick darüber, was unter W7 wie genau passiert und als Download das vewendete Testprogramm geben. Dann kann jeder für sich testen, ob er betroffen ist oder nicht. Interessanterweise hat ATI bereits vom Catalyst 9.10 zu 9.11 die Abstürze beim Zeichnen über das GDI gefixt, zwischen 9.11 und 9.12 wurde u.a. das Ausgeben der Fonts für alle Methoden um ca. 25% beschleunigt und läuft nun über die Hardware. Das für all diejenigen, bei denen evtl. noch Fragen offen sind.
Mehr dazu an dieser Stelle nicht, denn es wäre sicher unhöflich, in dem Forum einer Seite für den Artikel einer anderen zu werben. Das macht man nicht
