Grafik-Bibliothek für schnelles Rendering in Systemspeicher
-
Youka schrieb:
einfachen Transport der Daten zwischen Videospeicher und Systemspeicher anbieten?
Einfach ist der Transport eigentlich immer. Ob er schnell ist, haengt aber von der Hardware ab. Die ist dafuer nicht gedacht, kann sein, dass dies dein Problem ist.
-
Wofür genau brauchst du das 16x Multisampling?
-
Was ist denn mit dem Renderer den WPF verwendet wenn es keine kompatible Grafikkarte findet?
Wenn ich das richtig verstanden habe ist das ein vollständiger Direct3D Software-Renderer.
Wenn man ohne WPF irgendwie auf das Ding zugreifen könnte...
-
Du meinst WARP? Wollt ich auch schon vorschlagen, die Frage ist allerdings, ob Windows überhaupt eine Option ist. Und zuerst würd mich mal interessieren, wieso überhaupt so arges Multisampling (bei der Auflösung könnte man evtl. auch mit FXAA gute Ergebnisse erzielen) und ob er das Multisample target vor dem Download resolved oder tatsächlich die vollständigen multisampled Daten über den Bus jagt und wo tatsächlich die Zeit liegen bleibt (Stichworte Event und Query)...
-
Danke!
Ich denke das wird es sein.
Hab darüber nur mal im Zusammenhang mit WPF gelesen und mich dann nicht mehr weiter schlau gemacht ...Wobei ... was machen WPF Anwendungen unter Windows XP?
-
WARP ist glaub ich jünger als WPF, meine Erinnerung kann mich allerdings auch täuschen. Da die iirc damals ganz zufällig alle gleichzeitig rausgekommen sind, war meine persönliche Vermutung jedenfalls immer schon, dass Direct2D und DirectWrite sowie wohl auch WARP aus dem ursprünglichen, internen WPF Kram (milcore) hervorgegangen sind und nichts anderes als die nächste Evolution davon darstellen. Deren zeitliches Auftreten und die verblüffende Ähnlichkeit von Direct2D/DirectWrite mit WPF lässt imo praktisch eigentlich gar keinen anderen Schluss zu...
-
dot schrieb:
Und zuerst würd mich mal interessieren, wieso überhaupt so arges Multisampling (bei der Auflösung könnte man evtl. auch mit FXAA gute Ergebnisse erzielen) und ob er das Multisample target vor dem Download resolved oder tatsächlich die vollständigen multisampled Daten über den Bus jagt und wo tatsächlich die Zeit liegen bleibt (Stichworte Event und Query)...
Das 16x Multisampling war nur zu Testzwecken, um auszureizen, wie stark Antialiasing das Blitten beeinflusst, aber letztendlich war selbst das gewünschte 4x Multisampling nicht zufriedenstellend, dennoch deutlich besser.
Was du mit dem 'resolved' meinst verstehe ich nicht. Ich hatte halt eine FBO mit Multisample Renderbuffer als Colorbuffer, eine FBO mit Textur als Colorbuffer und zwischen ihnen geblittet, weil man auf einen Multisample FBO kein glReadPixel ausführen konnte. Vor dem Blitten wurde glFinish ausgeführt. Die Zeit habe ich mit clock gemessen und umfasste lediglich den glBlitFramebuffer Aufruf.
-
Youka schrieb:
Was du mit dem 'resolved' meinst verstehe ich nicht.
Bei Multisampling hast du mehr als ein Sample pro Pixel. Bevor die Bilddaten ausgegeben werden können, müssen die Samples auf die entsprechende Auflösung heruntergerechnet ("resolved") werden.
Youka schrieb:
Ich hatte halt eine FBO mit Multisample Renderbuffer als Colorbuffer, eine FBO mit Textur als Colorbuffer und zwischen ihnen geblittet, weil man auf einen Multisample FBO kein glReadPixel ausführen konnte. Vor dem Blitten wurde glFinish ausgeführt.
Wie genau hast du geblittet und die Daten zurückgelesen?
Youka schrieb:
Die Zeit habe ich mit clock gemessen und umfasste lediglich den glBlitFramebuffer Aufruf.
Auf einem Windows System? Wenn du Pech hast, dann hat clock() dort eine Auflösung im Bereich von 15ms und ist für derartige Dinge völlig unbrauchbar. Besser Queries verwenden, die Gesamtdauer über ein paar hundert Frames messen oder zumindest einen ausreichend genauen Timer nehmen...
-
dot schrieb:
Bei Multisampling hast du mehr als ein Sample pro Pixel. Bevor die Bilddaten ausgegeben werden können, müssen die Samples auf die entsprechende Auflösung heruntergerechnet ("resolved") werden.
Das habe ich durch das Blitting selbst bezwecken wollen. Der Multisample Renderbuffer war der Colorbuffer des Target FBOs. Weil der FBO dadurch mehrere Samples speichert, konnten nicht einfach Pixeldaten rausgelesen werden, sondern mussten vorher aufgelöst werden, was durch das Blitting in den FBO mit Textur (=nur ein Sample) als Colorbuffer gelöst wurde.
dot schrieb:
Auf einem Windows System? Wenn du Pech hast, dann hat clock() dort eine Auflösung im Bereich von 15ms und ist für derartige Dinge völlig unbrauchbar. Besser Queries verwenden, die Gesamtdauer über ein paar hundert Frames messen oder zumindest einen ausreichend genauen Timer nehmen...
Ich habe bei clock Abweichungen von bis zu 5ms festgestellt, aber selbst das Ruckeln des Frameserving, welches durch die Bearbeitungsdauer-Überschreitung von >20ms auftrat und der ruckelfreie Vergleich mit einem Renderbuffer ohne Multisampling haben mir Gewissheit verschafft.
-
Da der Threadtitel noch passt:
Welche Alternativen zu Cairo bieten sich an?Anforderungen (absteigend nach Priorität):
* Software-Renderer
* sehr schnell
* plattformunabhängig
* viele FeaturesAGG habe ich bereits ausgeschlossen.
-
Youka schrieb:
Welche Alternativen zu Cairo bieten sich an?
Du bezahlst jemanden, der für deinen Spezialfall eine solche Lib macht.
