Die Windows GDI+ (Teil 1)



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


  • Hallo

    Den Fehler hast du aber nicht bei diesem Codeausschnitt bekommen, oder?

    chrische



  • Nein. Ich habe mir eine Windows-Anwendung mit VC++ 2005 erstellen lassen die ja auch ein Standard-Fenster erstellt und dann die Lib und die Headerdatei eingebunden . Oder sollte ich ein leeres Project erstellen?



  • Willste nicht mal den Header aus den Compiler-Pfaden inkludieren? Also mit spitzen Klammern? Und hast du auch vor dem gdi-Header den <windows.h> inkludiert? LEAN AND MEAN Makros abgeschaltet? Steht alles in meinem Artikel.



  • Den header hatte ich in <>, hatte es nur mal zum Test geändert und die GdiPlus.h ins Projectverzeichnis kopiert. Die windows.h steht schon in die stdafx.h.

    LEAN AND MEAN Makros abgeschaltet?

    Wo kann ich die Abschalten bzw. was heisst das.
    Bin noch nicht lange dabei. 🙄

    EDIT: gefunden, alles klar.
    Danke euch.



  • Die GDI+ Tutorial-exe weigert Vista sich auszuführen(DOS?),
    der ZIP-Ordner Clock enthält 0 Bytes 😞



  • Die GDI+ Tutorial EXE ist ein 7zip-Selbstentpacker. Hem... kann sein das die nicht unter Vista funktioniert.

    Die Dateien sind eh nicht mehr online. Ich werde die mal heute abend neu hochladen und die URLs dann bekannt geben.



  • Downloads wurden korrigiert.



  • Moin,

    als erklärter Nicht-Fan von .NET versuche ich ein Semi-Transparentes Fenster mit GDI+ zu erzeugen was auch super funktioniert und echt klasse aussieht mit den richtigen PNGs.
    Allein: bei jedem Aufruf alloziert das Programm einige neue kB die nicht wieder freigegeben werden. Man stelle sich den folgenden Ausschnitt als Hintergrund einer Uhr vor, die sekündlich aktualisiert wird, dann ist der Speicher sehr schnell aufgebraucht.

    CRect crWindow;
    	GetWindowRect( crWindow );
    
    	HDC hdc = ::GetDC( this->GetSafeHwnd() );
    	if( hdc != NULL )
    	{
    		Bitmap *pbmClone = m_bmBackground->Clone( 0, 0, m_bmBackground->GetWidth(), m_bmBackground->GetHeight(), PixelFormatDontCare );
    
    		Graphics gr( pbmClone );
    
    		HBITMAP hbmBack;
    		Color	clrBm;
    		pbmClone->GetHBITMAP( clrBm, &hbmBack );
    		HDC dcMem = ::CreateCompatibleDC( hdc );
    		if( dcMem != NULL )
    		{
    			HBITMAP hbmOld = ( HBITMAP )::SelectObject( dcMem, hbmBack );
    			CPoint	ptZero( 0, 0 );
    			CSize	szWnd( crWindow.Size() );
    			CPoint	ptBase( crWindow.TopLeft() );
    			BLENDFUNCTION blendFunc;
    			blendFunc.AlphaFormat = AC_SRC_ALPHA;
    			blendFunc.BlendFlags = 0;
    			blendFunc.BlendOp = AC_SRC_OVER;
    			blendFunc.SourceConstantAlpha = iAlpha;
    			if( !UpdateLayeredWindow(	this,
    										hdc,
    										&ptBase,
    										&szWnd,
    										dcMem,
    										&ptZero,
    										::GetSysColor( COLOR_3DFACE ),
    										&blendFunc,
    										ULW_ALPHA ) )
    			{
    				MessageBeep( -1 );
    			}
    			::SelectObject( dcMem, hbmOld );
    		}
    		::DeleteDC( dcMem );
    		delete pbmClone;
    		::ReleaseDC( this->GetSafeHwnd(), hdc );
    		::DeleteDC( hdc );
    	}
    

    Was mache ich falsch?

    btw. Gute Einführung! Mehr davon!



  • Moin,

    so still hier auf einmal 😉

    Fehler gefunden und hat nichts mit GDI+ zu tun.

    Ich hätte erwartet, dass eine Methode die den Namen GetHBitmap trägt, mir ein Handle auf den Speicher gibt, der ohnehin benutzt wird. Tut es aber nicht. Die Methode legt ein komplett neues HBITMAP-Objekt im Speicher an, der über DeleteObject(), eine GDI-Funktion, wieder freigegeben werden sollte. Steht nur leider so nicht im MSDN. Schade!

    Ist allerdings als Hinweis irgendwo in der .NET Dokumentation zu GetHBitmap, wo ich es gefunden und ausprobiert habe.

    Viel Spaß noch!



  • Ich hab da noch ne Frage:

    da ich auch noch keine Ahnung habe wollte ich mal Fragen (bevor ich mich einarbeite), ob man das ganze auch auf einem Dialogfenster darstellen kann oder geht das nur auf einem SDI-Editier-Hintergrund?
    Wenn es auf einem Dialogfenster geht: muss man da irgendein Hintergrund einstellen oder kann man nach dem positionieren direkt auf dem grauen Bildschirm schreiben?
    Wenn es nicht geht: womit macht man sowas?

    Micha



  • Geht natürlich auch mit Dialogen. Dialoge sind auch nur Fenster.


Anmelden zum Antworten