Ja, das meine ich. Z.B. das Hintergrundbild, die Icons und die Rahmengrafiken als Texturen im VRAM ablegen, so geht das dann nicht auf den Hauptspeicher. Ausserdem geht dann das Zeichnen der Oberfläche dank 3D-Beschleunigung recht flott, den Z-Buffer kannst du dann im Orthomodus nutzen um OpenGL die Fenster für dich sortieren zu lassen, Transparenz hast du dann ja auch über die Alphakomponente drin uvm.
Wäre sicherlich jede Menge Aufwand, aber evtl. könntest du das nebenbei als Plug-In entwickeln, so daß SharpDesk wahlweise normal oder mit OpenGL-Beschleunigung läuft.

_________________
www.SaschaWillems.de | GitHub | Twitter | GPU Datenbanken (Vulkan, GL, GLES)

Uh, ok - das ganze geht dann denke ich etwas zu weit und sprengt vorallendingen meine OpenGL Kentnisse.
Ist zwar ne gar nicht mal schlechte Idee. Aber dazu müßte ich dann alles komplett umprogrammieren.
Obwohls eigentlich mal einen test Wert wäre. Ich bräuchte ja eigentlich erstmal nur die ganzen TBitmap Layer, welche ja eigentlich einfache Bitmaps sind, einfach als Textur speichern.
Das könnte ich sogar vielleicht so hinbekommen das ich die kompletten Zeichen funtkionen der Plugins nicht einmal ändern müßte da die Bitmaps ja an die Hauptanwendung übergeben werden...

Nur wie schaut es dann mit der Performance aus?
Dami läuft doch dann praktisch permanent eine OpenGL Anwendung...

Du musst ja nicht, so wie man das normalerweise bei einem Spiel macht, permanent rendern (also z.B. im OnIdle das Done auf False) setzen. Du renderst dann halt, wie von Windows gewohnt, nur dann deine Szene neu wenn sich irgendwo was geändert hat (neues Fenster geöffnet, irgendwo gescrollt, Fenster verschoben, usw.).
War aber eher auch nur als Anregung gedacht, denn wäre sicherlich ne recht komplexe Sache. Dann müsstest du ja im Endeffekt auch alle anderen Anwendungen über OpenGL rendern, was sicherlich hier und da knifflig werden könnte. Aber vielleicht kannst du das ja mal in Zukunft zumindest antesten.

_________________
www.SaschaWillems.de | GitHub | Twitter | GPU Datenbanken (Vulkan, GL, GLES)

Also ich glaube zu OpenGL muss man nicht unbedingt sofort greifen. Es bietet natürlich jede Menge voretiel. Keine Frage. Und sofern es nur für den Desktop ist sollte es schon machbar sein. Aber die Texturenverwaltung dürfte momentan noch das größte Problem mit sein. Ich sage nur n^2 Texturen.

Aber mal was anderes. Ich habe gerade mal mit meiner Lieblingsklasse TBitmap etwas rumgespielt. Denn was die wenigsten wissen. Ein TBitmap ist normal nur im Arbeitsspeicher verfügbar. Aber normal gibt es schon.
Und das TBitmap ermöglicht es ohne Problem den Handletypen umzuschalten. Dadurch gelangt man zu einer wahren Wunderwelt der Geschwindigkeit!
Moderne Grafikkarten haben schon lange nicht mehr nur eine 3D Beschleunigung oder wie es bei OpenGL ist eine "pseudo" 2D Beschleunigung. (nicht missverstehen aber diese 2D kann man auch durch Abschalten der Perspektive erreichen. Darum gehts hier aber nicht). Was ich meine. Moderne Karten besitzen eine normale GDI Zeichenbeschleunigung. Also Bilder oder Linien. etc. Mit dem Tool Sandra kann man sich anzeigen lassen was seine Karte alles unterstützt.

Ich hatte im Rahmen eines Projektes für meine Firma damit schon einmal ausgiebig herum spielen dürfen. Und so lange man sich auf normale GDI beschränkt bekommt man mitunter (auf einer Radeon 9500 Pro) das 100fache an Geschwindigkeit herraus. Im Vergleich zu DIB Bitmap zeichen operationen. Diese sind nämlich nicht beschleunigt und laufen komplett im Arbeitsspeicher und Prozessor ab. Und die Beschlenigung ist teilweise auch schon auf einer TNT2 bemerkbar. Allerdings ist das kein Muss sondern nur ein kann.

Um meine These zu untermauern hier folgender Codeschnipsel.


Der Speicherverbrauch ist bei dieser Anwendung 4MB. Ich betätige den Knopf und sehe die erste Meldung (DDB). Der Speicherverbrauch bleibt fast unverändert! 20 KB unterschied. Was aber den Klassenspeicher darstellen müsste. Und wenn man dann OK drückt passiert es. Wo auch immer das Bild vorher war anschließend ist es im Hauptspeicher und die Anwendung verbraucht 50 MB.

Diese Sache hat natürlich einen gewaltigen Hacken. Keine Trasparenz oer sonstige Effekte. Sondern nur pure GDI. Und dadurch, dass das ein speziell Hardwareangepasstes Bild ist gibt es auch keine Scanlines. Dazu müsste sich das Bild im Hauptspeicher befinden. Das Mischen von DIB und DDB ist problemlos möglich. evtl müsste man ein DIB aus Geschwindigkeitsgründen erst noch als DDB "umwandel". Musst du aber mal selber ausprobieren.

Aber was ich da gesehen hatte sollte ohne große Probleme alles damit möglich sein. Von dem möglichen Geschwindigkeitsvorteil mal abgesehen. Ich meine wenn das nicht verfügbar ist dann wird es von Windows automatisch als DIB behandelt. Wodurch die ganze Sache Kompatibel bleiben sollte.

PS: Die Transparenz deine Hintergrundbildes müsstest du einmal (als DIB) berechnen und könntest es dann als DDB ablegen. bzw. erstellst ein Zweites und kopierst es darauf. Damit könntest du sicherstellen, dass das Bild nicht noch im Speicher hängt.

Das Problem ist das, soweit ich das jetzt gesehen habe, nur DIB von dem TBitmap32 der graphics32 komponente unterstütz wird. Das ist ja nicht nur ein TBitmap mit nem PixelFormat von 32bit. Das ist eine eigene Klasse wo ich bis jetzt keine Möglichkeit gefunden habe den HandleType umzustellen.

Bei TBitmap32 geht das auch nicht, da das nicht auf der API aufsetzt sondern etwas komplett eigenes, in einem eigenen Stück Speicher, ist. Aber dadurch, dass es recht gut gekappselt ist müsstest du hoffentlich nur wenig ändern. Wobei das natürlich ganz auf dein eigenes Gezeichnetes ankommt. Und wie du die Klassen verwendest.

Aber Mittels DDB hätte man teilweise den Vorteil, dass der Speicher sinnvoll aus dem Arbeitsspeicher kommt und auch noch etwas in Sachen Geschwindigkeit bringt. Das wollte ich euch ja nicht vorenthalten.

Vielleicht kann ich das ja beim laden des Hintergrundbildes einsetzen. Da hantiere ich ein wenig mit Bitmaps hin und her um halt die ganzen Effekte wie das Color Blending zu machen. Später sollen ja auch noch Farb verlauf Effekte wie bei KDE dazu kommen. Vielleicht kann ich so den gesammten Vorgang etwas beschleunigen.

Also hab mir das sharpE desk system auch angeschaut und finds echt gut, grafisch gesehen ist es echt nice.

nur was mich ziemlich stört ist der fehlende unicode support.
Hab einfach mal den "Arbeitsplatz"
durch dieses ersetzt:

きんむさき - ohne IME JP sieht man hier nur ?

und das wurde zu: ‚«‚ñ‚Þ‚³‚«

habe sogar ne unicode fähige schriftart gewählt "Arial Unicode MS".

Ansonsten gefällt mir das ganz gut.

Leider ist aber auch so, das fast alle shell ersatz systeme kein unicode unterstützen.
Blackbox z.b. unterstütz das auch nicht

Ich hab mich erhlichgesagt noch überhaupt nicht mit irgendwelchem Unicode Zeug beschäftigt.
Es kann aber durchaus sein das es nicht funktioniert weil ich keine einfache Canvas draw funktion zum zeichnen des Textes benutze. TBitmap32 hat eine integrierte Render Text funktion mit integriertem Antialising, uvm. Kann durchaus sein das diese kein Unicode unterstützt. Oder aber die Daten dafür gehen schon beim speichern in XML verloren.

Kannst du mal zusammenfassen was ich beachten muß wenn ich Unicode unterstützen will?

also wenn du auf canvas zeichnen willst, geht das relativ einfach.
Erstmal wichtig ist, das ALLE strings in widestrings unkonvertierst.
Weil normale strings unterstützen kein unicode

Das ist schonmal ein haufen arbeit sag ich dir, StringListen müssen dann auch als Widestringlisten gemacht werden usw.

Kämpfe momentan selbst mit dem problem, Xenorate 2.5 unicode sicher zu machen.

Werde für das skinsystem auch die Graphics32 units benutzen.

Das zeichnen ansich ist nicht schwer:



einfach mal die delphi hilfe fragen, oder nach unicode beispielen gesucht.
Ich hab hier nen beispiel hochgeladen was ich mal gefunden habe da wird das ganze recht gut gezeigt:

http://www.xenorate.com/files/unicode.zip

die app von dem hat den unicode standard 3.0 in seiner library intergiert.
Da ich statische lösungen hasse, habe ich eine Dynamische Lösung gebastelt, welche die aktuellen Unicode Standards parsed und in eine struktur packt mit der man arbeiten kann.
Ich lade die app demnächst mal hoch.

matane,
Final

Das klingt ja alles erstmal reichlich Kompliziert
bleibt für mich erstmal die Frage ob JvSimpleXML widestrings unterstützt

Also ob JvSimpleXML unterstütz ist ganz klar nein.
Delphi bietet aber routinen Strings in WideStrings zu konvertieren und umgekehrt.

Kämpfe selbst damit momentan.

Für den Fall, dass die Jv Komponenten das nicht unterstützen musst du das wohl oder übel per Hand machen. Und das IDOMDocument unterstützt Widestring. Finden kannst du das in den Units XMLDoc, XMLDom und XMLIntf.

Allerdings kann es sein, dass du in dem XML auch noch einmal angeben musst, dass dieses Unicode beinhält. utf-8 müsste das sein wenn ich mich nicht irre.

ich weiss zwar nicht gelesen, obs schon jemand gesagt hat (hab grad keine zeit, informatikunterricht), jedoch funktioniert das ganze nicht auf WinME. gibts da einschränkungen oder bugfixes oder so??? ich würds gerne mal probieren, klingt nämlich extrem interessant!!!

_________________
Aktuelles Projekt :
www.PicPlace.de

Absolut Problemlos läuft es aktuell nur mit WinXP.
Die Finale Version wird auch unter Win2k laufen, da gibts aber aktuell noch ein paar Probleme mit dem Startmenü.
Win9x/Me wird ab der SharpE Public Beta 5 offiziell nicht mehr unterstützt womit es für mich nur von Bedeutung ist das es unter Win2k/XP funktioniert.

Ich gehe mal davon aus das Graphics32 auch unter Win9x funtkioniert. Ein Grund warum SharpDesk nun nicht funktioniert liegt eventuell bei ein paar Shell befehlen die benutzt werden. Ich weiß nicht wie weit diese von Win9x unterstützt werden. Gibt es irgendeine genaue Fehlermeldung?