Vorgestern war GDI(+), was nimmt man heute?

[Dr.Doom]

Howdy,
ich hab' hier eine über 20 Jahre alte, gewachsene Windows only-Software, die ihre Grafik-Darstellung von Koordinatensystem, Kurvenverläufen, Texten etc. mittels GDI, GDI+ auf den Bildschirm zaubert. (Aussen rum ist noch die MFC...)
Es war noch nie sonderlich performant, was aber auch daran liegt, dass es schon immer... Optimierungspotential gab.

Mal angenommen, man schrübe so eine Software heute neu -- welche Grafik-API würde man nutzen? Ist heutzutage "alles" Direct3D, selbst wenn man nur Tabellen, (2D-)Koordinatensysteme und Texte darstellen möchte?

[Exxtreme]

Bissl mehr Infos wären nicht schlecht. Soll das ausschließlich unter Windows laufen oder auch unter anderen Betriebssystemen? Dann welche Programmiersprache ist denn bevorzugt? Gibt es auch noch andere Abhängigkeiten ala SQL Server oder Active Directory etc.?

[Dr.Doom]

Windows only steht oben (Win7+), aber stimmt, der Rest ist C teilweise C++.
Dateioperationen sind alle zu Fuss programmiert, kein Netzwerk, keine Datenbanken.

Es geht mir ausschließlich um den "Grafik-Teil", der restliche Moloch soll bleiben.
Ok, wenn's einen guten Ersatz für die MFC gibt, um Menüs, Toolbars usw. nicht auch noch selbst programmieren zu müssen... aber eher nebensächlich. Grafik first!

[Ganon]

Kommt darauf an wie High- bzw. Low-Level du es haben willst. Es gibt auch Direct2D (https://docs.microsoft.com/en-us/windows/desktop/direct2d/direct2d-portal) was hardwarebeschleunigt ist, aber in dem Sinne nicht als "Malen-API" gedacht ist, sondern als Backend für Toolkits. FireFox nutzt es z.B. unter Windows.

Ansonsten gibt's noch Cross-Platform Toolkits wie Qt (https://www.qt.io/), die sehr viel abstrahieren. Da musst du aber wissen, ob es in das restliche Ökosystem passt. Qt selbst ist schon ein ziemlicher Brocken.

[Marscel]

Dann schau dir auf jeden Fall Direct2D einmal an, ob das deinem Anwendungsfall dienlich ist.

[Monger]

Kommt halt echt auf deine Anforderungen an. Microsoft selbst pusht sehr stark, HTML als Frontend zu nehmen, selbst für rein lokale Anwendungen. Das wird an mehr Stellen gemacht als man glaubt. Gibt auch Hybridlösungen. Manche Spiele rendern ihr HUD über HTML.

[Gast]

DirectxD ist ziemlich sicher der falsche Ansatz. Ihr sucht natürlich ein Toolkit, das euch die Arbeit abnimmt.

Wenns Windows only sein soll, dann .Net/WPF irgendwie naheliegend. Kommt aber auch darauf an, was für Entwickler ihr da habt, welche Lizenz das haben soll (wird das verkauft/weitergegeben?) und ob ihr im Zweifelsfall zusätzlich Geld ausgeben könnt.

Qt z.B. ist ein populäres Framework mit viel inklusivkram, gibts auch Bindings zu anderen Sprachen als C/C++. Ist Open Source und so lange ihr keine Closed Source Software verbreiten wollt und die falschen Addons verwendet (Chart) kostenlos. (Also Chart zwingt euch zu Open Source oder der kostenpflichtigen Lizenz).

Electron ist ein Framework, dass es ermöglicht Programme komplett in Javascript/HTML5 zu erstellen. (Anderer Code lässt sich natürlich auch irgendwie einbinden) Meiner Meinung nach eines der einfacheren Möglichkeiten hübsche Programme zu erzeugen. Lizenz ist super, man muss dann nur gucken, was für JS Bibliotheken man noch mitnehmen will und wie deren Lizenzen sind. Größter Nachteil: Praktisch ist das so umgesetzt, dass das eigene HTML von einem integrierten Chrome Browser angezeigt wird. Das HelloWorld Programm wird damit >50MB groß und wer high performance braucht, muss auch schon wieder tricksen. Dennoch ist die Produktivitat ziemlich hoch und sogar MS entwickeln inzwischen Skype und Visual Studio Code damit.

[Exxtreme]

Es geht mir ausschließlich um den "Grafik-Teil", der restliche Moloch soll bleiben.
Ok, wenn's einen guten Ersatz für die MFC gibt, um Menüs, Toolbars usw. nicht auch noch selbst programmieren zu müssen... aber eher nebensächlich. Grafik first!
Qt kann das alles und es ist auch sehr portabel. Wenn der Rest der Software nicht an Windows hängt dann könnte man auch andere Betriebssysteme abdecken. Ich weiss nur nicht ob das schneller ist als GDI+. Und Qt ist halt doch ein eigenes Öko-System. Dafür ein sehr großes und man bekommt recht gut Hilfe im Internet wenn man nicht weiter weiss. Hat auch den Vorteil, dass es weiter entwickelt wird und man auch kommerziellen Support einkaufen kann.

Man kann auch Wxwidgets nehmen. Das ist schlanker aber viel spartanischer als Qt.

[Marscel]

DirectxD ist ziemlich sicher der falsche Ansatz. Ihr sucht natürlich ein Toolkit, das euch die Arbeit abnimmt.

Wenns Windows only sein soll, dann .Net/WPF irgendwie naheliegend ...

Qt z.B. ist ein populäres Framework mit viel inklusivkram ...

Electron ist ein Framework, dass es ermöglicht Programme komplett in Javascript/HTML5 zu erstellen ...

Liest du eigentlich Anforderungen auch durch oder ist der Drang zur Stack-Diversifikation/Rewriting so stark ausgeprägt?

Da steht doch, es gibt eine alte Anwendung in C/C++ und Windows-API. Der Threadstarter möchte den Zeichnungsteil von GDI überarbeiten und den Rest so lassen.

Direct2D ist mitnichten der falsche Ansatz, wenn du nicht gleichzeitig 3rd-Party Dependencies (mitsamt Lizenzen), Toolchains, Glue-Code, Schnittstellen usw. klären sollst. Schau her: https://docs.microsoft.com/en-us/windows/desktop/direct2d/direct2d-portal

[Gast]

Ich kann mir beim besten Willen nicht vorstellen, dass GDI+ hier der Flaschenhals ist, zumal GDI+ sehr wohl hardwarebeschleunigt abläuft. Du deutest ja schon an, dass es im Code andere, viel dringendere Baustellen geben mag. Ich schließe mich den Vorrednern an: Bei einer Neuentwicklung kann man hier auf Direct2D setzen.

Wenn es aber darum geht, das Stück Software performanter zu machen, kann es passieren, dass man mit viel Aufwand zu Direct2D migriert und dann feststellt, dass das performancemäßig nichts gebracht haben wird. GDI+ ist schnell, keineswegs veraltet und ganz sicher nicht Deine Problemursache. Eine ordentliche Performanceanalyse wird das bestätigen.

[Dr.Doom]

Ich hab' die letzten paar Tage erstmal verwendet, zig Stellen um BitBlits zu bereichern. Das eigentlich Zeichnen ist nicht schneller, aber immerhin flackert es nun nicht mehr...:freak:

[Gast]

Ich weiß ja nicht, wie Dein Code aussieht, aber "zig Stellen um BitBlits bereichert"? Hast Du denn keinen Framebuffer, in den Du zuerst zeichnest und aus dem Du dann abschließend _ein einziges Mal_ pro Frame auf den Schirm blittest? BitBlit ist performancetechnisch ziemlich teuer.

[Dr.Doom]

Die Performance hat nicht gelitten, dafür flackert es halt jetzt nicht mehr.

Der Grafikteil wird bisher auch gar nicht zentral verwaltet, sondern Teile der Software haben Unterfenster, in die sie reinzeichnen dürfen, wann sie wollen.
Da, wo alles zusammenläuft... nun man sieht dort halt nur "Fenster", die auf einer Oberfläche angeordnet worden sind. Ob und wann da was zum Neuzeichnen ist, interessiert die "Zentrale" bisher nicht.

Wir reden hier aber auch gar nicht von etwas, dass X FPS haben muss, sondern eher über etwas Office-artiges. (Ist halt blöde, wenn man's nicht einfach zeigen darf.)

[ENKORE]

(Die allermeisten GDI-Operationen laufen nicht hardwarebeschleunigt ab... inwieweit eine Office-artige Anwendung das benötigt, ist eine andere Frage. Wenn man regelmäßig komplexe 2D Szenen manipuliert, kann das Sinn ergeben.)

[Mortalvision]

GDI, global defense initiative. war das c&c?

[Exxtreme]

(Die allermeisten GDI-Operationen laufen nicht hardwarebeschleunigt ab... inwieweit eine Office-artige Anwendung das benötigt, ist eine andere Frage. Wenn man regelmäßig komplexe 2D Szenen manipuliert, kann das Sinn ergeben.)
Ab Windows 7 ist das anders.

https://docs.microsoft.com/de-de/windows-hardware/drivers/display/gdi-hardware-acceleration
https://docs.microsoft.com/en-us/windows/desktop/direct2d/comparing-direct2d-and-gdi

Und GDI ist in aller Regel nicht der Flaschenhals. Da wären sonst fast alle GDI-Anwendungen langsam.

[Dr.Doom]

Bei meiner zu wartenden Anwendung habe ich drei unterschiedliche Konzepte beim Umgang mit Display Contexten (DC) und selektierten Objekten (Pen, Brush, etc) identifiziert:

(1)
Beim Selektieren von bspw. neuerstellten Pens wird penibel darauf geachtet, dass die OldPens nach getanem Werk wieder zurückselektiert wird, um alles so zurückzulassen wie man es vorgefunden hat.

(2)
Der DC wird vor der Anwendung irgendwelcher Massnahmen gesichert (SaveDC), es wird Herumgemalt, ge-clip-t und intersect-et, und schlußendlich wird der DC wiederhergestellt. Hierbei werden aber keine OldPens gemerkt und auch nicht wiederhergestellt.

(3)
Kombination aus (1)+(2): SaveDC/RestoreDC, aber "dazwischen" MIT Aufräumen und Zurücksetzen der OldPens, etc.


Muss man zwischen einem SaveDC und RestoreDC diese Verwaltung nicht machen oder ist das falsch programmiert worden?
Ein GDI-Ressourcen-Problem wäre über die Jahre aber aufgefallen...

[Ectoplasma]

Also zwischen Save/Restore brauchst du gar nichts aufräumen.