Direct2D / Direct3D

Hallo zusammen,

ich bin gerade dabei mich beruflich in DirectX einzuarbeiten(müssten trifft es hier ganz gut).
Grund ist, dass wir ein relativ komplexes DataGrid(readonly) benötigen und uns die Performance bei .NET und Java nicht so ganz zufrieden stellt.

Leider kann diese Liste unfassbar groß(lang und breit) werden und es wird viel gescrollt. Paginierung kommt leider nicht in Frage.

Nun zu meinen Fragen:

Momentan habe ich ein paar Sachen in Direct2D umgesetzt. Wenn ich das richtig verstehe, dann ist Direct2D ein Aufsetzer auf Direct3D. Ist das so korrekt? Wenn ja, dann gibt es ja mit Sicherheit einen kleinen Overhead. Dieses könnte ich erschlagen wenn ich direkt auf Direct3D setze oder? Damit sollte ja das selbe, wenn auch vielleicht mit Mehraufwand, dasselbe möglich sein wie mit 2D.

Außerdem habe ich mir gestern die Frage gestellt wann gezeichnet werden soll. Bisher habe ich bei WM_PAINT ein BeginDraw und EndDraw aufgemacht und dazwischen "gemalt". Da aber recht viel gemalt wurde, finde ich es nicht sonderlich performant ständig das ganze neu zu zeichen. Also müsste ich ja jetzt eigentlich abfragen, ob es überhaupt nötig ist neu zu zeichnen oder? Z.B. nur dann wenn neue Daten oder so da sind oder. Allerdings sehe ich z.B. in den MS Beispielen nur, dass die jedes mal alles neu zeichnen. Was ist da nun best practice?

Gruß

Meine Grafikprogrammiererfahrung ist schon ein paar Jährchen her, aber ich traue mich trotzdem mal, eine Antwort zu geben.

uns die Performance bei .NET und Java nicht so ganz zufrieden stellt.

Das sind ja gleich drei Dinge auf einmal: .NET ist ein Framework, Java ist eine Programmiersprache, und Direct3D/2D eine Grafik-API. Wie stehen diese drei Dinge in deinem Kontext im Bezug zueinander?

Wenn ja, dann gibt es ja mit Sicherheit einen kleinen Overhead. Dieses könnte ich erschlagen wenn ich direkt auf Direct3D setze oder?

Ja, damit implementierst du dann dein eigenes Direct2D mit deinem eigenen Overhead, der aufgrund deiner nicht vorhandenen Erfahrung sicher um einiges höher ausfällt als bei D2D.

Was ist da nun best practice?

Meiner etwas angestaubten Erfahrung nach zeichnet quasi jedes existierende Programm den kompletten Bildschirminhalt in jedem Frame neu. Das ist zumindest bei Spielen so üblich.

GPUs sind so leistungsstark, dass man für ein bisschen 2D einfach alles zur GPU schickt. Bei sehr großen Dimensionen vorher an den Bildrändern grob clippen, um nur das Nötige zur GPU zu schicken und gut.

Sind deine Inhalte komplett statisch? Nur Scrolling?

Da du Java erwähnt hast: mal OpenGL in Betracht gezogen?

Naja wir sind keine Anfänger also können wir ja drauf los reden.

WPF hat es leider nicht so gebracht, da die ListView, ebenso das DataGrid, vollkommen vergewaltigt wird. Eigentlich hatte ich mir da was besseres erhofft, da WPF bekanntermaßen auf DirectX fußst. Aber die Sache ist eben sehr komplex. Mit Windows Forms fange ich erst gar nicht an. Und eine Diskussion auch nicht:-P

Relativ gute Erfahrungen habe ich mit dem CEF(Chrome) Framework gemacht. Nervig ist allerdings der massive Overhead und das Gerümpel was ich mitschleppe. Ich brauche ja schließlich keinen ganzen Browser.

Bei Java gehts um unter anderem um SWT und die Tatsache, dass das Java Zeugs(ist nicht meine Welt) eher weniger für eine GPU geeignet ist. Java ist im Backend vielleicht ganz brauchbar aber nicht für ein Frontend. BTW ich rede hier nur von Windows!

Ist erstmal eine Unterstellung. Man kann ja schließlich nachsehen wie D2D es macht.

Ja, damit implementierst du dann dein eigenes Direct2D mit deinem eigenen Overhead, der aufgrund deiner nicht vorhandenen Erfahrung sicher um einiges höher ausfällt als bei D2D.

Naja ich habe in den letzten Tagen viel gebastelt und mir ist folgendes aufgefallen. Ich habe, erstmal nur so zum Spaß aber die Anzahl wird später durchaus realistisch sein, mal ca. 20.000 Texte zeichnen lassen. Und das war noch längst nicht alles. Und naja...die Performance war eher enttäuschend. Entweder scheibt man 20.000 Texte welche unabhüngig voneinander sind nicht mit 20.000 DrawText Aufrufen oder ich mache etwas falsch. Das ist auch der Grund weshalb ich mir Gedanken über einen Wechsel von D2D zu D3D gemacht habe. Vielleicht gibt es da andere Tricks. Alles in allem kann man sagen... Ich habe bei jedem PAINT Aufruf zu Beginn ständig alles neu gezeichnet aber danach war die Anwendung gar nicht mehr zu gebrauchen. CPU Auslastung war brutal und auf meiner billigen Grafikkarte war auch viel los.

Der Inhalt ist an sich statisch. Deswegen dachte ich an einmal zeichen und gut ist's. Und erst bei Bedarf wird neu gezeichnet.
Scrollen bin ich gerade dabei einzubauen aber da habe ich momentan das selbe Problem wie der Type hier: http://stackoverflow.com/questions/32835771/strange-effect-when-resizing-a-window-with-scrollbars

Mal sehen ob ich nicht doch besser meine eigene Scrollbar baue die auch noch besser aussehen soll.

Ich habe so einiges vergleichen und mir auch mal Vulkan angesehen. Aber alles in Allem kann man sagen, dass bei den Benchmarks DirectX ganz ok abgeschnitten hat und OpenGl eher etwas hinherher hing. Begründet wurde das durch die stündige weiterentwicklung von MS die wohl im Verhältnis mehr Zeit investieren als es jemand bei OpenGL tut. Und Vulkan ist wohl noch nciht so ganz ausgegoren. Interessant fand ich bei Vulkan aber, dass die wenig Overhead haben weil viele Prüfungen einfach ausgelassen wurde. Da muss man als Entwickler eben besser aufpassen was ja erstmal in Ordnung ist.

XMAMan

WPF ist ungfähr um den Faktor 10 langsamer als DirectX.

Wie statisch sind deine deine Grafiken? Kann man sich das als ein 2D-Bild vorstellen, wo du dann Scrollen und Zoomen willst oder ist das eher wie bei ein Spiel, wo viele Objekte sind, die sich alle irgentwie bewegen können?

Ich würde es in der Stelle schon mit Direct3D probieren, da du dort noch die Shader hast, womit du Zeichenfunktionen an deine Bedürfnisse anpassen kannst.

Mechanics

Ich glaub jetzt ehrlich gesagt nicht so wirklich, dass das Grafikframework hier der Flaschenhals ist. Wenn du dein Grid selber zeichnest bzw. die entsprechenden Mechanismen des GUI Frameworks benutzt, sollte das Zeichnen an sich nicht das Problem sein.
Wir benutzen Qt und haben teilweise auch sehr große Tabellen. Viele Elemente werden im Hintergrund geladen und evtl. später dargestellt, um den UI Thread nicht zu blockieren. Aber das Zeichnen an sich ist überhaupt kein Problem, wenn man nur das zeichnet, was auf den Bildschirm passt. Da lohnt es sich meiner Meinung nach überhaupt nicht, irgendwas zu optimieren.

rapso

@secondsun
ergo: scheint als kennst du das problem, aber kennst dich nicht mit den loesungen aus.
wir kennen die loesungen, aber dein problem nicht.
wenn du also wirklich hilfreiche hilfe haben moechtest, erklaere uns das problem genau und wir antworten dann, ob deine annahmen, auf dein problem bezogen, stimmen. bzw, was eine gute loesung waere (aus unserer sicht).