ImageBuffer
Übersicht

![]() |
Mathias-KwiatkowskiBetreff: ImageBuffer |
![]() Antworten mit Zitat ![]() |
---|---|---|
ImageBuffer gibt es ja nicht mehr. was ich aus dem topic (link unten) entnommen habe. mein problem ist.
GrabImage = viel zu lahm GrabPixmap = um die hälfte schneller als GrabImage damit immernoch viel zu langsamm. was muss ich also genau machen um mehrere bilder als eines zu verknüpfen und dies dann direckt irgendwie in einem image zu bekommen? z.b. habe ich in der vergangenheit ne gui geschrieben die extrem langsam war aufgrund 1 fenster (window) hatte 9 bilder, bei 10 fenstern habe ich 90 bilder die ich male, dann kommt noch drawtext was das ganze unschön herunterzieht. gott segne weitere gadegts. all die probleme würden nicht sein wenn ich etwas in einem image direckt malen könnte ohne 500ms delay von grabimage abzuwarten (naja 500ms bei grossen fenstern, was aber möglich ist) gibt es ein modul dazu? oder vergleichbare tutorials ect, andere hilfestellungen? wie machen es die guten profies hier von euch? ![]() Eine kleine anmerkung habe ich noch ich habe das gefunden, was genau mein problem beschreibt. war mir aber nicht sicher ob ich dieses alte topic verwenden darf und es somit aus der vergessenheit hole. aus diesem grund habe ich dieses eröffnet. falls es falsch gewesen ist bitte ich um die verschiebung in dem alten topic. (welches nicht von mir war) leider ist dort aber auch keine lösung für mein problem enthalten. https://www.blitzforum.de/foru...07608993fc ich bedanke mich im vorraus, und hoffe das es eine gute möglichkeit gibt. |
||
Skype: Anarchie1984
http://projektworks.de/maxbase/ Icq - Erneuert am 21.08.2017 Yahoo - Erneuert am 21.08.2017 |
![]() |
BtbN |
![]() Antworten mit Zitat ![]() |
---|---|---|
Wenn du kein Problem damit hast, dass das nur mit OpenGL funktioniert, render einfach das Fenster in ein FBO, und nutz die resultierende textur wenn du das Fenster zeichnen willst. | ||
![]() |
Mathias-Kwiatkowski |
![]() Antworten mit Zitat ![]() |
---|---|---|
oha von open gl habe ich 0 ahnung und das was du geschrieben hast ehrlichgesagt habe ich es nicht verstanden , was also ist ein FBO und wie kann ich das ganze benutzen? | ||
Skype: Anarchie1984
http://projektworks.de/maxbase/ Icq - Erneuert am 21.08.2017 Yahoo - Erneuert am 21.08.2017 |
![]() |
BtbN |
![]() Antworten mit Zitat ![]() |
---|---|---|
Ein offscreen-rendertarget, was man mit einer Textur verknüpfen kann.
Du renderst dann da rein dein Fenster, und anschließend nurnoch die Textur, wenn du das fenster zeichnen willst. Das ganze ist absolut echtzeitfähig, auch mit mehreren dutzend fenstern. |
||
![]() |
Midimaster |
![]() Antworten mit Zitat ![]() |
---|---|---|
ich kann mir gar nicht vorstellen, dass das Zeichnen der 9 Bilder pro Gadget die Performance herunterzieht. Windows macht das ja ähnlich und zerlegt seine Elemente in noch viel kleinere Teile. So wird z.B. immer nur das gezeichnet, was nicht von darüberliegenden Elementen sowoeso wieder verdeckt werden wird. Das Stichwort lautet hier RECTANGLE Struktur. Die setzen voll auf sowas....
Zudem sind ja 8 deiner 9 Elemente immer sehr klein. Hast Du schon mal geprüft, welcher Teil der Zeit für das mittlere Feld draugeht? Dritter Tipp: Die 9 Elemente können mit DrawSubImageRectangle aus einer gemeinsamen Vorlage gezeichnet werden. dies bringt unter Monkey Zeitverbesserungen. Möglicherweise ja auch unter BlitzMax? |
||
Gewinner des BCC #53 mit "Gitarrist vs Fussballer" http://www.midimaster.de/downl...ssball.exe |
![]() |
BtbN |
![]() Antworten mit Zitat ![]() |
---|---|---|
Windows erzeugt aber seine Fenster nicht durch das rendern von zig bildern, sondern wesentlich effizienter und mit für 2D Grafik optimierten funktionen.
Das Compositing von Windows Vista und höher wird außerdem vermutlich genau das selbe tun, und die Fenster in eine Textur rendern. |
||
![]() |
Mathias-Kwiatkowski |
![]() Antworten mit Zitat ![]() |
---|---|---|
naja 9 bilder zieht nichts runter es macht die masse...
9 bilder= 1 fenster titel des fensters "Mathias" = weitere 7 bilder nun nehmen wir an wir haben slider rechts und slider unten mit nem rahmen rahmen=1 bild slider 1 bild zusammen 4 bei 2 slidern so jetzt haben wir nen button drin 1 bild button text "Hallo Welt" = 10 bilder ich möchte nun gar nicht mit flexibelen textgadgets anfangen oder aren. somit hätten wir 30 bilder für 1 fenster (1 FENSTER) bei mehrern fenstern bleibt da kaum noch platz für das darunterliegene spiel. und wie gesagt textbasierte felder ausgelassen. windows macht es im übrigen nicht so das fenster wird scaliert gerandert und ebenso als bild hinterlegt und wenn das fenster inaktiv ist wird es gar mit dem desktop hintergrund icons ect verschmelst, das bringt demnach mehr preformence als ob man ein _"teil gerüst" bastellt so denke ich zumindest wird es miki soft machen. wenn man ein alten rechner mit wenig speicher zu hand hat ( mein netbook ) kann man dies auch fast deutlich sehen 1gb ram xD win 7 starter is darauf. und für das ding ist windows schon ein spiel. dort aber wie gesagt kann man es sehen das wenn ein fenster aktiv ist die cpu richtig gefressen wird. was Btbn gesagt hat klingt gut nur gibt es dazu ein tutorial wie ich es auch umsetzen kann? |
||
Skype: Anarchie1984
http://projektworks.de/maxbase/ Icq - Erneuert am 21.08.2017 Yahoo - Erneuert am 21.08.2017 |
![]() |
BtbN |
![]() Antworten mit Zitat ![]() |
---|---|---|
Ist im OpenGL wiki mit einigen Beispielen dokumentiert.
http://www.opengl.org/wiki/Framebuffer_Object |
||
PhillipK |
![]() Antworten mit Zitat ![]() |
|
---|---|---|
Und ich verweise gerne auf die Delphi-GL wiki seite, da die tutorials einfach super sind *find*
http://wiki.delphigl.com/index...fferobject Ich für meinen teil habe sogut wie alles, was ich über OpenGL weiß, von dieser seite. Allerdings musst du die beispielcodes entsprechend interpretieren; die funktionsnamen sind aber 1zu1 auch in Blitzmax vorhanden. |
||
![]() |
DAK |
![]() Antworten mit Zitat ![]() |
---|---|---|
Bei einer GUI könnte es helfen, Flip nicht so oft aufzurufen / nicht jedes Frame was zu zeichnen, sondern nur, wenn es notwendig ist. Nimm mal z.B. Fraps und lege es über ein beliebiges GUI-Programm, z.B. Chrome und schau, wie es mit den FPS ausschaut. Bei mir hat Chrome üblicherweise 1 FPS außer wenn sich was am Bild ändert, dann hat es 30+ FPS. Wenn sich nichts ändert, braucht man auch nichts neu zeichnen.
Und wenn sich ein kleiner Teil des Bildschirms ändert aber nicht alles, wie es z.B. der Fall ist, wenn nur ein Fenster sich ändert, dann mal ein schwarzes Rect über das Fenster (statt einem CLS) und mal nur das Fenster neu. Die Android-GUI z.B. hat eine View-Hirachie. Du hast da als oberstes Element das ganze Fenster in dem alle sichtbaren Elemente als Kinder (oder Kinder von Kindern) angehängt sind. Wenn ein Element ein Bildupdate braucht (z.B. wenn sich der Text eines TextViews oder so ändert), dann wird für den invalidate() aufgerufen, was dafür sorgt, dass dieses Element neu gezeichnet wird. Dieses invalidate() wird dann an alle Kindelemente weitergegeben, und auch die werden dann neugezeichnet. Auf diese Weise wird immer alles was notwendig ist neugezeichnet und alles was kein Update gehabt hat, bleibt einfach unverändert am Bildschirm. Dafür brauchst du gar kein render to texture sondern musst nur auf den Framebuffer rendern. Musst hald schauen, dass du immer beide Buffer (Front- und Backbuffer) gemeinsam updatest. Gleichzeitig ist es auch wesentlich schneller als per render to texture. Bei render to texture renderst du jedes Teilbild (=Fenster) bei Veränderungen in eine Grafik. Ab dann musst du jedes Frame jedes Bild neu zeichnen. Ist zwar schneller als wenn du jedes Frame alles von neu zeichnest, aber du musst trotzdem jedes Frame was machen. Diese Methode hat also hohe Kosten bei Änderungen (um auf die Textur zu rendern) und mittlere Kosten zwischen den Änderungen. Verwendest du den Inhalt des Framebuffers, dann brauchst du nur bei Änderungen einmal was zeichnen und ohne Änderungen brauchst du gar nichts zeichnen (eventuell wäre es trotzdem nicht schlecht, ein mal pro Sekunde oder so alles neu zu zeichnen um eventuelle Bildfehler auszubügeln). Du hast also hohe Kosten bei Änderungen (ähnlich wie bei render to texture, nur dass du nicht auf die Textur sondern den Framebuffer renderst) und quasi keine Kosten zwischen den Änderungen. Musst nur aufpassen: Wenn sich zwei Fenster überlappen und eines verschoben wird, musst du beide neuzeichnen. |
||
Gewinner der 6. und der 68. BlitzCodeCompo |
- Zuletzt bearbeitet von DAK am So, Dez 01, 2013 11:40, insgesamt 2-mal bearbeitet
![]() |
BtbN |
![]() Antworten mit Zitat ![]() |
---|---|---|
Da es keinen bezeichnebaren frontbuffer gibt, ist das nicht möglich und wäre auch enorm instabil und aufwändig im vergleich zu einer simplen Render-To-Texture lösung. | ||
![]() |
DAK |
![]() Antworten mit Zitat ![]() |
---|---|---|
Natürlich kannst du nicht direkt auf den FB zeichnen, aber folgendes geht:
FB (altes Bild) BB (egal was) Render -> BB flip() Render -> BB (der ja der FB war) Das war, was ich gemeint habe, mit beide Buffer berendern. Der zweite Render auf den BB ist notwendig, damit man das Ganze beim nächsten Mal wiederholen kann. Das ist genau das System, was die Android GUI verwendet. Kann man sich bei Android 4+ sogar anzeigen lassen, welche Bildteile gerade aktualisiert werden (Einstellungen -> Entwickleroptionen -> Bildschirmaktualisierungen anzeigen). Ist mies für Spiele (wegen den höher als normalen Kosten für Änderungen) aber für GUIs ist das wie man es machen sollte. Die Render-to-Texture hat dabei aber die gleichen Nachteile für Spiele. |
||
Gewinner der 6. und der 68. BlitzCodeCompo |
![]() |
BtbN |
![]() Antworten mit Zitat ![]() |
---|---|---|
Es ist in keiner weise garantiert dass man nach einem Flip den alten Frontbuffer wieder vor sich hat.
Und den kram schonmal vorrendern und dann pausieren ist auch absolut keine option, weil dann das ganze Programm nicht mehr flüssig auf eingaben reagieren kann, und das ganze außerdem für Ingame-GUIs mehr als suboptimal wäre. Generell wäre das ganze unterfangen völlig sinnlos kompliziert. Einfach das Fenster in eine Textur rendern und gut ist. |
||
![]() |
DAK |
![]() Antworten mit Zitat ![]() |
---|---|---|
Aus der Dokumentation:
Zitat: Flip swap the front and back buffers of the current graphics objects.
Also doch, man kriegt den Frontbuffer zurück. Wie das ganze üblicherweise gemacht wird, ist dass nicht tatsächlich der Inhalt des Buffers rübergeschrieben wird, sondern nur die Referenz auf den Buffer geändert wird. Man hat dann hald einen Speicherbereich A und einen B. Vor dem Flip ist FB = A, BB = B, nach dem Flip ist FB = B, BB = A. Der Inhalt wird dabei nicht verändert. Für ein Spiel, dessen veränderliche Objekte in der GUI liegen (z.B. Animationen usw. die in der GUI in einem Fenster ablaufen) ist dieses System perfekt. Liegt die GUI über veränderbaren Objekten, dann geht es nicht. Muss man hald richtig planen. Wo hast du die Idee mit dem Pausieren her? Davon habe ich nichts geschrieben. Was ich gemeint habe ist, dass du einfach nicht neuzeichnest, nicht dass du irgendwas pausierst. Deine Hauptschleife rennt weiter, nur wenn es keinen Input gibt und sonst auch keine Änderungen, dann zeichnest du einfach nicht. @Instabil und kompliziert: Ich hab grad in rund einer halben Stunde eine kleine Demo geschrieben. Die ist noch nicht wirklich optimiert (Block-invalidation funktioniert noch nicht richtig), rennt aber auch schon so sauschnell. Bei 500 Fenstern mit je 5 klickbaren Buttons braucht es im Leerlauf 1% CPU bei mir. Das klicken der Knöpfe kostet gar nichts an Leistung. Einzig das Verschieben eines Fensters schiebt die CPU auf 7% hoch, da da noch alle Fenster neu gezeichnet werden. Wenn ich die Blockinvalidation noch richtig hinkrieg, dann würde es auch beim Verschieben von Fenstern nur noch die Fenster, die überschoben werden, neuzeichnen. Hat man eine sehr hierarchische GUI (was ja hier nicht der Fall ist, da mein GUI-Baum nur drei Ebenen tief ist (Desktop-Fenster-Buttons), die eher in die Tiefe geht und weniger in die Breite, dann ist auch der momentane Ansatz schon extrem schnell. BlitzMax: [AUSKLAPPEN] SuperStrict |
||
Gewinner der 6. und der 68. BlitzCodeCompo |
![]() |
BtbN |
![]() Antworten mit Zitat ![]() |
---|---|---|
Nein, was im Backbuffer nach dem SwapBuffers ist, ist völlig undefiniert.
Es hängt vom verwendeten OpenGL system(GLX, WGL, ...) und Treiber ab, und ist absolut nichts, wodrauf man sich in irgend einer Weise verlassen kann. Und was willst du eigentlich beweisen? Dass eine enorm komplexe und anfällige Lösung, wenn richtig implementiert, eventuell funktionieren kann? Ist ja schön und gut, das ganze in eine Textur zu rendern wären ein paar Zeilen, und würde keinerlei Probleme verursachen, und ist vorallem wunderbar für Ingame-GUIs geeignet, wo man nicht mal eben aufhören kann zu rendern. |
||
![]() |
count-doku |
![]() Antworten mit Zitat ![]() |
---|---|---|
Moin,
Um mal von der (unnötigen) Diskussion zu Mathias Problem zurückzukommen, ich löse das ganze mit klepto's Render2Texture. Das verwendet die Framebuffer Objekts von OpenGL, welche oben schonmal angesprochen wurden. https://www.blitzforum.de/foru...hlight=fbo Unten in seinem Code ist auch ein Beispiel drinne, im Grunde musst du einfach nur: BlitzMax: [AUSKLAPPEN]
Das Bild kann dann später mit dem normalen DrawImage gezeichnet werden. Wichtig ist nur, dass du OpenGL Graphicsdriver lädst und glewInit() aufrufst. Steht aber alles im Beispielcode drinne. Ist dann wie der ImageBuffer in BB ![]() lg, Count-Doku |
||
![]() |
Mathias-Kwiatkowski |
![]() Antworten mit Zitat ![]() |
---|---|---|
das ist eine sehr gute variante, ich versuch seit dieser zeit als du es gepostet hast anzuwenden, aber eines hindert mich.
mach dir ein punkt im image (links oben also plot 0,0,) und dieser punkt ist dann nicht mehr oben links sondern im image unten rechts, warum is das so und wie geht es anders? so das es nicht mehr spiegelverkehrt ist? |
||
Skype: Anarchie1984
http://projektworks.de/maxbase/ Icq - Erneuert am 21.08.2017 Yahoo - Erneuert am 21.08.2017 |
![]() |
count-doku |
![]() Antworten mit Zitat ![]() |
---|---|---|
Oh ja sry, habe ich vergessen zu erwähnen. Es ist spiegelverkehrt xD
Einfach entweder schon beim Render2Texture oder später beim Zeichnen ein SetScale 1,-1 oder so verwenden. Je nachdem um welche Achse es gespiegelt ist. Ein Codebeispiel, hier wird beim Anzeigen gespiegelt: BlitzMax: [AUSKLAPPEN] TImageBuffer.Init(800, 600) 'Same as Graphics but set to GLDriver + glewinit Du könntest auch das gespiegelte Bild wieder in ein neues Rendern, das wird dann aber glaube ich, zu rechenaufwendig. Aber einfach immer das SetScale sollte nicht den Unterschied machen, zumal du es ja sowieso bei so ziemlich allen R2T Objekten brauchen wirst ![]() lg, Count-Doku |
||
Übersicht


Powered by phpBB © 2001 - 2006, phpBB Group