Die Windows GDI+ (Teil 1)



  • 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





  • 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



  • 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...



  • 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.



  • 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.



  • 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+.



  • 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.



  • 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?



  • 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.



  • Artchi schrieb:

    Für EBV völlig ungeeigent.

    Wenn man sich für eine Bildbearbeitungssoftware wirklich auf die Features der zugrunde liegenden Grafik-API verlassen will, dann bietet WPF zumindest wesentlich mehr Möglichkeiten als GDI(+) und ist ungleich performanter.

    Dass beides eigentlich nicht für diesen Zweck geschaffen wurde, steht auf einem anderen Blatt. Beide APIs sollen Pixel erzeugen und nicht "bearbeiten".





  • Hallo

    Ich habe Probleme mit GDI+ beim einbinden. Ich habe mir ein TestProject von VC++ 2005 EE erstellen lassen. Dann die gdiplus.h und die gdiplus.lib eingebunden und nun bekomme ich 77 Fehlermeldungen.

    // GDI_Test.cpp : Definiert den Einstiegspunkt für die Anwendung.
    //
    
    #include "stdafx.h"
    #include "GDI_Test.h"
    #include "gdiplus.h"  // dieser Header ist für alle GDI+ Klassen, Funktionen usw.
    
    #pragma comment (lib,"GdiPlus.lib")
    #define MAX_LOADSTRING 100
    using namespace Gdiplus;
    
    Kompilieren...
    GDI_Test.cpp
    c:\programme\microsoft platform sdk for windows server 2003 r2\include\gdiplusimaging.h(67) : error C4430: Fehlender Typspezifizierer - int wird angenommen. Hinweis: "default-int" wird von C++ nicht unterstützt.
    c:\programme\microsoft platform sdk for windows server 2003 r2\include\gdiplusimaging.h(67) : error C2440: 'Initialisierung': 'const char [37]' kann nicht in 'int' konvertiert werden
            Es gibt keinen Kontext, in dem diese Konvertierung möglich ist
    c:\programme\microsoft platform sdk for windows server 2003 r2\include\gdiplusimaging.h(67) : error C2146: Syntaxfehler: Fehlendes ';' vor Bezeichner 'IImageBytes'
    

Anmelden zum Antworten