Hallo.
Ich bin seit Sommer am Coden von einem Malprogramm, und alles läuft eigentlich recht gut.
Ich frage mich blos ob die Entscheidung die gesamte Oberfläche mit OpenGL umzusetzen schlau war,
bzw. ob es so wie ich es zur Zeit mache vielleicht zu langsam läuft.

Es ist in C++ geschrieben und nutzt die WinApi. *hust*

Was Ich schreibe soll möglichst plattformunabhängig sein, deshalb nutze ich die WinApi so selten wie möglich
und versuche die Oberfläche mit OpenGL zu zeichnen(Buttons, Text, etc)...Sodass ich vielleicht später auch mal für KDE schreiben kann, ohne zu viel ändern zu müssen.

1.Frage: Mit SDL könnte ich doch die WinApi dann völlig ersetzen und könnte es unter jeder Plattform laufne lassen,
oder sehe ich das falsch?
In der Wiki stand auch das es sich nicht sehr gut dazu eignet um ein GUI zu machen und es sei für den
Vollbildmodus
(Ich möchte allerdings dass man das Fenster auf dem Desktop hat und es frei skalieren kann)

2.Frage: Wenn nicht SDL, welche Api könnte man noch nutzen die möglichst plattformunabhängig ist und auch leicht
OpenGL einbinden kann? ...Ich persönlich dachte da auch schon an Java.

3.Frage: Soll Ich Überhaupt OpenGL nehmen? Ich frage mich wirklich was schneller ist, entweder die ganzen GL_POINTS
jedes mal neu von der Grafikkarte zeichnen lassen, oder das gleich mit TCanvas oder solchen Geschichten über den
CPU regeln?

Der Hauptgrund warum ich zur Zeit mit OpenGL arbeite ist eigentlich, dass ich mich nicht wirklich mit der WinApi auskenne
und ich mein unter Delphi erlerntes OpenGL Wissen bei C++ mit der Dev-Cpp Entwicklungsumgebung gleich anwenden konnte.
Ich bin sozusagen seit Sommer ein C++ Neuling und wollte mit diesem Malprogramm, was ich durchaus als ernstes Projekt bezeichnen kann, mich in der Sprache üben(OOP kennen lernen etc).

Welchen Weg würdet ihr mir am ehsten raten? Bzw. schätzt bitte mal meine Situation ein.
Ich entschuldige mich dafür als C++ler (bzw. bin ich ja noch etwas unentschieden) das hier zu fragen. Allerdings ist das hier der beste deutsche Anlaufpunkt für OpenGL.

Wenn Interesse besteht, bin ich durchaus bereit ich mal das Prog zu zeigen.

Puh das ist ganz schön viel auf einmal. Aber die Prgrammiersprache ist egal also mach dir da mal keine Sorgen. Das was du hast ist eher ein generelles Struktur Problem.

Platformunabhngigkeit: Ja mit SDL geht so etwas. Bei einer Größnänderung des Fensters besteht unter Windows das Problem, dass der RenderKontext zerstört wird. Das bedeutet du musst nach einer Veränderung alle Texturen etc neu laden. Das sollte bei einem Programm wie deinem recht Problemlos möglich sein.

OpenGL oder nicht?: Also GL_POINTS würde ich nur benutzen wenn du auch mit Sprites arbeitest. Dabei werden auf jeden Punkt eine Textur gepackt. Das lohnt aber nur wenn die Sprites größer als 1 Pixel sind. Und dabei würde es sich eigentlich lohnen, wenn du deine Ergebnisse in eine Textur zeichnest.
So könntest du auch weiche Pinsel benutzen. Da du mit der Grafikkarte blendest

Ds könntest du aber auch ohne tun. Dazu müsstest du lediglich die Pixel in den Speicher reinrechnen. Das ist aber recht unabhängig von der Windows API.

Aber auf beiden Seiten solltest du dir gut überlegen was du machst. Soll bedeuten, dass das genau der zeitkritischste Punkt überhaupt ist. Und der muss gut optimiert werden.

Da werde ich mir SDL sicher nochmal genauer anschauen.


Da haben wir doch schon mein Problem.
So ich wie zur Zeit arbeite scheint mir als wenn ich die Vorteile die einem durch OpenGL geboten werden, gar nicht richtig ausnutze.

Ich lade das Bild aus einer Datei in den Hauptspeicher(nicht in die Grafikkarte).
Dann wenn ich mit Pinselstriche ziehe, werden die Pixel im Hauptspeicher durch den CPU manipuliert, und die geänderten Pixel werden
werden an Grafikkarte gesendet um gezeichnet zu werden.
Ich kenne mich nicht wirklich damit aus, was man mit Pixelshadern machen könnte, um Pixel zu manipulieren.
Außerdem weis ich noch nicht wie man diese dann wieder aus dem Grafikspeicher raus bekommt, um das Bild speichern zu können, etc.

Ich könnte ja dann auch immer bloß Teile des Bildes in den Speicher bringen, da ich große Formate unterstützen möchte.
Bei älteren Rechnern würde das besonders wichtig sein.

Man erkennt also dass ich nicht ohne Grund im Einsteigerbereich gepostet habe ^^
Wäre also nett wenn mir jemand einen Ausblick geben könnte, inwieweit es mir Vorteile bringt mit Unterstützung von der Grafikkarte
das umzusetzen.
Wäre der CPU nicht schneller wenn er Pixel manipuliert?(ohne Darstellung)

Übrigens danke für die schnelle Antwort.

Wir bemühen uns immer so schnell wie möglich zu antworten.

CPU vs GPU: Was dabei schneller ist kommt wohl ganz darauf an was du genau vor hast. Wenn du zum Beispiel einfach nur einzelne Pixel anders Färben möchtest wäre es wohl besser, wenn du das im Hauptspeicher machst. Da ist das Handling einfacher. Wenn es aber halbtransparent sein soll dann dürfte wohl die GPU gewisse Vorteile bieten.

Aber so weit wie ich weiß benutzen die aktuellen Programme wie GIMP oder Photoshop keine besondere Beschleunigung. Die haben ihre Algorithmen extrem optimiert. Will dafür aber meine Hand nicht ins Feuer legen.

Speziell wenn es wirklich darum geht, dass die Bilder extrem groß werden können denke ich das du an die Grenzen der GPU stoßen wirst. Also falls die Bilder zu groß werden. Wenn du mit Ebenen arbeiten willst wirste das noch früher erreichen.

Okay. War vielleicht ein bisschen wirr alles. Schaue gerade die Simpsons nebenbei. Aber eigentlich wollte ich damit nur sagen, dass du dir sehr gut überlegen solltest was du jetzt alles an Features brauchst und was evtl später noch ganz sinnvoll wäre. Evtl schließt das alles ja schon eine Hardwarebeschleunigung aus.

Hi,

ich habe ja ein kleines Malprogramm in meinem Flipbook (siehe Projekt-Bereich) eingebaut... ich lasse es da alles über die CPU berechnen und nur via OpenGL darstellen.

Sprich, ich zeichne im grunde im Hauptspeicher eine Textur welche dann von OpenGL dargestellt wird (= Zoomen etc kommt wieder von OpenGL)

Aya~

Zu dem Thema solltest du dir mal nach FBO googeln, dass sollte dann alles ein bischen schneller machen.
Vieleicht noch ne gute Gui nutzen (XD_GUI vorschieb ^^).
Die größte arbeit wirst du mit Strukturen haben.
Z.B. Layer, States für Rückgängig, Brushsystem und so weiter.
Wenn du SDL verwendest, wirst du auf MDI Style arbeiten müssen aber PhotoShop tut das ja auch.

_________________
"Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren"
Benjamin Franklin

Projekte: https://github.com/tak2004

Ich rate für die GUI auf jeden fall zu einem fertigem Toolkit wie GTK oder QT, wenn das programm komplexer wird. Um die eigendlichen Stärken von opengl auszunutzen könnte man dann den Arbeitsbereich als Texturen (je eine für jeden Layer) nutzen. Auch wenn man keine mipmap verwendet, ist es doch mit multisampling sehr einfach möglich zu zoomen. Zusätzlich könnte man Layer auch verdrehen. EIn weiterer vorteil wäre das man durchgehend im float16 format arbeiten könnte, was das programm dazu in die lage versetzten würde im HDR zu bearbeiten. (Allerdings sind 256 MB Graka ram ganz schnell weg: 8 byte Per Pixel erlauben noch 32 Mpixel was gerade noch 4000x8000 entspricht und recht schlenn bei mehreren Layern verbraucht ist) Filter und Tools usw könnte man dann recht einfach in GLSL schreiben. Auf undo/redo könnte man wahrscheinlich verzeichten und nur einen Binlog mit aufzeichnen, da ein replay aller aktionen sehr schnell gehen sollte.

Ich muss hier einfach auch meinen Senf dazugeben.
Ich würde die Aussage, dass sich SDL nicht so gut dafür eignet, eine GUI zu schreiben, nicht unterschreiben. Ja es gibt in Windows die Hürde, dass bei einem Fensterresize der Rendering Context flöten geht. Alles, was Du der Grafikkarte anvertraut hast (Texturen, VBOs etc.) geht dabei verloren. Das ist lt. Phobeus ein Windows-spezifisches Problem. Aber Dir als Grafikprogrammierer sollte es eigentlich nicht schwer fallen, so etwas aufzufangen (Fenster-Resizes passieren nicht so oft wie man glaubt). Das ist bisher der EINZIGE Nachteil, den ich bei SDL bemerkt habe.
@edit: Vielleicht gut zu wissen: SDL kann nur Bilder laden, aber nicht speichern mit der Ausnahme des Windows BMP-Formats.

ÜBRIGENS stellt das SDL eine GUI zur Verfügung, aber eben SDL-spezifisch.

Ich habe genau das gleiche Problem wie der Starter dieses Threads. Ich will Plattformunabhängigkeit (allerdings schreibe ich in Pascal) Ich habe wirklich intensiv nach einer passenden GUI gesucht. GUIs gibts wie Sand am Meer, siehe z.B. http://www.free-soft.org/guitool/ (ich lege für die Aktualität dieser Seite nicht meine Hand ins Feuer, also googeln wäre noch angebracht). Allerdings lohnt es sich, auf diese Kandidaten einen genaueren Blick zu werfen:

Zum Stichwort GTK und Plattformunabhängigkeit: Die Möglichkeit FreePascal+GTK gibt es offenbar nur theoretisch. Aus der Mailing List von Free Pascal habe ich Folgendes noch in Erinnerung, was einer der Macher von Free Pascal geschrieben hat: "Nicht einmal Lazarus verwendet für Windows das GTK". Darüber würde ich nachdenken.

Zu QT gibts im Wikipedia folgende Anmerkung: "Die Klassenbibliothek steht sowohl unter der GNU General Public License (GPL) als auch unter einer kommerziellen Lizenz, welche allerdings nur benötigt wird, falls mit der Umgebung Produkte entwickelt werden sollen, die nicht wiederum unter einer freien Lizenz stehen. (siehe Duales Lizenzsystem)". Also ist es nicht wirklich frei verwendbar.

Traude

Hab mir mal SDL angeschaut und es scheint nicht all zu schwer zu sein den Umstieg zu wagen
Werde dann die Grafikkarte vorwiegend für ein grafisch ansprechendes und intuitives GUI nutzen.
Ich denke da an halb transparente Fenster mit einem leichten Blur(Milchglaseffekt wie bei Vista) oder aufleuchtende Buttons oder ein schön animiertes aufpoppen von Fenstern.
Hach ja, mit OpenGl kann man ja so viel träumen.

Ich werde mir dementsprechend ein eigenes GUI entwickeln, da ich erstmal eigene Erfahrungen sammeln möchte, und auch noch nicht so den Wissenstand habe um mit diversen Bibliotheken zu hantieren.