GUI als Bild abspeichern

  • Hi,

    was ich machen will: ein Linienchart erzeugen und das als Bild abspeichern.
    Also in etwa: ein Rechteck mit x- und y-Beschriftung, darin dann eine Linie und das ganze dann speichern.

    Nun bin ich halt nicht so der AutoIt-Experte :) - daher hoffe ich auf Hilfe von euch.

    Ich hab mir einige Skripte runtergeladen und rumprobiert.
    Ich vermute mal, an GUICreate() geht kein Weg vorbei (obwohl ich gar kein UI will).
    Aber damit habe ich zumindest schon mal ein Rechteck mit Linien erzeugen koennen.
    Dann kam erst GDI+ ins Spiel, und dann auch Screencapture.
    Ich hab versucht, aus dem GUI eine Grafik zu erzeugen, daraus ein Image, daraus ein ??? usw. usf.
    Das ganze vorwaerts und rueckwaerts, um vielleicht mit _GDIPlus_ImageSaveToFile() oder _ScreenCapture_SaveImage()
    das von dem GUI in eine Datei zu bekommen - aber ich schaffe es nicht.

    Hoffe ihr koennt mir etwas den Weg weisen ...

  • Erzeug einfach eine Bitmap mit _GDIPlus_BitmapCreate() und render darin hinein indem du mit _GDIPlus_ImageGetGraphicsContext() das Graphics Objekt der Bitmap holst.

    Edit: Es existiert gar keine Standard AutoIt Funktion namens _GDIPlus_BitmapCreate() :whistling:
    Stattdessen einfach _GDIPlus_BitmapCreateFromScan0() mit der gewünschten Höhe & Breite (evtl auch Pixelformat aufrufen) und du hast deine Offscreen-Bitmap (also ohne jegliches GUI-Zeugs) :D

    Edit 2: .., weil die Rede war, dass du vlt. keine Ahnung hast wie du mit GDI+ umgehen sollst. Hier mal ein Beispiel wie ich mir das dachte.

    Spoiler anzeigen

    7 Mal editiert, zuletzt von CentuCore (5. Juli 2015 um 14:52)

  • Hi,
    so sollte es funktionieren mit GDIPlus. Ich persönlich ziehe die "Oldschool"-Variante mit Bitmaps vor.

    Spoiler anzeigen
  • Andy, du solltest die _GDIPlus_PenCreate Ressourcen "sauber" freigeben, wenn du sie so oft benutzt. ;)

    12x erstellt und nur 1x freigegeben.


    Oder so:

    :D

    Auch am Arsch geht ein Weg vorbei...

    ¯\_(ツ)_/¯

  • Andy, du solltest die _GDIPlus_PenCreate Ressourcen "sauber" freigeben, wenn du sie so oft benutzt.

    UEZ, du weisst genau, dass ich das Beispiel aus der Hilfe kopiert und um 3-4 Zeilen eigenen Code ergänzt habe :D
    Ansonsten wären GARKEINE _Dispose()-Aufrufe im Script enthalten 8)
    *whispermode ON* und wenn es statt 12 auch 12000 Pens wären, Windows sorgt beim Beenden des Scripts dafür, dass der Speicher freigegeben wird...*whispermode OFF*

    Übrigens einer der Gründe, wieso ich die Variante mit _WinAPI_ - Funktionen vorziehe, da kümmerst du dich selbst um deinen Speicher bzw. dieser wird sowieso von Windows abgewickelt.. Für o.g. Beispiel brauche ich damit nicht mal die Hälfte der Befehle. Mal davon abgesehen, dass ich die _GDIPlus_- Funktionen sowieso nur zu 5% verstehe (und deswegen auch nutze).
    Bis jetzt konnte mir noch niemand erklären, worin der Unterschied der GDI+ in Bezug auf -Graphics, -Image, -Bitmap, HBitmap usw besteht, ich habe EINE einzige GUI auf der ich mit mehreren Objekten jedes mal Saltos schlagen muss, um "ein bisschen" Grafik anzuzeigen :| .

  • UEZ, du weisst genau, dass ich das Beispiel aus der Hilfe kopiert und um 3-4 Zeilen eigenen Code ergänzt habe :D Ansonsten wären GARKEINE _Dispose()-Aufrufe im Script enthalten 8)
    *whispermode ON* und wenn es statt 12 auch 12000 Pens wären, Windows sorgt beim Beenden des Scripts dafür, dass der Speicher freigegeben wird...*whispermode OFF*

    Übrigens einer der Gründe, wieso ich die Variante mit _WinAPI_ - Funktionen vorziehe, da kümmerst du dich selbst um deinen Speicher bzw. dieser wird sowieso von Windows abgewickelt.. Für o.g. Beispiel brauche ich damit nicht mal die Hälfte der Befehle. Mal davon abgesehen, dass ich die _GDIPlus_- Funktionen sowieso nur zu 5% verstehe (und deswegen auch nutze).
    Bis jetzt konnte mir noch niemand erklären, worin der Unterschied der GDI+ in Bezug auf -Graphics, -Image, -Bitmap, HBitmap usw besteht, ich habe EINE einzige GUI auf der ich mit mehreren Objekten jedes mal Saltos schlagen muss, um "ein bisschen" Grafik anzuzeigen :| .

    Da hast du recht, dass nach dem Beenden des Skriptes der Speicher wieder freigegeben wird, aber wenn jemand dies in einer endlosen Schleife tut, gibt's eben ein Speicherleck.

    Die Unterschiede zwischen GDI und GDI+ sind leider in der Hilfe nicht gut dokumentiert und viele schmeißen auch die Begriffe wild durcheinander. Aber in GDI+ gibt es einige Befehle, die die Brücke zu GDI (HBitmap) schlagen.

    Die Unterschiede zwischen Bitmap und Image (in GDI+) und Bitmap (GDI) und Bitmap (GDI+) sind eben da und müssen verstanden sein, wenn man beide kombiniert nutzen möchte. Wenn man einmal den Bogen raus hat, ist es nicht mehr so kompliziert.

    Der Hauptunterschied ist wohl der interne Aufbau, aber wer möchte, kann in MSDN sich informieren.

    Auch am Arsch geht ein Weg vorbei...

    ¯\_(ツ)_/¯

  • Der Hauptunterschied ist wohl der interne Aufbau, aber wer möchte, kann in MSDN sich informieren.

    Genau DAS ist eben das Problem....
    Dort gibt es eben die Beispiele nicht, welche einem logisch denkenden Menschen erklären, wieso es MEHRERE komplizierte Verfahren/Ausdrücke für ein und dasselbe gibt.

    Ich als "Oldschool"-Bitmapbearbeiter möchte das machen, was der TE auch machen möchte! Eine Zeichnung erstellen, indem ich verschiedene "Pinsel" verwende.
    "Von Hand" nehme ich einfach eine Leinwand und male mit verschiedenen Pinseln etwas darauf. Fertig.
    Code dazu:


    Es gibt EINE Leinwand, auf die sämtliche Funktionen angewendet werden, so stelle ich mir das vor.


    Dagegen ist

    AutoIt
    $hGraphic_hwnd = _GDIPlus_GraphicsCreateFromHWND($hGUI)
    $hImage = _GDIPlus_BitmapCreateFromGraphics(400, 300, $hGraphic_hwnd)
    $hGraphic = _GDIPlus_ImageGetGraphicsContext($hImage)

    mMn nur noch KRANK!
    Da beziehen sich GRAPHICS, BITMAP und IMAGE -Funktionen auf ein- und dasselbe, nämlich das "Bild"
    Um zu "malen", MUSS ich die GRAPHICS-Funktionen benutzen, um Filter und Pixel und Icons zu bearbeiten MUSS ich BITMAP-Funktionen verwenden, und um schliesslich mein Bild zu vergrössern/verkleinern oder zu speichern oder die Bildgröße herauszufinden MUSS ich die IMAGE-Funktionen verwenden.....ohne Worte...
    Und wenn man dabei an der richtigen Stelle nicht noch das eine oder andere _WinAPI_SelectObject() benutzt, funktioniert sowieso nichts mehr ||
    Tut mir ehrlich leid, aber das Konzept dahinter ist weder für Einsteiger noch für Fortgeschrittene Anwender (und ich bezeichne mich hier einfach mal als "Fortgeschrittener" in Sachen Programmierung) nachvollziehbar.

    //EDIT
    WENN sich schon 25 Jahre nach Einführung grafischer Betriebssysteme das Graphics-Konzept etabliert hat, wieso gibt es dann bspw. die Funktionen _GDIPlusGraphicsCloneArea() oder _GDIPlusGraphicsGetHeight() und _GDIPlusGraphicsSaveToFile() nicht?
    Dann könnte man sich auch die Fingerwundschreiberei sparen und gleich Clonearea(),GetHeight() und SafeToFile() schreiben :whistling:

    ciao
    Andy


    "Schlechtes Benehmen halten die Leute doch nur deswegen für eine Art Vorrecht, weil keiner ihnen aufs Maul haut." Klaus Kinski
    "Hint: Write comments after each line. So you can (better) see what your program does and what it not does. And we can see what you're thinking what your program does and we can point to the missunderstandings." A-Jay

    Wie man Fragen richtig stellt... Tutorial: Wie man Script-Fehler findet und beseitigt...X-Y-Problem

    3 Mal editiert, zuletzt von Andy (3. Juli 2015 um 16:13)

  • $Leinwand=GetLeinwand($hwnd_GUI,Position,Größe) ;soweit ok
    $Pinsel=DefinierePinsel($Leinwand,Eigenschaften) ;auch ok

    MaleLinie($Leinwand,x1,y1,x2,y2,Pinsel) ;wie sonst^^
    MaleRechteck($Leinwand,bla...)
    MaleIrgendwas($Leinwand,blub...)
    MaleFilter($Leinwand,tralala...)

    Filesave($Leinwand,Dateiname) ; fertig


    Das würde ich so lösen:

    Abgesehen davon gebe ich dir recht, dass das Verstehen der GDI / GDI+ Funktionen (Aufbau und Anwendungen) nicht einfach sind, aber ich der Meinung bin, dass wenn mal der Groschen gefallen ist, das Grafik System verständlicher ist, als am Anfang. Man muss nur intensiv damit auseinander setzen.

    Auch am Arsch geht ein Weg vorbei...

    ¯\_(ツ)_/¯

  • eher so...

    Spoiler anzeigen

    Man beachte die Parameter (und deren Übergabe bzw. Verwendung) in den "neuen" Funktionen :D
    Aber ich denke es wird klar, wo ich hin will...

    Übrigens ist mir noch etwas eingefallen, es gibt noch einen Audruck für "Leinwand", und zwar "Canvas", cool, damit könnte man _Canvasxxxxx()-Funktionen erstellen um die GRAPHICS/BITMAP/HBITMAP/IMAGE -Funktionen zu wrappern 8o

    ciao
    Andy


    "Schlechtes Benehmen halten die Leute doch nur deswegen für eine Art Vorrecht, weil keiner ihnen aufs Maul haut." Klaus Kinski
    "Hint: Write comments after each line. So you can (better) see what your program does and what it not does. And we can see what you're thinking what your program does and we can point to the missunderstandings." A-Jay

    Wie man Fragen richtig stellt... Tutorial: Wie man Script-Fehler findet und beseitigt...X-Y-Problem

    3 Mal editiert, zuletzt von Andy (3. Juli 2015 um 21:00)

  • Andy: Übrigens ist mir noch etwas eingefallen, es gibt noch einen Audruck für "Leinwand", und zwar "Canvas", cool, damit könnte man _Canvasxxxxx()-Funktionen erstellen um die GRAPHICS/BITMAP/HBITMAP/IMAGE -Funktionen zu wrappern


    Und das Ganze hätte ich nun einmal erklärt. Habe das Unverständliche mal "unterstrichen" und "fett" dargestellt.

    Und noch was !!!
    Den Link bei Andy in der Signatur der so lautet "Wie man Fragen richtig stellt..." finde ich ja mal für "Frischlinge" echt gut. Ups, nun habe ich den Link geklaut. Stimmt ja gra nicht, einen Link kann man nicht klauen. Oder doch? :p

    Lieben Gruß,
    Alina

    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

    Geheime Information: ;)
    k3mrwmIBHejryPvylQSFieDF5f3VOnk6iLAVBGVhKQegrFuWr3iraNIblLweSW4WgqI0SrRbS7U5jI3sn50R4a15Cthu1bEr

  • @Alina,
    der ThreadErsteller kommt, übrigens genau wie ich, beim Erstellen eines Scriptes nicht mit den diversen BITMAP/IMAGE/HBITMAP/GRAPHICS-Funktionen der GDI(+) klar!
    Das kommt einfach daher, dass man sich als Anfänger sowie auch als Fortgeschrittener durch den Objektdschungel der verschiedenen Funktionen schlagen muss.
    Die Frage ist, wieso man nicht EIN Objekt bearbeitet, welches sich in den Funktionsnamen wiederspiegelt?!
    Die Funktionen bleiben identisch, die Namen beziehen sich aber auf EIN Objekt, beispielsweise "CANVAS" statt BITMAP/IMAGE/HBITMAP/GRAPHICS-Funktionen.

    Siehe Post #9, dort werden NUR die GRAPHICS-Funktionen verwendet. Obwohl es einige davon diese in der "offiziellen" Bildbearbeitungs-Beschreibung garnicht gibt...
    Somit bezieht man sich auf EINEN Funktionsnamen-Stamm und muss nicht mit mehreren anderen Funktionsnamen komplizierte (weil nicht dokumentierte! ) Abhängigkeiten auflösen!

    Link dazu... https://msdn.microsoft.com/de-de/library/…7(v=vs.71).aspx
    Zusammengefasst wird ein BITMAP-Objekt in einem IMAGE-Objekt erstellt, welches dann mit einer GRAPHICS-Funktion bearbeitet werden muss! Weiterbearbeitet wird das Ganze dann mit BITMAP-Funktionen und gespeichert mit IMAGE-Funktionen!
    Wieso wird kein XXXXX-Objekt erstellt und mit einer XXXXX-Funktion bearbeitet und mit einer XXXXX-Funktion gespeichert?

  • @Offtopic:

    ...Zusammengefasst wird ein BITMAP-Objekt in einem IMAGE-Objekt erstellt, welches dann mit einer GRAPHICS-Funktion bearbeitet werden muss! Weiterbearbeitet wird das Ganze dann mit BITMAP-Funktionen und gespeichert mit IMAGE-Funktionen!
    Wieso wird kein XXXXX-Objekt erstellt und mit einer XXXXX-Funktion bearbeitet und mit einer XXXXX-Funktion gespeichert?...

    Es wird kein Bitmap Objekt in einem Image Objekt erstellt.
    Es wird ein Bitmap Objekt erstellt und das ist gleichzeitig ein Image Objekt (weil es von Image abgeleitet ist = von Image geerbt hat).

    Warum es nicht nur Bitmap-Funktionen gibt liegt daran, dass jede Klasse nur die Funktionen implementiert und zB nicht Bitmap, sondern Image implementiert "GetGraphicsContext".
    Warum nicht alles in Image implementiert ist?
    Hm...ich hab's nicht designed, aber wenn du dir die GDI+'s Vererbungshierarchie anschaust, dann siehst du, dass zwei Klassen von Image erben und das sind Bitmap und Metafile.
    Und es wär unlogisch wenn man aus einem Metafile ein Graphics Objekt erstellen könnte, deshalb wurde diese Funktion in Bitmap ausglagert. (und frag mich jz nicht warum Metafile von Image erbt, die Designer hatten schon ihre Gründe/soweit kenn ich mich nicht mit GDI+ aus)
    Aber in C++ ist es auch leichter mit GDI+ umzugehen als in AutoIt, weil dann alles mehr Sinn ergibt.

    @Ontopic: Was hat diese Diskussion mit der eigtl. Problemstellung des TE zu tun?
    Ich fänd's besser wenn man sowas zwar in einem Thread anspricht (wenn's auf der Zunge brennt, aber dann einen eigenen Thread aufmacht und den dann noch verlinkt. Allein schon weil man dann in Zukunft solche Diskussionen viel leichter wieder findet)

  • und frag mich jz nicht warum Metafile von Image erbt, die Designer hatten schon ihre Gründe/soweit kenn ich mich nicht mit GDI+ aus)

    Wenn du dich nicht auskennst, und nicht weisst bzw. erklären kannst WARUM das so ist, wird dein Statement "die Designer hatten schon ihre Gründe" zur Ausrede für alle Leute, welchen sämtlichen Mist kommentarlos akzeptieren und auch anwenden...in Ermangelung konstruktiver Verbesserungen! Diese Leute würden heute noch mit der Keule in der Hand in Höhlen wohnen und sich den Arsch abfrieren. Feuer? Pfff...im Sommer wird es doch sowieso wieder warm...

    Die erfolgten "Verbesserungen" von GDI(+) klammern diesen undurchsichtigen Sumpf komlett aus, und nennen sich dann DirectX, D3D, OpenGL uswusf. Mal abgesehen davon, dass dort genauso "zwielichtige" Konstrukte vorkommen. Ob das daran liegt, dass 10000 "Entwickler" über 30 Jahre hinweg permanent auf der Arbeit ihrer Vorgänger aufbauen und somit auch kommentarlos deren Fehlkonstruktionen übernehmen und sich nur 3 Handvoll Leute Gedanken darüber machen, was "sinnvoll" und "Anwenderfreundlich" ist, soll jeder selbst entscheiden!
    Akzeptieren muss man das aber nicht!

    @Ontopic: Was hat diese Diskussion mit der eigtl. Problemstellung des TE zu tun?

    Was wiederum erklärt, dass du dich nicht auskennst und auch den Thread nicht verfolgt hast!
    Der TE bekommt es eben NICHT hin, einfachste Bildbearbeitung mit GDI(+) hinzubekommen, genau WEIL das System völlig undurchsichtig ist! Und er ist nicht allein, vielen anderen geht es genauso!
    Wie gesagt, das ist auch der Grund, wieso ich persönlich "direkte" Bildbearbeitung vorziehe. Mittlerweile habe ich mir Funktionen dafür geschrieben, um bspw. Schrift/Bilder in vorhandene Zeichnungen/Bilder einzufügen, oder Filter auf vorhandene Bilder anzuwenden, da ich nach 8 Wochen ohne GDI keinen Plan mehr habe welche Schritte im einzelnen dafür nötig sind.

    aber wenn du dir die GDI+'s Vererbungshierarchie anschaust, dann siehst du, dass zwei Klassen von Image erben und das sind Bitmap und Metafile.
    Und es wär unlogisch wenn man aus einem Metafile ein Graphics Objekt erstellen könnte, deshalb wurde diese Funktion in Bitmap ausglagert

    Ah 8o , genau DAS interessiert ehrlich gesagt kein Schwein! Interessant ist, wie ich ein vorhandenes BILD lade, dieses rotiere, einen Teil davon ausschneide, mit Markern versehe und wieder speichere bzw. in einer GUI anzeige! Und das mit Befehlen, welche sich auf das BILD beziehen, denn DIESES wird doch bearbeitet, oder etwa nicht?!

  • Wenn du dich nicht auskennst, und nicht weisst bzw. erklären kannst WARUM das so ist, wird dein Statement "die Designer hatten schon ihre Gründe" zur Ausrede für alle Leute, welchen sämtlichen Mist kommentarlos akzeptieren und auch anwenden...in Ermangelung konstruktiver Verbesserungen! Diese Leute würden heute noch mit der Keule in der Hand in Höhlen wohnen und sich den Arsch abfrieren. Feuer? Pfff...im Sommer wird es doch sowieso wieder warm...
    Die erfolgten "Verbesserungen" von GDI(+) klammern diesen undurchsichtigen Sumpf komlett aus, und nennen sich dann DirectX, D3D, OpenGL uswusf. Mal abgesehen davon, dass dort genauso "zwielichtige" Konstrukte vorkommen. Ob das daran liegt, dass 10000 "Entwickler" über 30 Jahre hinweg permanent auf der Arbeit ihrer Vorgänger aufbauen und somit auch kommentarlos deren Fehlkonstruktionen übernehmen und sich nur 3 Handvoll Leute Gedanken darüber machen, was "sinnvoll" und "Anwenderfreundlich" ist, soll jeder selbst entscheiden!
    Akzeptieren muss man das aber nicht!

    Die Designer hatten aber ihre Gründe..dass ich die nicht kenne ist verständlich.
    Du verallgmeinerst recht "schön", bzw. implizierst dass GDI+ Mist ist.
    Wenn dem so ist, warum kommst du zu dieser Meinung?
    Was wäre deiner Meinung nach bitte eine konstruktive Verbesserung?

    Von welchem Sumpf redest du bitte?

    Wie ein Bild rotiert wird hat nichts mit einer Bitmap zu tun, sondern ist reine Zeichenaufgabe.
    Ein Graphics Objekt repräsentiert die Zeichenfunktionen für ein Image/HDC/HWND.
    Klar GDI+ hätte Bequemlichkeitsfunktionen a là Bitmap::DrawRotated() haben können. Dann hast du aber immer noch das Problem, dass du ein Rendertarget angeben musst.
    Dieses Target gibst du bei der Erstellung von Graphics gleich mit und folgt daher dem RAII-Prinzip (sauberes Klassendesign).

    Ich frag sicherheitshalber nochmal, weil du meinen @Ontopic Punkt so perfekt falsch verstanden hast:
    Von welchem Sumpf redest du? Gib mir genaue Beispiele und ich werd dir gerne helfen.

    Zählst du dich selbst zu Leuten die sich Gedanken machen über gutes Klassendesign und setzt das dann immer um?

    Du sagst selbst, dass du dich mit GDI+ nicht wirklich beschäftigt hast ziehst, aber darüber her, dass das alles undurchsichtig ist.
    Wenn das dein Problem ist, sprich es doch direkt an und stell eine normale Frage ohne irgendwas über Höhlen, Feuer oder anderes nichts mit dem Thema im Zusammenhang stehende zu nenen. Persöhnliche Meinungen haben in einer solchen sachlichen Debatte nichts verloren.

    "Was anwenderfreundlich ist soll jeder selbst entscheiden": der eine findet, dass es auf seine art besser geht...der andere mags lieber anders. Klar du kannst dich ewig darüber aufregen, dass die Dinge nicht so sind wie du denkst, dass sie besser wären, aber ändern wird das nichts daran, dass GDI+ so bleibt wie es ist.
    Dein "GraphicsDrawToGUI"-Code ist zB überhaupt nicht anwenderfreundlich.
    A) .., weils falsch geschrieben ist.
    B) .., weil bei jedem Aufruf ein Graphics Objekt erstellt und dann wieder gelöscht werden müsste und Performance orientiert ist was anderes. Ergo nicht anwenderfreundlich.
    Oder wolltest du mit dem Code was anderes ausdrücken?

    Was wiederum erklärt, dass du dich nicht auskennst und auch den Thread nicht verfolgt hast!Der TE bekommt es eben NICHT hin, einfachste Bildbearbeitung mit GDI(+) hinzubekommen, genau WEIL das System völlig undurchsichtig ist! Und er ist nicht allein, vielen anderen geht es genauso!
    Wie gesagt, das ist auch der Grund, wieso ich persönlich "direkte" Bildbearbeitung vorziehe. Mittlerweile habe ich mir Funktionen dafür geschrieben, um bspw. Schrift/Bilder in vorhandene Zeichnungen/Bilder einzufügen, oder Filter auf vorhandene Bilder anzuwenden, da ich nach 8 Wochen ohne GDI keinen Plan mehr habe welche Schritte im einzelnen dafür nötig sind.

    Zu unterstellen ich habe keine Ahnung oder habe den Thread nicht mitverfolgt ist absolut lächerlich wenn du selbst eine "Lösung" anbietest die nicht auf die Fragestellung des TE eingeht und dann gefühlte tausend Posts verfasst in denen du über GDI+ herziehst die allesamt nichts, mit der TE-Frage zu tun haben. Defacto OffTopic sind. Du argumentierst dich mit deinem Satz damit also selbst in Aus.
    Er/sie fragte (vereinfacht): "Wie zeichne ich ein Bild mit GDI/GDI+ möglichst ohne UI und speicher das?"
    Und wie man das GDI+ Klassendesign verändern könnte hat damit nichts zu tun. Wenn du mich schon pseudo-argumentativ angreifst bitte lies dir meine Fragen vorher genau durch und überleg dir was ich damit meine.

    Der TE bekommt einfachste Bildbearbeitung nicht hin.
    Das kann mehrere Gründe haben.
    Er/sie hat kaum Programmier-Erfahrung.
    Er/sie hat nie mit GDI+ gearbeitet und selbst wenn GDI+ anders aufgebaut wäre braucht man am Anfang immer noch Hilfe. Deine "Schlussfolgerung" das Design ist für'n Arsch ist solange Spekulation wie der/die TE nichts dazu sagt.

    Inwiefern GDI+ nicht direkte Bildbearbeitung unterstützt versteh ich nicht. Bitte erklär mir was du damit gemeint hast.
    Du hast einen Backbuffer (Bitmap) auf den zeichnest du mit Graphics. Mal ist der Backbuffer bereits mit einem Bild gefüllt, zB wenn du ein Bild lädst, mal ist der leer. Wo ist das Problem?

    Ah 8o , genau DAS interessiert ehrlich gesagt kein Schwein! Interessant ist, wie ich ein vorhandenes BILD lade, dieses rotiere, einen Teil davon ausschneide, mit Markern versehe und wieder speichere bzw. in einer GUI anzeige! Und das mit Befehlen, welche sich auf das BILD beziehen, denn DIESES wird doch bearbeitet, oder etwa nicht?!

    "DAS interessiert ehrlich gesagt kein Schwein!" persöhnliche Meinung

    "Interessant ist wie ich ein Bild lade, rotiere, Teile auschneide, anzeige, usw....Und das mit Befehlen, welche sich auf das BILD beziehen, denn DIESES wird doch bearbeitet"
    Nein das Bild wird nie bearbeitet. Mit dem Bild wird gearbeitet. Ebenso ist es nicht die Aufgabe von Bitmap mehr als nur Bilddaten zu repräsentieren.
    Da hast du eine falsche Vorstellung der Dinge.
    Das Bild wird geladen.
    Dann wird eine Transformationsmatrix gesetzt und das Bild rotiert gezeichnet und ergibt ein neues Bild.
    Das Original wurde nie verändert oder bearbeitet und hat wie bereits
    geschrieben nichts mit dem Zeichnen zu tun. Es repräsentiert nur sich
    selbst. Ein Bild kann nicht zeichnen, dafür hast du ein anderes Objekt, dessen Aufgabe nur das Zeichnen ist.

    Würdest du jz so eine Super-Alles-Könner-Klasse schreiben, dann wär dein Code so überladen, dass du dich einfach irgendwann nicht mehr auskennst wo vorne und hinten ist.
    Deswegen wird so eine Unterteilung in Funktionalität gemacht. Im Endeffekt wie prozedurales Programmiern nur halt mit Objekten.

    All das zusammen zeigt mir einfach nur, dass du keine Ahnung vom C++ Standpunkt von GDI+ hast, was wiederum zeigt, dass du dich nicht damit beschäftigt hast.
    Was auch vollkommen okay ist, aber dann unnötig persöhnlich wirst und zu guter Letzt beweist du nur, dass du versuchst mit Nicht-/Halbwissen zu "argumentieren".

    Kann es sein dass nur nie oder wenn selten objekt-orientiert programmiert hast? (reines Interesse)


    Was du möchtest ist im Endeffekt ein Zeichen-System wie das von DX/OGL.
    Du setzt deine "Leinwand" und dann kommen die Zeichen Befehle, setzt dann eine neue, evtl zeigst du das gerenderte am Bildschirm/Fenster/speicherst es in einer Textur, usw...
    Und auch da zeichnet nicht das Bild, sondern das Device (GPU) und das Original bleibt erhalten.
    GDI+ ist aber nicht so entworfen worden. Warum dich das so aufregt versteh ich ehrlich nicht.

    8 Mal editiert, zuletzt von CentuCore (5. Juli 2015 um 19:57)