Rechtecke gefüllt und ungefüllt (also transparent), Kreise gefüllt und ungefüllt (also transparent)
Also die Transparenzfrage bezog sich eher auf die Fonts. Dort wird erst mal der Hintergrundbereich des Zeichens mit der Hintergrundfarbe überpinselt. Verwendet man hier Transparenz, so bedeutet das einfach, daß eben genau diese Hintergrundpixel nicht beschrieben werden. Damit steigt nicht der Datendurchsatz sondern er sinkt weil nur die Vordergrundpixel, also das eigentliche Zeichen übertragen wird. Man kann dann zwar nicht die selbe Stelle mehrfach überschreiben, weil dann das alte Zeichen noch sichtbar ist. Man kann aber damit schicke Button machen, die eine strukturierte Oberfläche haben und zunächst als Bild gezeichnet werden. Dann kommt da die Beschriftung tansparent drauf.
Jetzt könnte man ja sagen, daß man sich einfach für jede Funktion einen eigenen Button mit entsprechender Beschriftung macht und diesen speichert. Das dürfte aber reine Speicherverschwendung sein.

Außerdem könnte man das Bitmap des Buttons gleich in ein entsprechend dimensioniertes Array packen und dann mehrere dieser Button sehr schnell auf dem Bildschirm positionieren. Einmal array füllen, window definieren, array in einem stück senden, nächtes window definieren und array wieder schrieben. Bisher wird bei jedem Button den man erzeugt die Bilddaten decodiert und gesendet. Will man das selbe nochmal tun, so muss wieder decodiert werden. Das kann nicht schnell gehen. Klar geht das bei Vollbildern nicht, weil da der SRAM zu klein ist, aber man zeichnet ja auch nicht mehrere Vollbilder kurz nacheinander.




Da finde ich eher die Bascom Routinen für das 1.5" Display Grundversorgung
Da stimme ich dir zu. Das war aber nicht das was ich meinte. Die Routinen von Display3000 sind recht ineffizient. Ein wenig mehr Assembler und effektives Datenmanagement hätte dem durchaus Beine gemacht. Hinzu kommt noch, daß Bascom ja eh schon langsamen Code erzeugt.

Ich lese überall nur von Problemen die die Leute mit dem Superkranz-Display und der Superkranz-Software haben. Wenn ich mir die völlig konfuse Dokumentation ansehe, wundert mich das auch nicht.
Naja es gibt sicher Probleme, aber Herr krantz verdient ja auch kein Geld mit seiner Software. Bei Display3000 zahle ich aber für ein fertiges Produkt und da möchte ich doch auch erwarten, daß die Software und Hardware gut dokumentiert ist.
Außerdem ist die Software von Display3000 auch nicht fehlerfrei wie ich inzwischen feststellen musste. Ich habe mal etwas herumgespielt und in irgendeinem Grafikmodus werden die die linken 8 Pixel des Bitmaps rechts ans Bild gehängt. Ich glaube es war der 4096 Farben Modus, bin mir aber jetzt nicht ganz sicher. Die Grafik wurde mit dem beiliegenden Grafikkonverter konvertiert. Ich muss mal prüfen, ob das am Grafikkonverter liegt oder ob irgendwo in den Routinen ein Index falsch läuft.

Ich habe zudem mal ein paar Performancetest gemacht und versucht die Software etwas zu optimieren. Da steht zum Beispiel in der LCD_CLS Rountine drin, daß dort immer 8 Byte am Stück übertragen werden, damit es schneller geht. Man könne die ZAhl der BYtes erhöhen um die geschwindigkeit zu erhöhen. Ruft man die Originalroutine 100 mal auf, so dauert das 19 Sekunden, also 0,19sek/CLS. Dann habe ich versucht die Arraygröße auf 128byte zu erhöhen, was die Zeit auf 16Sekunden verkürzte. Kein wirklich gravierender Geschwindigkeitsgewinn. Das kann aber auch an Bascom liefern, da Bascom hier vermutlich zwar prinzipiell HardwareSPI kann, abe rnicht hinterher kommt die Daten zu liefern. Das liegt wohl daran, daß Bascom die Variablen immer im SRAM hält und von dort auch lädt. So braucht das zuweisen eine Variablen 3 Takte während es bei Assembler mit Verwendung von registern in einem Takt geht. Zudem verwendet die Display3000 Software ziemlich viele LOCAL- variablen, was noch langsamer geht.

Meine ersten Versuche die kritischen Routinen in Assembler umzuarbeiten reduzierten die Zeit für 100x CLS auf 9 Sekunden.

Meine Absicht war es nicht das Display irgendwie schlecht zu machen, für einfache Aufgaben reicht es vollkommen, aber ich finde trotzdem, daß es durchaus bei der Software deutlichen Optimierungsbedarf gibt. Im Handbuch steht drin, daß extra nicht alles ausgeschöft wurde um die Software verständlich zu gestalten. Das mag sicher OK sein, für den, der diese gern selbst umschreiben will. Wer aber ein Display kauft um damit effektiv zu arbeiten, der will auch schnelle und effektive Software dafür haben. Man sollte sich auf die Programmierung der Anwendung konzentrieren können und nicht darauf, wie man die Grafikausgabe schneller bekommt.
Man stelle sich mal vor man kauft ein Auto und da ist als Motor eine Dampfmaschine drin: Argument des Verkäufers: die ist halt einfacher zu verstehen ist als ein moderner Einspritzmotor mit seiner ganzen Elektronik. Wenn Sie Power haben wollen,d ann abuen sie sich einen Motor oder Tunen ihre Dampfmaschine.

Wie wäre es wenn Display3000 zwei Versionen seiner Software beilegt. Eine für den, den es interessiert, wie es intern funktioniert und eine optimierte Bibliothek für den, der das Display einfach nur effektiv und S
schnell einsetzen will. Damit wäre jedem geholfen.