So in etwa Frase.

Wann es etwas geben wird ist übrigen eine sehr gute Frage. Das richtet sich ganz nach dem was ich sonst noch zu tun habe und wie es priorisiert ist. Habe derzeit noch zwei Sachen die noch höher priorisiert sind. Aber diese sind beide in etwa bei 90%. Bei den Fonts denke ich mal, dass ich da recht schnell etwas benutzbares vorlegen kann. Ich weiß, dass ist in etwa so genau wie "When its done". Aber ich bemühe mich redlich, dass es nicht den typischen "when its done" Effekt annimmt. Also Jahre. Der fehlt Laden/Speichern, ein sinnvolles Klassenkonzept und abschließende Änderungen an der glBitmap. Dann könnte man die Fonts benutzen. Wenn die dann noch in die Controls eingebaut sind, dann kann man schon ein bisschen was mit anstellen. Ich werfe da jetzt einfach mal einen Monat in den Raum. Bitte nicht schlagen, wenn ich es unter oder überbiete. Aber so ein bisschen Zeitdruck kann ja bekanntlich wunder wirken.

Einen ganzen Monat? Ohje...

_________________
"Für kein Tier wird so viel gearbeitet wie für die Katz'."

Was erwartest du? Hast du jetzt damit gerechnet, dass ich sagen in einer Woche gibbet was. Wenn du so willst besteht das auch 3 Projekten und die haben alle einen gewissen Komplexibilitätsgrad erreicht. Und ich bin derzeit noch mit unserem OpenGL Header beschäftig. Bzw sollte das von meiner Seite aus so weit fertig sein. Und bevor ich die glBitmap veröffentlichen kann muss erst einmal der draußen sein. Und die neuste glBitmap wird zwingend für die Fonts benötigt. Die ihrerseits wieder für die Komponenten benötigt werden. An der TextSuite schreibe ich auch schon seit über 2 Monaten. Abgesehen davon muss ich nebenbei auch arbeiten.

Sorry falls euch die Antwort nicht gefällt aber das ist eine realistische Schätzung. Wie gesagt. Kann auch sein, dass ich das gnadenlos unterbiete kann aber auch passieren, dass es länger dauert. Kommt ganz darauf an wie viele Probleme ich habe. Und das Format der Fonts sollte ja irgendwo schon fest stehen. Also nicht, dass sich das ständig ändert.

Holdiro,

hätte mal ne Frage. Wenn ich ein OpenGL GUI bastele (oder deines verwende) und das in einer Anwendung die jede Menge Rechenintensive Berechnungen auf der GPU durchführt (so aufwendig das sie bei weitem nicht in echtzeit laufen!). Gibt es dann irgend ne Möglichkeit sicherzustellen das während der Berechnungen das UI nicht einfriert ?

Gruß,
Thorsten

Allgemein ist das ein Fall fuer Threads! Siehe: http://wiki.delphigl.com/index.php/Tuto ... ithreading

_________________
Danke an alle, die mir (und anderen) geholfen haben.
So weit... ...so gut

Danke schonmal, ich kenn das Tut auch...liegt bei uns in der Arbeit aufm Klo (und unter Männern ist das ja ein großes kompliment ). Allerdings ist das Problem das ich befürchte meines Erachtens nicht mit Threads zu lösen. Wäre es ein CPU GUI dann wäre es kein Problem. Ein Thread kümmert sich um OpenGL, einer um die GUI...aber da beides ja OpenGL beschleunigt sein soll, wird ja beides auf der Karte berechnet, und dann wäre das GUI ja eingefroren während die GraKa mit den Berechnungen beschäftigt ist. Denn auf der GPU ist meines Wissens kein Multithreading möglich, oder ??

Gruß,
Thorsten

glaub da hast du recht. Man kann zwar OpenGL aus mehreren Threads ansteuern, aber ob das dann wirklich irgendwie Parallel ausgeführt wird, weiß ich net.

Man müsste sich ne Art "TimeSharing GPU" bauen, also irgendwie den GPU-Registerinhalt und den Speicherinhalt sichern, und dann kurz die UI einblenden. Was aber die berechnungen u.u. stark in Mitleidenschaft ziehen kann.

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

Yep...da ist dann vor lauter "Administration" vieles an Geschwindigkeitsvorsprung wieder dahin...mal ganz abgesehn von der Fehleranfälligkeit durch den zusätzlichen aufwand. Ne möglichkeit wäre vielleicht die Berechnungen einzig und allein auf nicht sichtbare Rendertargets zu beschränken und die GUI auf´s nötigste beschränken. Aber ich hab keinen blassen schimmer ob die sich dann immernoch beeinträchtigen oder nicht.

Thorsten

Hmmm.... Eventuell gehts doch.

Die GUI muss ja nicht ständig frisch gezeichnet werden, sondern nur alle Sekunde mal.
Die Bedienung (auswertung der Ereignisse) läuft ja weiterhin über die CPU. Reagieren sollte die GUI also weiterhin normal (nur sehen tut man etwas verzögert). Ich weiß ja nicht wie du auf der GPU etwas berechnest. Rufst du einen Shader, in einer Schleife immer wieder auf? Dann könntest du ja, alle Sekunde mal kurz die GUI rendern lassen, den Framebuffer flushen und dann weiterrechnen. Oder brauchst du den Framebuffer? Hmmm...dann könntest du die GUI im Framebuffer rendern, und die Berechnungen dann auf einen anderen Puffer umlenken.

Erzähl mal mehr. Wenn die Shaderspezies sich dass mal durchlesen kommt vielleicht noch was dabei rum. Bin leider auf dem Gebiet ein echter Noop

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

Ich bin noch früh in der Planungsphase...was ich wie berechne weiß ich noch nicht. Im Endeffekt soll ein kleines aber feines Compositing-Tool be rüber kommen. Also im Prinzip Video-Effekte und Layergeschichten. Das Standard antialiasing ist aber keineswegs produktionstauglich....müsste also in nem Shader passieren um Qualität garantieren. Und wenn man das ganze mit vielen Layern und n paar Blurs, nem Erode oder Dilate, nem RadialBlur und nem Glow kombiniert kommt da schnell was zusammen. Nochdazu soll das ganz Nodebasiert sein und dann werden Composites sehr schnell SEHR aufwendig.

Das Problem ist (zwecks UI jede Sekunde neu zeichnen) das bei EINFACHEN sachen das ganze in Echtzeit laufen soll und man während dem Playback zum beispiel an nem einfachen Fastblur regeln kann ohne Pause zu machen. Vielleicht muß ich mich einfach von der OpenGL GUI verabschieden, aber 3d-Beschleunigte UI´s sind so schön fix und responsiv! (Siehe z.B. Picasa)

Thorsten

Sowas sollte eigentlich gehen. Ich glaub sowas hat sogar schonmal hier gemacht (oder angefangen, oder... ich weiß net mehr genau).

Ich dachte schon, du willst irgendwelche Kryptographischen Sachen berechnen, oder die GPU anderweitig missbrauchen. Sowas hatten wir hier alles schon. Also solche Shader sachen mit ner GPU sind definitiv machbar. Die UI ist ansich ganz simpel (auch wenn Lossys UI etwas mehr kann als z.B. meine). Zumindest ist eine GU für die Graka nur ein paar Quads mit Textur. Das machen die mit Links. Ich denke da kannst du beruhigt diese Schiene angehen.

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

Lossy´s Demo sieht ja schonmal sehr fein aus. Ich werde (von wegen nodebasiert) einige relativ eigenwillige Bedienelemente. Wenn die erweiterung und einbindung von Lossy´s system sich einfach gestaltet wäre das vermutlich ne große Arbeits-erleichterung. Man wird sehen....werde vermutlich erst mal ein paar tests mit layering und
shadern machen um mich da einzuarbeiten.

Thorsten

So lange es da zum Lesen liegt.

Mit den Threads hast du vollkommen recht. Du kannst die Berechnung nicht in einen externen Thread auslagern und dabei immer noch auf den selben Kontext zugreifen. Was aber evtl. gehen dürfte wäre, wenn du mit dem Thread in einen PBuffer renderst und diesen dann in den Komponenten (VCL THread) verwendest. Allerdings musst du dann auch einen definierten Zustand erreichen. Also sollte das Bild schon fertig sein und nicht noch gerade gerendet werden. Wobei man das auch mit Events und DoubleBuffering im PBuffer ganz gut lösen könnte. Dann kannst du das eine Bild schon benutzen wärend im Hintergrund bereits am nächsten gerechnet wird. Du müsstest dann lediglich dafür sorgen, dass du wärend des Renderns des PBuffers diesen nicht swapst. Rein Theoretisch sollte das so sogar recht gut funktionieren müssen. Ist aber alles nur Theoretisch und müsstest du wohl mal ausprobieren.

Wenn es so funktioniert wir ich mir das denke solltest du mit recht wenigen Synchronierungen auskommen. Allerdings möchte ich nicht drauf wetten ob die Grafikkarte da auch ohne weiteres mitmacht. Das müsstest du evtl mal ausprobieren. Wenn es nicht funktioniert müsstest du es so machen wie es Flash vogeschlagen hat. Also an einem bestimmten Punkt deine Rendereien unterbrechen und dann die GUI updaten.

Ein andere Weg würde ähnlich wie der obrige arbeiten allerdings wäre der evtl ein bisschen sicherer. Du arbeitest wie oben nur das du anstelle des PBuffers zum Rendern in der GUI eine temporäre Textur erstellst in der du den PBuffer kopierst sobald er fertig ist. Das muss dann natürlich 100% synchron passieren und würde länger dauern. Wäre aber mit sicherheit einen ganzen Ticken sicherer und weniger kriminell.

Meine Komponenten sind so aufgebaut, dass du von einer Basisklasse etwas ableiten kannst und sobald die Klassen registriert sind kannst du diese auch verwenden. Also auch aus dem XML herraus. Habe ich mir von der VCL abgeschaut und funktioniert dort ja meistens auch ziemlich gut.

Sind auch "interaktivere" Elemente problemlos machbar ? also beispielspweise ein Panel mit zur Runtime hinzufügbaren unterelementen die frei verschoben werden können (vom Anwender)?

Gruß,
Thorsten

Der Aufbau ist sehr stark an der VCL angelehnt. Jede erstellte Komponente bekommt die Events, KeyUp, KeyDown, MouseDown, MouseMove, MouseUp. Was sie dann damit macht ist deren Sache. Gelle.

Also ich sehe darin jetzt kein Problem. Dynamisch kannst du natürlich Problemlos Instanzen erstellen und diese dort hinzufügen wo du möchtest und ich es erlaube. Freigeben ist dann latürnich auch kein Problem.

Das Einzige was derzeit noch nicht so wirklich gut gehen dürfte wären animierte Elemente. Also so, dass man eine kleine Animation sehen kann wenn auf einen Button drückt. Da bin ich mir selber gerade noch ein wenig unschlüssig. Aber da habe ich schon so die ein oder andere Idee. Wird aber wohl eh erst später werden.