Hallo DGL,

ich war schon länger nicht mehr hier, und muss sagen das neue Web-Layout ist übersichtlicher als das Alte, obwohl ich im Geiste immer noch das Alte vor mir sehe... war auch nicht schlecht.

Ok, zu meinem Problem ,

ich arbeite gerade an einem Programm das Bilder darstellen und manipulieren soll. Eine Version als nur Windows DC habe ich bereits fertig, jetzt soll OpenGL zum Einsatz kommen, da ich denke das hier viel Perfomance verschenkt würde, wenn ungenutzt. Ich habe alles auch soweit das das verschieben der geladenen Texturen, Transparenz, Skalierung etc... auch funktioniert und das prächtig.

Jetzt habe ich aber das Problem das wenn ich z.B. Teile des Bildes löschen möchte, (z.B. mit Radiergummi) das ich eine komplett neue Textur erstellen muss (für Jedes betroffene Bild ca 10MB * 10) und das in Echtzeit, und hier liegt mein Problem. Wie bekomme ich die Texturen quasi in Echtzeit manipuliert, oder ist OpenGL nicht dafür geeignet. Ich frage mich auch wie die Entwickler von Compiz das unter Linux mit der OpenGL Unterstüztung geregelt haben, dort kann man ja auch direkt auf den Bildschirm zeichnen, und das innerhalb eines OpenGL-Renderkontextes.

Danke für Eure Hilfe.
G-DC!

_________________
Gruß Andreas (aka DeepCopy) - Sic Luceat Lux

Classified Directive: initialization write in function for finalization, repeat until public case uses begin, if not case type as default, var in virtual override for while, in case of class type type asm until read begin.

Du kannst nicht nur auf den Bildschirm sondern auch in Texturen rendern. Stichwort: FBO.

Um nur Teile einer Textur zu ersetzen kann auch glCopyTexSubImage2D ganz hilfreich sein. Das funktioniert wie glTexSubImage2D, liest aber aus anderen Texturen oder dem Framebuffer.

_________________
Yeah!

Du kannst per Shader brushes erstellen und direkt in das FBO rendern, ohne wieder auf die CPU und RAM gehen zu müssen.
Dazu hat Nvidia in wärend der GF6 generation einiges gemacht guckst du hier http://developer.download.nvidia.com/shaderlibrary/packages/paint_brush.zip.

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

Projekte: https://github.com/tak2004

Danke für die Tipps,
aber ich muss mit dem Projekt noch bis Ende es Monats fertig werden, und kann jetzt
unmöglich damit anfangen shader zu erlernen, ich habe mir das so gedacht.

Ich speichere ein Bitmap das bereits als Textur vorhanden ist, stelle die Texturen
dar so wie bisher, und verwende zum Ändern der Texturen nur die Teile die sich
auf dem Bitmap geändert haben, und lade die Änderungen mit glCopyTexSubImage2D
in die Textur ein, und stelle es wie gehabt im render context dar.

Ich meine damit das ich eigentlich einen virtuellen Arbeitsbereich habe, der mit dem
Grafikkarteninhalt identisch ist, und eben diesen, anstelle der Grafikkarte bearbeite.

Vorteil für mich, ich kann alle Funktionen des device contextes nutzen, linen, rechtecke
ROP-Codes, kreise... etc... Und brauche keinen komplette neuen Code zu schreiben!

Ich hoffe ich habe klar genug ausdrückt, das ganze ist halt ein wenig komplizierter.

_________________
Gruß Andreas (aka DeepCopy) - Sic Luceat Lux

Classified Directive: initialization write in function for finalization, repeat until public case uses begin, if not case type as default, var in virtual override for while, in case of class type type asm until read begin.

Compiz nutzt Shaderprogramme, die alten halt.
Die Lösung die du dir Vorstellst wird auf jeden Fall laufen aber ist halt komplexer und langsamer als über Shader aber da du nicht drin bewandert bist dauert es dann wohl noch einiges länger.

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

Projekte: https://github.com/tak2004

Ist die von DeepCopy genannte glFunktion die schnellste NichtShader Methode um Texturbereiche auszutauschen? Nur so als Frage, ich hatte da im Hinterkopf, dass es auch eine veraltete Variante gab, die extrem schlecht performt.

_________________
Blog: kevin-fleischer.de und fbaingermany.com

Die Frage ist was man möchte. glCopyTexSubImage2D schreibt einfach nur in den Speicher der Grafikkarte. Will man aber z.B. viele identische Muster in die Textur schreiben (Brush) ist wahrscheinlich ein FBO schneller. Die FBO-Variante kann von der Grafikkarte parallel ausgeführt werden, während glCopyTexSubImage2D in jedem Fall sequenziell läuft und CPU sowie GPU bindet.

_________________
Yeah!

In einen FBO zu malen ist von der Perf mit einem normalen Szenen Rendern in ein FBO zu vergleichen nur dank scissor kann man das sogar um ein vielfaches beschleunigen(mehr mit deferred shading zu vergleichen). Man muss allerdings beachten, das die Performance dann stark vom Brush abhängt. Man macht ein Texturbinding auf das Brush und legt die Farbe z.B. über die Vertexcolor fest. Dann kann man dann malt man das Brush auf das FBO, hierbei braucht man 2 lesezugriffe(FBO aktuell,Brush) bei Texturbrushes pro Pixel und 1 schreibzugriff(neuer FBO Pixel). Einfach ein Quad mit der Textur zeichnen und kein glClear nutzen(das blending macht dann die arbeit). Man kann auch die ganzen Postscreenfeatures und so weiter drauf anwenden, die sind natürlich wesentlich rechenintensiver aber selbst das ist ein Witz, da ja jedes game von vor 3-4 Jahren selbst sowas schon macht.
Adobe Photoshop wird seit CS1 oder 2 schon experimentell mit OpenGL1.5>= und glsl das interne rechnen auf cpu ersetzt, guck mal bei youtube rein, findest einige videos von denen.

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

Projekte: https://github.com/tak2004