ClearType in Vista Hardwarebeschleunigt?

[peanball]

Floi hat am Rande mal erwähnt, dass ClearType (bzw. Schrift-antialiasing) in Vista hardwarebeschleunigt sein soll (http://www.forum-3dcenter.org/vbulletin/showthread.php?p=5030210).

Wohl aufgrund einer Aussage von Demirug (http://www.forum-3dcenter.org/vbulletin/showthread.php?p=3862674#post3862674).

Da die Frage wenig mit dem eigentlichen dortigen Thema zu tun hat, möchte ich fragen:
Gibts dafür offizielle Quellen?

ClearType ist doch Subpixel-Hinting.
Sinnvoll klingts schon, das die Grafikkarte über eine große Textur machen zu lassen. Insbesondere wenn man eine Textzeile/einen Textblock ge-cleartype-t über ein Bild ziehen lassen möchte und der text dabei so genau/scharf wie möglich sein soll.
Könnte man das aber nicht gleich den Shader komplett machen lassen, ohne vorher in eine übergroße Textur zu rendern (SS) - eine Art Multisampling per Shader?

Gibts da mit den Vista RCs oder der Final schon genauere Aussagen obs nun hardwarebeschleunigt ist? Oder vielleicht sogar näheres zur eigentlichen Implementierung?

Die Neuerungen wie Subpixel zur genaueren Positionierung der einzelnen Zeichen innerhalb einer Zeile einzusetzen und damit ein gleichmäßigeres Schriftbild zu ermöglichen (genauere abstände zwischen Zeichen, etc) wird auf Channel 9 vom Microsoft Typography Team (http://channel9.msdn.com/Showpost.aspx?postid=146749) mal erwähnt.
Prinzipiell klingt also der Ansatz Supersampling + Shader für Subpixel-rendering garnicht so falsch :)
Ich hätte nur gerne etwas mehr als 1-2 Sätze wenn möglich von offiziellerer Stelle - finde aber nichts.

[Expandable]

Kann man denn dieses Schmarrn (ClearType) unter Vista auch noch irgendwie komplett deaktivieren? Es gibt zwar die Option (an gleicher Stelle wie unter XP), nur leider greift das nicht überall (zumindest im RC1).

Ich frag nur, weil mir von ClearType schlecht wird, weil die Schrift dann so abartig verschwommen ist und das Lesen so anstrengend wird.

[Gast]

Erazor']Floi hat am Rande mal erwähnt, dass ClearType (bzw. Schrift-antialiasing) in Vista hardwarebeschleunigt sein soll (http://www.forum-3dcenter.org/vbulletin/showthread.php?p=5030210).



naja, eigentlich soll ja der gesamte desktop hardwarebeschleunigt sein ;)

[peanball]

@Expandable: Das war nicht die Frage. Zum Thema für und wider ClearType kann ich dir diesen Thread (http://www.forum-3dcenter.org/vbulletin/showthread.php?p=3531351) ans Herz legen.

Zum Thema, ich hab selbst was gefunden:
Windows Presentation Foundation uses sub-pixel positioned ClearType, which allows the full precision of ClearType to be displayed on the screen. Using this option, glyphs can both start and end on arbitrary pixel positions. This, especially when combined with kerning, allows us to have very high quality word shapes on the display. High-quality spacing is an important part of making good-looking text on the screen. Sub-pixel positioning gives us a very slight loss of contrast, but excellent spacing offsets this. This high precision spacing allows us to position text in a device-independent manner.

Lastly, y-direction anti-aliasing smooths the edges of character glyphs on the vertical axis; while it can't take advantage of RGB sub-pixels in this axis, this capability still further increases the accuracy of text rendering.

All of the text rendering in Windows Presentation Foundation can be hardware-accelerated given a suitable card, using composites, filters, and blends to offload work that would otherwise be performed on the CPU. The enhanced text support in Windows Presentation Foundation is particularly noticeable for users of East Asian fonts, where historically ClearType has been missing and fonts haven't taken full advantage of the platform.

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnlong/html/wpf101.asp


naja, eigentlich soll ja der gesamte desktop hardwarebeschleunigt sein ;)
Klar. Die GDI ist aber grundsätzlich nicht mehr beschleunigt. Die CPU malt den ganzen Legacy-Krempel in eine Textur und Aero stellt das ganze als Fenster dar. Die bisher vorhandene Möglichkeit, Teile der GDI-Zeichenroutinen (Block füllen, Linie zeichnen, etc.) im Grafikkartentreiber einem 2D-Hardwarebeschleuniger zu übergeben existiert so ja nicht mehr.

Aber inzwischen sehe ich die Cleartype-Beschleunigung mit WPF als bestätigt :)

[Gast]

Erazor']
Klar. Die GDI ist aber grundsätzlich nicht mehr beschleunigt. Die CPU malt den ganzen Legacy-Krempel in eine Textur und Aero stellt das ganze als Fenster dar. Die bisher vorhandene Möglichkeit, Teile der GDI-Zeichenroutinen (Block füllen, Linie zeichnen, etc.) im Grafikkartentreiber einem 2D-Hardwarebeschleuniger zu übergeben existiert so ja nicht mehr.Und woraus besteht dann der Fortschritt?

[peanball]

GDI ist tot - sozusagen. Das beschriebene ist ein Legacy-Modus, den man unterstützen muss. Vorteil der neuen Methode ist allerdings, dass man beim Fenster übereinanderschieben nicht x mal den Bereich für ungültig erklären und die Anwendung neu zeichnen lassen muss.
Außerdem war/ist GDI eh so ineffizient und langsam, dass man es nicht in performancekritischen Bereichen einsetzen kann/konnte.

Mit WPF sollen werden solche Dinge von den 3D Einheiten der Grafikkarte berechnet werden. Flächen werden (ggf. texturierte) Polygone, etc.
Insgesamt wird die komplette Arbeit auf die Grafikkarte abgewälzt.

Spekulation: Dinge wie Scrollflächen kann man sicherlich auch gut mit der Grafikkarte realisieren. Die nicht sichtbaren Inhalte werden ja schon jetzt gepuffert - ansonsten wären z.B. Browser unerträglich langsam.

[Gast]

Erazor']GDI ist tot - sozusagenSchoin geahnt... Die Frage würde ich dann aber gerne wiederholen...

Außerdem war/ist GDI eh so ineffizient und langsam, dass man es nicht in performancekritischen Bereichen einsetzen kann/konnteHmm. Unerträglich langsam wird es, wenn ich dann zB. XP den Grakatreiber von der Herstellerseite vorenthalte.
Sonst spiel ich mal mit XP, mal mit VistaRC2, mal mit WindowFX2... Ich kann nicht behaupten, daß mir bei Vista fast die Augäpfel rausfallen und TFT kaum dem Nachzeichnen nachkommt.

Mit WPF sollen werden solche Dinge von den 3D Einheiten der Grafikkarte berechnet werden. Flächen werden (ggf. texturierte) Polygone, etc.
Naja. Mal sehen. Ich hoffe, ich muß für TrueType nicht 4xAA aktivieren und für saubere "Gitternetzlinien" im Dateimanager 8xAF ;)

[Gast]

Erazor']Vorteil der neuen Methode ist allerdings, dass man beim Fenster übereinanderschieben nicht x mal den Bereich für ungültig erklären und die Anwendung neu zeichnen lassen muss.


Es zeichnet sich natürlich auch nicht das komplette Fenster neu, sondern nur die Update Region. Mit entsprechendem Wissen kann man sehr effiziente, performante GDI Anwendungen entwerfen.


Außerdem war/ist GDI eh so ineffizient und langsam, dass man es nicht in performancekritischen Bereichen einsetzen kann/konnte.


Was ist für dich performance-kritisch bzw. wo wäre GDI inakzeptabel, dass man darauf verzichten müsste?

Dass der Nutzen von WPF außer Frage steht, ist klar.

[Coda]

Naja. Mal sehen. Ich hoffe, ich muß für TrueType nicht 4xAA aktivieren und für saubere "Gitternetzlinien" im Dateimanager 8xAF ;)

Was soll AF bringen bei Texturieriung ohne jegliche Verzerrung? Und nein must du nicht.

[Gast]

Was soll AF bringen bei Texturieriung ohne jegliche Verzerrung?Flip3D? :) Entspann dich mal...

[Coda]

Das ist auch maximal 2:1-verzerrt, da wirst AF so gut wie gar nicht bemerken.

[JaDz]

Erazor']Aber inzwischen sehe ich die Cleartype-Beschleunigung mit WPF als bestätigt :)

Nur dass – soweit ich weiß – DWM überhaupt nicht WPF (Teil von .NET 3.0) nutzt.

Siehe hier: http://blogs.msdn.com/greg_schechter/archive/2006/06/09/623566.aspx

Dass in WPF-Applikationen ClearType hardwarebeschleunigt wird, kann durchaus sein, in den Windows-eigenen Programmen ist dies jedoch meiner Meinung nach nicht der Fall.

Falls jemand genaueres weiß, kann er mich aber gerne korrigieren.;)

[robbitop@work]

Erazor']
Insgesamt wird die komplette Arbeit auf die Grafikkarte abgewälzt.
Ach und wer errechnet die Position der Vertices, wer wandelt die Drawcalls um, ectpp? Ich kann mir nicht vorstellen, dass ein 3D Desktop CPU sparender sein soll als die GDI.

[Demirug]

Nur dass – soweit ich weiß – DWM überhaupt nicht WPF (Teil von .NET 3.0) nutzt.

Siehe hier: http://blogs.msdn.com/greg_schechter/archive/2006/06/09/623566.aspx

Dass in WPF-Applikationen ClearType hardwarebeschleunigt wird, kann durchaus sein, in den Windows-eigenen Programmen ist dies jedoch meiner Meinung nach nicht der Fall.

Falls jemand genaueres weiß, kann er mich aber gerne korrigieren.;)

Beide nutzen intern die gleiche "Renderengine". Da die GDI Anwendungen aber über die CPU abgewickelt werden läuft das ClearType für diese entsprechend auch über die CPU.

[Demirug]

Ach und wer errechnet die Position der Vertices, wer wandelt die Drawcalls um, ectpp? Ich kann mir nicht vorstellen, dass ein 3D Desktop CPU sparender sein soll als die GDI.

Hardware beschleunigtes GDI hat auch einen höllischen Overhead. Der Hauptpunkt wo der neue Desktop sparsamer ist das ständige neu zeichnen von Fenstern die sich eigentlich gar nicht verändert haben. Beim GDI Model kommt das ständig vor bei neuen nicht mehr.

[peanball]

Ach und wer errechnet die Position der Vertices, wer wandelt die Drawcalls um, ectpp? Ich kann mir nicht vorstellen, dass ein 3D Desktop CPU sparender sein soll als die GDI.
Selbst wenn es gleichviel Leistung benötigen sollte, hast du immer noch den Vorteil frei skalierbarer Vektorgrafik. Das wird sich bei der hoffentlich bald eintreffenden Auflösungs-Revolution (Displays mit 150-300dpi oder mehr) bezahlt machen.
Effektiv hängt dann die weitere Skalierung der eigentlichen Auflösung soweit ich das verstehe von der Leistung der Grafikkarte ab. Die Last der Vertice-Berechnung, Drawcalls, etc. bleibt ja soweit gleich.

Zum Thema GDI ist tot: DirectDraw und Co wurden nicht aus Langeweile entwickelt. 2D Spiele, Scaling und co auf der CPU zu machen ist einfach tödlich. Macht auch keiner. Deswegen sehe ich es nicht als großen Verlust, dass GDI nicht mehr beschleunigt wird.

Alle Punkte, die man hätte beschleunigen müssen, lassen sich mit 3D Hardware wesentlich besser beschleunigen, v.a. weil man unglaubliche Leistung brachliegen ließ. Als Beispiele möchte ich mal wieder das offensichtlich hardwarebeschleunigte Verschieben von Fenstern, Scrollen in Fenstern, etc. heranziehen.
Wieviel wurde mit reiner GDI ansonsten gezeichnet und wieviel davon merklich beschleunigt?

@Gast #8: GDI wird garnicht in so performancekritischen Bereichen eingesetzt, als dass es so viel etwas ausmachen würde die Beschleunigung zu streichen.

[Gast]

Ach und wer errechnet die Position der Vertices, wer wandelt die Drawcalls um, ectpp? Ich kann mir nicht vorstellen, dass ein 3D Desktop CPU sparender sein soll als die GDI.

wirklich sparsamer vielleicht nicht, aber er lässt mehr von der cpu-leistung, die man dann für andere dinge verwenden kann.

btw: die java-vm rendert standardmäßig unter windows auch auf eine OGL-oberfläche, hat sich auch noch keiner aufgeregt, dass das mehr strom brauchen soll ;)

[peanball]

btw: die java-vm rendert standardmäßig unter windows auch auf eine OGL-oberfläche, hat sich auch noch keiner aufgeregt, dass das mehr strom brauchen soll ;)Das halte ich für ein Gerücht.
Ist aber nicht standardmäßig aktiviert und war auf jeden Fall bei der Einführung von Java 1.5 noch nicht ganz stabil.
Danach hatte ich leider wenig Gelegenheit mich mit Java2D zu beschäftigen.

http://java.sun.com/j2se/1.5.0/docs/guide/2d/new_features.html#ogl

[JaDz]

Erazor']Selbst wenn es gleichviel Leistung benötigen sollte, hast du immer noch den Vorteil frei skalierbarer Vektorgrafik. Das wird sich bei der hoffentlich bald eintreffenden Auflösungs-Revolution (Displays mit 150-300dpi oder mehr) bezahlt machen.
Effektiv hängt dann die weitere Skalierung der eigentlichen Auflösung soweit ich das verstehe von der Leistung der Grafikkarte ab. Die Last der Vertice-Berechnung, Drawcalls, etc. bleibt ja soweit gleich.

Vektorgrafik gibt's aber auch wieder nur für WPF-Applikationen. Die Windows-eigenen Programme nutzen bei Aero über DWM (teilweise transparente) PNGs zur Grafikdarstellung.

[peanball]

Vektorgrafik gibt's aber auch wieder nur für WPF-Applikationen.
So wie ich das verstanden habe für alles, was den selben Composition Manager ansprechen kann. Das wäre einerseits WPF, andererseits die "nackte" unveröffentlichte API, auf der der eigentliche DWM basiert. Inwiefern Microsoft selbst diese API für eigene Programme nutzt ist mir nicht weiter bekannt.
Auf jeden Fall ist WPF die "öffentliche" API.
Die Windows-eigenen Programme nutzen bei Aero über DWM (teilweise transparente) PNGs zur Grafikdarstellung.In welchen Fällen? Für alles? Was genau bringt in dem Zusammenhang PNG? Schlussendlich muss es ja doch irgendwie mehr oder minder unkomprimiert in den Grafikspeicher (ja ich weiß, s3tc, dxtc, ...).

[Gast]

Erazor']
Ist aber nicht standardmäßig aktiviert und war auf jeden Fall bei der Einführung von Java 1.5 noch nicht ganz stabil.


mit java 1.5 ist der standardrenderer in windows auf jeden fall OGL. am anfang gab es probleme mit dem renderer falls der grafiktreiber FSAA aktiviert hat (teilweise unscharf, fensterinhalte fehlen etc.), was man umgehen konnte indem man entweder im grafiktreiber ein profil für java angelegt hat, in dem man FSAA deaktiviert hat, oder indem man java in den DirectDraw-renderer zwang.

mit dem JRE1.4 war glaub ich noch der DirectDraw-renderer standard (falls es überhaupt einen OGL-renderer gab), mit 1.5 ist auf jeden fall eine 3d-oberfläche standard.

[JaDz]

Erazor']In welchen Fällen? Für alles?

Ja, alle Grafikelemente zur Darstellung der Oberfläche sind in der "aero.msstyles" als PNG gespeichert. (Buttons, Checkboxes, Startmenü, Taskleiste, Fensterrahmen, Captionbuttons, …, alles eben)

Erazor']Was genau bringt in dem Zusammenhang PNG?

Transparenz und Speicherplatz auf der Festplatte nehme ich an. In Windows XP waren es noch meist BMPs.

[Gast]

Beim GDI Model kommt das ständig vor bei neuen nicht mehr.

Da wird aber auch nur neu gezeichnet, wenn sich die Client-Area ändert. Sprich: beim Überlappen oder eben in der Applikation selbst. Selbst wenn du das Fenster auf dem Desktop hin und her ziehst, findet kein Neuzeichnen statt, sofern nichts mit dem Fenster überlappt oder es aus dem Desktop herausgeschoben wird. Und selbst da wird nur die Update Region neu gezeichnet und nicht die komplette Client Area.