Die Windows GDI+ (Teil 1)

Artchi

Man kann auch in einem Konsolenprogramm ein grafisches Fenster öffnen. Also kein Problem.

Gibt es schon eine Fortsetzung des Tutorials?

Artchi

Bisher gibt es kein Teil 2. Es gab bisher auch nicht wirklich einen Wunsch nach einem weiteren Teil. Wennaber hier schon die ersten Nachfragen kommen, kann ich mir was überlegen.

Hallo

Ich fänd es auch schön, wenn du noch ein weiterer Artikel hinzukommen würde. Viellecith was mit Bitmaps udn noch ein paar versteckten Gimmicks, weil das alles ja sehr selbsterklärend wirkt.

chrische

*D*Evil

Nja eigentlich ist doch alles logisch ...

mein tipp: lasst die finger vom gdi+. es wird nicht weiter entwickelt, hat tausend bugs die nicht gefixt werden und ist laaaaangsaaaam.

Hallo

Na das ist doch mal eine fundierte Meinung.

chrische

chrische5 schrieb:

Na das ist doch mal eine fundierte Meinung.

jeder der sich mal ernsthaft (abseits eures heimprogrammiererniveaus) mit gdi+ auseinandergesetzt hat, wird meine äußerst fundierte meinung teilen.

Hallo

zzZZz schrieb:

chrische5 schrieb:

Na das ist doch mal eine fundierte Meinung.

jeder der sich mal ernsthaft (abseits eures heimprogrammiererniveaus) mit gdi+ auseinandergesetzt hat, wird meine äußerst fundierte meinung teilen.

Wow, du zeigst aber Krallen. Du äußerst halt nur eine Meinung, ohne Links oder ähnliches und dazu bist du nicht registriert und von daher weiß man halt nicht, was man von deiner Meinung halten soll. Obwohl ich ihr nicht einmal entgegen stehe.

chrische

Vertexwahn

in welcher Programmiersprache ist GDI+ entwickelt worden? C# oder C++? wenn man sich die Headerdateien so anschaut so sind die C++ Klassen einfach nur ein Wrapper um irgendeine Bibliothek, die z. B. mit C# programmiert worden sein könnte...

Artchi

GDI+ ist eine native API neben der GDI. Hat absolut nichts mit C# zu tun, da man für die GDI+ kein .NET-Framework benötigt. Aber das .NET-Framework macht tatsächlich von GDI+ gebrauch. Mehr nicht.

nep

Mich würde aber jetzt auch mal interessieren was so schlimm an GDI+ sein soll? Ich habe das hier nämlich auf der Arbeit eingesetzt und war eigentlich ganz zufrieden damit. Es ist natürlich etwas "langsam", da ich verdammt viele Daten zeichnen muss, aber ich denke beim normalen "nativen" GDI wäre das auch nicht wirklich schneller. Soll aber nicht heißen, dass ich denke ich wüsste es besser. Ich würde nur wirklich gerne *fundiert und begründet* wissen, was so schlecht an GDI+ ist.

MartinG

zZzZz schrieb:

mein tipp: lasst die finger vom gdi+. es wird nicht weiter entwickelt, hat tausend bugs die nicht gefixt werden und ist laaaaangsaaaam.

Hallo, kann man das jetzt ernst nehmen oder eher der "Anti-Microsoft-User" Abteilung zuordnen? Ich möchte mich nämlich im Gebiet Bildbearbeitung festsetzen (im Laufe der Zeit eine eigne Bildbearbeitungssoftware ins Leben rufen) und frage mich, ob GDI+ einen guten "Start" darstellt?

Dem Autoren dieser Einführung möchte an dieser Stelle einen großen Dank
aussprechen.

MfG
Martin

MartinG schrieb:

zZzZz schrieb:

mein tipp: lasst die finger vom gdi+. es wird nicht weiter entwickelt, hat tausend bugs die nicht gefixt werden und ist laaaaangsaaaam.

Hallo, kann man das jetzt ernst nehmen oder eher der "Anti-Microsoft-User" Abteilung zuordnen? Ich möchte mich nämlich im Gebiet Bildbearbeitung festsetzen (im Laufe der Zeit eine eigne Bildbearbeitungssoftware ins Leben rufen) und frage mich, ob GDI+ einen guten "Start" darstellt?

Für den Fall, dass unser "zZzZ-Freund" rechtbehält könntest du die Befehle von GDI+, die du brauchst durch eigene Klassen aufrufen. Du könntest auch Befehle von DX dazumixen und desssen Vorteile nutzen, z.B um schnell ein Gitternetz zu zeichnen.

Der Aufwand wäre hoch aber wenn du dich in der Graphikbearbeitung festsetzten möchtest, könnte es das Wert sein.

Falls nun tatsächlich aus irgendwelchen Gründen GDI+ nicht mehr so toll ist und du auf etwas anderes umsteigen möchtest, müsstest du nur eine Stelle deines Projektes anpassen.

MartinG schrieb:

zZzZz schrieb:

mein tipp: lasst die finger vom gdi+. es wird nicht weiter entwickelt, hat tausend bugs die nicht gefixt werden und ist laaaaangsaaaam.

Hallo, kann man das jetzt ernst nehmen oder eher der "Anti-Microsoft-User" Abteilung zuordnen? Ich möchte mich nämlich im Gbiet Bildbearbeitung festsetzen (im Laufe der Zeit eine eigne Bildbearbeitungssoftware ins Leben rufen) und frage mich, ob GDI+ einen guten "Start" darstellt?

Für Bildbearbeitung spielt es nun wirklich keine Rolle, welche Plattform du verwendest. Bilder anzeigen können sie alle und der Rest passiert offscreen und ist unabhängig vom API.

Was du suchst, ist eine Bildbearbeitungs-Bibliothek. Das ist GDI+ nicht. Und ja, GDI+ ist in einigen Bereichen tatsächlich relativ langsam und hat auch seit Jahren kein Update mehr erfahren.

SilentRob schrieb:

Falls nun tatsächlich aus irgendwelchen Gründen GDI+ nicht mehr so toll ist und du auf etwas anderes umsteigen möchtest, müsstest du nur eine Stelle deines Projektes anpassen.

Das trifft natürlich auch auf jedes andere API zu und nicht bloß auf GDI+.

Artchi

MartinG schrieb:

Hallo, kann man das jetzt ernst nehmen oder eher der "Anti-Microsoft-User" Abteilung zuordnen? Ich möchte mich nämlich im Gebiet Bildbearbeitung festsetzen (im Laufe der Zeit eine eigne Bildbearbeitungssoftware ins Leben rufen) und frage mich, ob GDI+ einen guten "Start" darstellt?

Kann man nicht ernst nehmen, da der Kritiker keine Fakten geliefert hat. Und somit ist er nicht mal ein Kritiker sondern einfach nur ein Troll.

Die GDI+ würde ich für die Windows-Programmierung empfehlen. DIe GDI+ hat keine Alleinstellungsmerkmale, es gibt auch andere Bibliotheken, die ähnlich Aufgaben erfülln. Aber es ist nunmal eine Lib die ab WinXP serienmäßig dabei ist.

Für EBV (elektr. Bildverarbeitung) bringt sie auch gute Basisfunktionalität mit. Egal ob es Skalierung, Rotation oder Farbwertmanipulation ist. Sie liest und schreibt auch gleich viele Formate von Haus aus.

Eine EBV-Software muss eh mit der Zeit wachsen. Wenn du super spezielle Effekte haben willst, bekommst du diese eh in keiner kostenlosen Library. Also wirst du eh irgendwann eigene Algorithmen entwickeln müssen. Und ob dadrunter dann GDI+, Cairo oder sonst was werkelt, ist nicht so entscheidend. Denn dann wirst du ja jeden Pixel selber bearbeiten müssen.

Was auch eine Möglichkeit wäre, ist GIL von Adobe.

Artchi schrieb:

Die GDI+ würde ich für die Windows-Programmierung empfehlen.

Für neue Projekte wäre es vielleicht sinnvoller, auf die WPF zu setzen statt auf das veraltete GDI+.

Artchi schrieb:

Die GDI+ würde ich für die Windows-Programmierung empfehlen.

Schließt das DirectX Graphics mit ein?

Wenn ich nämlich den Gerätekontext eines BackBuffers mit Alphakanal mit

IDirect3DSurface9::GetDC

holen will, streikt DX.

Artchi

Für neue Projekte wäre es vielleicht sinnvoller, auf die WPF zu setzen statt auf das veraltete GDI+.

PLONK! Was ist das denn? WPF ist was total anderes als die GDI+, weil das WPF reines .NET ist und auch vornehmlich was mit GUIs zu tun hat. Ganz davon abgesehen, das die WPF-Effekte von der Grafikkarte durchgeführt werden, und das Ergebnis sich somit von GraKa zu GraKa unterscheiden kann und auch wird. Für EBV völlig ungeeigent. Also, was sollen denn diese unqualifizierten Empfehlungen hier?

Artchi

SilentRob schrieb:

Artchi schrieb:

Die GDI+ würde ich für die Windows-Programmierung empfehlen.

Schließt das DirectX Graphics mit ein?

Wenn ich nämlich den Gerätekontext eines BackBuffers mit Alphakanal mit
IDirect3DSurface9::GetDC
holen will, streikt DX.

Bitte differenziere zwischen reiner Präsentation, wo es nicht auf Details ankommt. DX, OpenGL und WPF sind nicht gerade für Pixel-genaue Bearbeitung gedacht. Libraries wie Cairo, GDI+ und GIL sind für ganz andere Einsatzzwecke ausgelegt, nämlich für EBV. Wobei sogar GIL hier wohl am professionellsten ist... ist aber auch vom EBV-Spezialisten Adobe.

Bei dem DC-Problem vom DX kann ich dir leider nicht helfen.