Hallo, Hier soll es nicht darum gehen, wie man ein grafik LCD/TFT anstsuert, sondern viel mehr darum, wie man Informationen abschickt und diese dann "verarbeitet" werden um grafisch zu entstehen. Ich habe zb. ein ILI9341 320x240 TFT Display und auch ein ST7920 128x64 LCD Display. Initialiesierung, nutzung von SPI etc. ist soweit erstmal verstanden. Mich interessiert grade viel mehr, und ich konnte bis jetzt auch nicht viel darüber finden, wie es den im Hintergrund abläuft. Also als Beispiel eine einfache Textausgabe (ganz davon abgesehn das einige Displays Text-Modi haben). Irgendwo muss ja eine art Schriftart vorliegen. und irgendwas muss ja bestimmen wo die schrift hinkommt. Wenn ich zb. "Hello" ausgeben möchte, muss ja erstmal etwas die Pixel für jeden Buchstaben setzen, dann muss der "cursor" ja auch weiter wandern. Oder wie das ganze funktionert, wenn ich zb. ein Diagramm darstellen will? Den Rahmen (oder zb. Raster beim Oszi) würde man ja noch recht leicht hinbekommen. Nur wie stellt man es an, dass die "geschriebene Linie" (also der strahl beim oszi) nicht das Raster kaputt macht? Also ich meine, wenn die Linie durch zufall mal auf einem Raster liegt, dann wird beim verändern der linie ja das alte Pixel wieder gelöscht. Dann muss ja irgendetwas überwachen, dass das Raster nicht versehentlich "weggeblendet" wird? Genauso frage ich mich, wie ich einen 2 Dimensionalen Puffer aufbauen soll. Brauche ja im grunde einen Platzhalter für jeden Pixel im grafen, und je nachdem ob dort ein Pixel gesetzt wird, ändert der Puffer dort halt seinen Status. Beim 128x64 Display sind ja nur zwei zustände, schwarz oder weiß, möglich, dadurch ergibt sich ja schon 2048 Byte, allein um das display zu Puffern. wenn noch Farbe dazukommt und mehr Pixel, reicht der Speicher ja gar nicht mehr. Mir würden bei dem ILI9341 ja schon 8 Farben reichen, das wären dann aber schon 76,8 Kbyte. Außerdem muss sich der Puffer ja ständig verschieben, sobald neue Daten reinkommen, also zb bei Verwendung als Datenlogger oder oszi. Wie bewerkstelligt man sowas? Oder sind meine Gedanken grade totaler schwachsinn? Würde gern mehr zu dem Thema erfahren. Habe ja nicht vor 3D sachen darzustellen :) Bin für alle Infos/Links dankbar! Mit freundlichen Grüßen Sascha
Sascha712 schrieb: > Mich interessiert grade viel mehr, und ich konnte bis jetzt auch nicht > viel darüber finden, Ich kenn jetzt nicht die neuere Literatur. Aber wenn dir eine etwas ältere Literatur auch genügt, dann würde ich dir zu einem Foley/Van Dam raten http://www.amazon.com/Computer-Graphics-Principles-Practice-Edition/dp/0201848406 Zu seiner Zeit war es eines der Standardwerke, die man haben musste, wenn man in Computer-Graphik einstieg. > wie es den im Hintergrund abläuft. Also als > Beispiel eine einfache Textausgabe (ganz davon abgesehn das einige > Displays Text-Modi haben). Irgendwo muss ja eine art Schriftart > vorliegen. Exakt. > und irgendwas muss ja bestimmen wo die schrift hinkommt. Wenn > ich zb. "Hello" ausgeben möchte, muss ja erstmal etwas die Pixel für > jeden Buchstaben setzen, dann muss der "cursor" ja auch weiter wandern. Bei einem reinen Grafikdisplay gibt es keinen Cursor in dem Sinne. Textausgabe bedeutet einfach nur, die richtigen Pixel an der richtigen Stelle in der richtigen Farbe einzuschalten. > Oder wie das ganze funktionert, wenn ich zb. ein Diagramm darstellen > will? Den Rahmen (oder zb. Raster beim Oszi) würde man ja noch recht > leicht hinbekommen. Nur wie stellt man es an, dass die "geschriebene > Linie" (also der strahl beim oszi) nicht das Raster kaputt macht? Also > ich meine, wenn die Linie durch zufall mal auf einem Raster liegt, dann > wird beim verändern der linie ja das alte Pixel wieder gelöscht. Soll vorkommen. > Dann > muss ja irgendetwas überwachen, dass das Raster nicht versehentlich > "weggeblendet" wird? Im einfachsten Fall beginnt die Ausgabe des nächsten Bildes damit, dass der Raster komplett neu gezeichnet wird. Wie überhaupt recht viel in der Computergrafik darauf beruht, dass man sich im Speicher das komplette Bild neu erzeugt (inkl. Raster und sonstigen Hilfslinien) und dann dieses neue Bild komplett ausgibt. Darauf aufbauend gibt es natürlich Möglichkeiten, wie man das beschleunigt, zb in dem man sich den Hintergrund (Raster + Beschriftungen) in einem Buffer bereits ausgabefertig vorhält, so dass man diese Pixel lediglich aus diesem Buffer auf die Anzeige transferiert und dann da die Linien für das nächste Bild drüber malt. > Genauso frage ich mich, wie ich einen 2 Dimensionalen Puffer aufbauen > soll. In den meisten Programmiersprachen nennt man das ein Array. > Brauche ja im grunde einen Platzhalter für jeden Pixel im grafen, > und je nachdem ob dort ein Pixel gesetzt wird, ändert der Puffer dort > halt seinen Status. Ja. > Beim 128x64 Display sind ja nur zwei zustände, > schwarz oder weiß, möglich, dadurch ergibt sich ja schon 2048 Byte, > allein um das display zu Puffern. 1K Schwarz oder Weiß sind ja nurt 2 zustände. Ist ein Bit 0, dann soll das entsprechende Pixel schwarz sein, ist es 1, dann soll es weiß sein. > wenn noch Farbe dazukommt und mehr > Pixel, reicht der Speicher ja gar nicht mehr. Tja. Pech gehabt. > Mir würden bei dem ILI9341 > ja schon 8 Farben reichen, das wären dann aber schon 76,8 Kbyte. 8 Farbe lassen sich in 3 Bit codieren, womit du dann 28.8k brauchst und nicht 76.8 k 28.8k werden nicht ganz reichen, weil 3 Bit pro Pixel in der Verarbeitung recht ekelig sind (aber machbar). Wahrscheinlicher ist es, dann eben 4 Bit pro Pixel herzunehmen und damit potentiell 16 Farben pro Pixel machen zu können. > Außerdem muss sich der Puffer ja ständig verschieben Was muss sich da verschieben? > sobald neue Daten > reinkommen, also zb bei Verwendung als Datenlogger oder oszi. Wie > bewerkstelligt man sowas? Indem man nur einen Ausgabepuffer hat, die darzustellenden Daten nicht als Bild vorrätig hält, sondern in Form der Datenwerte selber und dann eben dafür sorgt, das man zb 20 mal in der Sekunde ein komplett neues Bild aufbaut, das man dann anzeigt.
:
Bearbeitet durch User
Das ist das Problem mit den einfachen Display Controllern die über einen Datenbus angeschlossen werden und einfache Kommandos verarbeiten. Die Performance reicht nur für einfache Grafiken und Touchbuttons. Die Buchstaben muss man pixelweise setzen, das war schon richtig. Dabei kann man durch Nutzen der Controllerfeatures etwas optimieren: erst ein Window setzen und dann kann man alle Pixeldaten nacheinander schicken ohne jedesmal erst die Position zu setzen. Graphen kann man evtl. durch srcoll Funktionen des Controllers schneller machen, aber auch das ist limitiert weil dann der ganze Fensterbereich verschoben wird. Für ordentliche Performance braucht man dann µC mit integrierter Displayansteuerung und zusätzlichem RAM.
Na das ich das keine 25fps habe bzw brauche ist mir schon bewusst. Aber so 5 bilder pro sekunde sollten ja machbar sein? Gibt es, außer das eine Buch oben, kostenlose informationen über das thema?
Na ja. Wenn ich dich richtig verstanden habe, dann ist das was du willst, ja nicht so sehr das große algorithmische Problem. Alles steht und fällt mit dem Problem, die Bytes eines Bildes möglichst rasch vom µC zum Display schaufeln zu können, wenn das Display selber keine höherwertigen grafischen Operationen oder gar Double Buffering anbietet. Welche Methode dann eingesetzt wird, hängt auch nicht unwesentlich davon ab, wie komplex das darzustellende Bild eigentlich ist und wie aufwändig es ist, es jedes mal neu zu erzeugen. Es gibt dann auch noch die Möglichkeit, die Dinge nicht einfach blind übereinander zu malen, sondern beim Malen einer Linie den 'Untergrund' zu berücksichten. Zb. in dem man Pixel per XOR-Operation setzt. Eine zweimalige Ausgabe derselben Linie hinterlässt dann den Untergrund so wie er vor der ganzen Aktion war. Einfach mal ein bischen spielen. Das erste Zwischenziel bei einem Display, dessen Controller nichts anbietet, ist es sowieso erst mal einzelne Pixel gezielt setzen zu können. Vorher geht sowieso nichts.
:
Bearbeitet durch User
Das Datenblatt zum Display gibt einen Überblick über die Features und es gibt einige Bibliotheken zur Ansteuerung im Sourcecode, da sieht man auch was geht und wie aufwändig einige Funktionen sind. Die Geschwindigkeit hängt sehr stark an der Busanbindung und wie schnell der µC die Kommandos und Daten raushauen kann. Auf Youtube findest du eine Menge Beispielvideos wenn du zb nach dem Controller 'ILI9341' suchst.
Gesamtdarstellungen im Netz zu finden, wird vermutlich eher schwierig. Als unmöglich würde ich es aber auch nicht bezeichnen wollen. Das Problem mit dem Thema ist, dass die einzelnen Punkte - Du hast das ja schon recht einleuchtend gegliedert - im Grunde trivial sind. Abgesehen von dem Buch, dass Karl Heinz genannt hat, hatte eben sonst kaum jemand Grund eine weitere Gesamtdarstellung zu erstellen und die noch kostenlos in's Netz zu stellen. Die einzige, reale Möglichkeit, die mir spontan einfällt, ist, die offenen Vorlesungen/Skripte von Unis, dann vor allem amerikanische Unis, durchzusehen. (Die deutschen sind da etwas zugeknöpfter). Ansonsten nimm Deine Gliederung und versuche dafür Darstellungen zu finden. Wie Fonts aufgebaut sind, wie man Diagramme erstellt, wie man Linien und Kreise zeichnet, etc. wird man leicht finden. Hingegen ist die Frage wie man einen Punkt der schon gesetzt ist, nicht wieder löscht schon Programmierer-Einmal-Eins (Bitoperationen), über das sich selten jemand ausführlich Gedanken macht und das auch noch niederschreibt. Allgemein nützlich, wenn man mal über die Grundlagen hinaus ist, sind aber, denke ich, die "Algorithmen in C" von dem Robert Sedgewick. Da gibts eine online-Version von. Auch das mehrteilige Buch von dem N. Wirth ist interessant. (Gibts mit ein bisschen Suchen auch online, meine ich).
Ja, werds versuchen. Hab gestern auch erst meinen Raspberry Pi zum Logic analyzer umfunktioniert, mit piscope. Um direkt zu sehen, ob das SPI alles richtig macht, also um fehler direkt von anfang an zu finden. Werde also erstmal versuchen ein paar Pixel draufzuzaubern. Um kurz meine Überlegung zum Oszilogramm zu erläutern: Es kommen ja ständig werte vom ADC rein. Daher muss das oszilogramm ja stätig fortlaufend sein. Ich kann also nicht den ganzen Bildschirm um x Pixel nach links verschieben, da das oszilogramm ja nur in einem Fenster ist. Beispielweise 60x100 Pixel. dann muss ich ja alle Pixel in diesem bereich um eins nach Links schieben, damit der neue wert wieder platz hat. Dabei darf dann ja auch das Raster nicht verschoben werden^^ Gruß
Sascha712 schrieb: > ist. Beispielweise 60x100 Pixel. dann muss ich ja alle Pixel in diesem > bereich um eins nach Links schieben, damit der neue wert wieder platz > hat. Dabei darf dann ja auch das Raster nicht verschoben werden^^ Dann bearbeitest Du halt in Deinem internen Array/Matrix nur die Pixel, die sich ändern sollen: ..oooo ..oooo ..oooo ..oooo ..oooo ..oooo ..oooo ..oooo ..oooo ...... . = statisch o = ändert sich
Richtig Spaß macht Computergrafik ab OpenGL aufwärts. Zwar ist es gut, wenn man weiß, wie man jedes einzelne Pixel von Hand setzen kann. Aber zum Erstellen einer tauglichen Anwendung im Jahr 2014 ist das doch eher mühsam. Dafür sind höhere Abstraktionsebenen da: Dass man sie nutzt :-)
:
Bearbeitet durch User
Das macht man dann abwe nich mit nem 8 bit microcontroller :D
Kann ich den mit der literatur im zweitem post den wirklich was mit dem atmega anfangen?
Ich weiß ja nicht, wie gut du programmieren kannst. Wenn du da drinn fertige Lösungen suchst, dann wirst du nicht fündig. Im Buch werden die Grundlagen durchgezogen, allgemeine Algorithmen beschrieben, die Prinzipien erläutert und die dahinter liegende Mathe durchgezogen. Wenn du Fertiges suchst, das du nur noch abtippen brauchst, dann ist das eher nichts für dich. Wahrscheinlich ist es eher nichts für dich.
Ne, ich such ja was um ddn hintergrund zu verstehen Hab mir mal nen gebrauchtes bestellt.
> Hab mir mal nen gebrauchtes bestellt.
Nanu? Warum das?
Komisch, jetzt haben die Studenten schon mehr Geld als ich.
Oder ich bin geiziger. :-)
20 euro. Das bei amazon wäre mir auch zu teuer :D Ja, komme wohl nicht drumrum. :) Sicher gibts fertige liberis. Nur dannnist ja 80% meines codes von wem anders :) Und bestimmt lässt sich hier und da auch was optimieren. Bin zwar noch nicht so erfahren, aber ich lerns gern.
€ 0.- (abgesehen vom Strom) http://ebookbrowsee.net/computer-graphics-principles-and-practice-in-c-2nd-edition-pdf-d429193380
Naja, viele Wege führen nach ROM. Eine Sparvariante für kleine/langsame LCDs/uCs ist ein Oszi für Arme, das nicht echt scrollt sondern den virtuellen Schreibzeiger einfach von links nach rechts durchlaufen läst und dabei den alten Punkt dieser Spalte löscht und den neuen setzt. So wie man es aus dem Film von EKG Geräten kennt.
Sascha 712 schrieb: > Kann ich den mit der literatur im zweitem post den wirklich was mit dem > atmega anfangen? Wohl eher nicht. Weißt du, im Prinzip ist das Ganze doch recht einfach: Wenn man ein Display mit Controller hat und dennoch wenigstens so einigermaßen frei sein will mit der Anzeige, dann muß man sich im (hoffentlich vorhandenen RAM) einen Bildpuffer einrichten, den man nach getaner Zeichenarbeit komplettiko in das Display kopiert. Bei einfachen monochromen Displays kommt man da mit einem normalen Achtbitter zurecht, weil der RAM dafür ausreicht. Bei bunten TFT's hört das Ganze auf, weil man recht bald viel mehr RAM braucht, als der µC drin hat - und so ab 480x272 braucht es nen so großen RAM, daß damit die meisten Achtbitter überfordert sind, da ist dann ein 32 Bitter vonnöten. Ansonsten, was das eigentliche Zeichnen von diversen Dingen betrifft, brauchst du dafür eine nette Sammlung von Funktionen, denen man salopperweise Namen wie GDI usw. gegeben hat - da tummeln sich im wesentlichen Funktionen für: - Pixel setzen - Linien zeichnen - Kreise zeichnen - Flächen füllen - Text zeichnen - Bilder zeichnen und dazu gehören natürlich Fonts in einem Format, was das jeweilige GDI auch versteht. Guck mal hier in der Codesammlung nach der Lernbetty, dort findest du so ein GDI nebst einigen Fonts, obendrein ein Tool, um sich selber nen Font zu machen. Das Ganze ist zwar für nen 32 Bitter (hier ARM7) geschrieben, aber in simplem C ohne Besonderheiten. Sollte also auch für einen AVR fast ohne Änderungen benutzbar sein - wenn man mal von den Pointerbesonderheiten beim AVR (const oder nicht) absieht. Dieselbe Quelle läuft bei mir auch auf anderen µC mit anderer Endianess (Motorola und Fujitsu), sollte also universell genug sein.
Naja, andere habens ja auch geschafft fortlaufende Oszilografen hhinzubekommen :D Das Buch aus dem Link ist doch gar nicht das von Amazon. Naja, werde mich langsam dran wagen. Werde denke erstmal mit dem 128x64 Display arbeiten. Das ILI9341 scheint doch recht kompliziert zu sein. Und außerdem hab ich keinen Pegelwandler von 5 auf 3,3 Volt :) Und ob ich das einfach mit Spannungsteiler arbeiten soll? Weis nicht, klappt sowas den bei den frequenzen vom SPI?
>Das Buch aus dem Link ist doch gar nicht das von Amazon.
Na toll. Da hab' ich 'nen Bock geschossen. :-) Entschuldigung.
Allerdings solltest Du es trotzdem lesen. Das Thema stimmt.
Ja, W.S. da hast/haben du/sie schon recht. Ich geb mich am anfang ja erstmal mit Monochrom zufrieden. Hab ja auch kein bestimmtes ziel vor augen. Es geht erstmal ums verstehen und schauen was möglich ist. Dann kann ich mir auch was nützliches dazu ausdenken :) Momentan nutze ich ja nur HD44780 LCDs und die sind ja recht primitiv. Daher auch meine Überlegung was mit Grafikdisplays zu machen. Das ganze wird sich wie gesagt nur in 2D abspielen und wenn überhaupt nur in 16 Farben(falls ich irgendwann dazu komme das ILI9341 zu benutzen) Ich müsste also im Grunde auf dem uC erstmal nen Bildpuffer anlegen?
1 | int LCD[64] [128] = |
2 | {{0,0,0,0,0,0,0.........0,0,0,0} |
3 | {0,0,0,0,0,0,0.........0,0,0,0} |
4 | {0,0,0,0,0,0,0.........0,0,0,0} |
5 | {0,0,0,0,0,0,0.........0,0,0,0} |
6 | ....
|
7 | {0,0,0,0,0,0,0.........0,0,0,0} |
8 | {0,0,0,0,0,0,0.........0,0,0,0}} |
Je nachdem ob ein Pixel gesetzt wird oder nicht, setze ich eine 0 oder eine 1 in die jeweilige Array Position. Sollte man eig. einen anderen Datentyp nehmen? int reserviert doch mehr Speicher als nur 1 Bit? Oder wie läuft das ganze ab? Weil rechnerisch brauch ich ja nur 1 Kbyte für das monochrome 128x64 Display. Als nächstes würde ich ja mit entsprechenden Funktionen etc. in diese Array das Bild aufbauen. und dann würde ich jeden einzelnen Pixel ans LCD senden, indem ich ihm erst die Adresse mitteile und dann ob der Pixel gesetzt wird oder nicht? Dauert das nicht "vergleichsweise" ewig? Weis ja nicht wie der Datendurchsatz von SPI so ist, hab ich auch noch nichts mit gemacht :) bzw. bin ich dabei.
:
Bearbeitet durch User
Könnt ihr mir nen 32 bit fähigen uC empfehlen, der sich ähnlich programmieren lässt wie ein avr? Kenn mich außerhalb der 8bit welt eher schlecht damit aus. Evtl auf nem entwicklungsboard, weil das wird es wohl nicht als DIP geben :)
Pauschal, d.h. ohne ein konkretes Display lässt sich über die notwendige resp. angemessene Speicherorganisation nichts sagen. Suche Dir einfach mal einige Displays raus und schaue Dir die Datenblätter dazu an. Aber soweit ist es richtig, das ein Integer in der Regel mehr als ein Bit umfasst. Ob Du nun aber ein Integer, ein Byte oder was auch immer nimmst hängt vom konkreten Display ab. Bei monochromen Displays wird in der Regel ein Byte mehrere Pixel kodieren. Ob aber nun ein Byte vertikal oder horizontal angeordneten Pixel entspricht, ist nirgendwo festgelegt - allerdings ist die waagerechte Anordnung, soweit ich weiß, üblicher. D.h. bei einem 64 * 128 Pixel Display könntest Du etwa uint8 BildSpeicher[8][16]; oder uint16 Bildspeicher[4][8]; schreiben. oder sogar, uint32 Bildspeicher[2][4]; Was am effezientesten ist, hängt von der Wortbreite des Prozessors ab. Die erste Adresse enthielte dann, wenn der Koordinatenursprung (0,0) oben, links liegt (was auch nicht grundsätzlich so sein muß) +-----+-----+-----+-----+-----+-----+------+-----+------+ | 0,0 | 0,1 | 0,2 | ... | 0,7 | ... | 0,15 | ... | 0,31 | +-----+-----+-----+-----+-----+-----+------+-----+------+ ------------------------------------- Die Bewegung vom 8-Bit AVR weg zu einem 32Bit Prozessor ist allein schon eine große Umstellung. Wenn Du in C programmierst, dann ist zwar einfach ein 32Bit-Typ der "natürliche" aber es gilt immer noch, das Du in C den den Daten angemessenen Typ benutzt. Nach den 32Bit richtest Du Dich genau dann, wenn Geschwindigkeit und Effizienz bei einer bestimmten Aufgabe wichtige Faktoren sind. Aber warum sollte man 32 Bit bei ASCII-Strings benutzen? Das geht weiterhin gut mit 8Bit. Die größte Umstellung wird Dich bei der Programmierung der Peripherie treffen. Die 32Bitter haben in der Regel wesentlich komplexer zu programmierende Peripherie. Obwohl am Ende eigentlich dem Wesen nach gleich, gibt es doch mehr Betriebsmodi von Timern und UART etc. Dann gibt es oft noch DMA und die Interrupts lassen sich, anders als beim AVR häufig noch konfigurieren, was Du vom AVR nicht kennst. Ich schlage Dir als Anfang die STM32-Prozessoren vor. Da gibt sehr günstige Boards. ------------------------------- Aber wiegesagt, schaue Dir erstmal die Datenblätter einer Reihe von Displays an.
Sascha712 schrieb: > Ich müsste also im Grunde auf dem uC erstmal nen Bildpuffer anlegen? > int LCD[64] [128] = > {{0,0,0,0,0,0,0.........0,0,0,0} ... Nein. So schonmal nicht. Du willst ja 128x64 Bits, nicht 128x64 int mit je 16 Bits. Du wirst also wohl oder übel einzelne Bits in einem entsprechend breiteren Datentyp verwenden müssen. Also z.B. uint8_t und dann nur 1024 davon. Ob du das nun als eindimensionales Feld oder zweidimensional machst, ist Geschmackssache. Die viel wichtigere Entscheidung ist, wie du die einzelnen Bits in deinem Array zu den Pixeln des Bildschirms zuordnest. Verschiedene Grafikchips verwenden da durchaus verschiedene Methoden. Zwar organisieren die meisten ihren Grafikspeicher in Bytes, aber bei manchen sind die 8 Bits in einem Byte horizontal angeordnet, bei anderen vertikal. Mal ist das kleinste Bit links, mal das größte. Man kann, muß aber nicht, diese Organisation für seinen Display-Buffer übernehmen. Für eine eigene Organisation sprechen: * man kann Besonderheiten des Controllers wegabstrahieren, etwa daß ein 128x64 LCD mit KS0108 in Wirklichkeit aus zwei unabhängigen 64x64 LCD besteht. * man kann die Grafikroutinen für verschiedene LCD-Controller gleich lassen und muß nur die eine Funktion, die den Grafik-Buffer auf das LCD schiebt, an den Controller anpassen. Dagegen spricht vor allem, daß die letztgenannte Funktion schnell sein muß. Deswegen wird man da kaum komplexe Transformationen wie das Spiegeln eines Bytes o.ä. drin machen wollen. > Als nächstes würde ich ja mit entsprechenden Funktionen etc. in diese > Array das Bild aufbauen. und dann würde ich jeden einzelnen Pixel ans > LCD senden, indem ich ihm erst die Adresse mitteile und dann ob der > Pixel gesetzt wird oder nicht? Nicht wirklich pixelweise. Sondern in der Breite, die das LCD entgegen nimmt. In der Regel sind das Bytes, also immer 8 Bit auf einmal. > Dauert das nicht "vergleichsweise" ewig? Typische LCD-Controller wie der KS0108 brauchen ca. 10µs für ein Byte. Die 1024 Byte für ein 128x64 Display sind also in 10ms kopiert. Wenn man die beiden Teildisplays verschachtelt anspricht, reichen sogar 5ms. Also 100 bzw. 200 Auffrischungen pro Sekunde. Schnell genug. XL
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.