|
ENGLISH VERSION |
|
 |
| Links | | | Forum | | | Kommentare | | | News melden |
|
| Chat | | | Umfragen | | | Newsticker | | | Archiv |
|
| amiga-news.de Forum > Programmierung > UAE zu langsam oder Programmierfehler? | [ - Suche - Neue Beiträge - Registrieren - Login - ] |
| -1- 2 | [ - Beitrag schreiben - ] |
|
26.07.2011, 20:56 Uhr AGSzabo Posts: 1663 Nutzer |
Hallo, ich frage mich gerade, wie große der Unterschied zwischen der nativen rechenleistung und der emulierten ist. während sich nativ komplizierte webseiten schneller als der blitz aufbauen, braucht meine neu listview schon ab ca 200 einträgen zu 5 spalten spürbar lange. ich habe die listview in 68k assembler programmiert und alles an ihr ist ein eigenes objekt: die view selber als geclippte area, die scroller, der titel, der hintergrund einer listenreihe und die texte in der listenreihe. nun scheint mein system an seine grenzen gestoßen zu sein und ich frage mich, wie ich es schneller machen kann, falls das in der emualtion irgendwie möglich sein sollte. ich vermute, der flaschenhals liegt nicht im zeichnen, weil ich da eben clippe und garnicht erst zu zeichnen anfange was außerhalb des clips liegt, sondern er liegt evtl beim layouten! wenn ich die view scrolle, müssen alle x und y coordinaten der childs angepasst werden. dazu mache ich das ganze setlayout für den inhalt der view nochmal, also auch höhen und breiten. was meint ihr? @Der_Wanderer: ist dein NTUI schnell genug? -- Sam mini os4.1 upd. 2 / e-uae 39bb2 / A4000D 3.0 & 3.9 2mbchip 8mbfast Ariadne_II ide DVD und HD / A500 3.1 (mkick) adide 50mb / Athlon ii X2 Ubuntu Linux [ - Antworten - Zitieren - Direktlink - ] |
|
26.07.2011, 21:13 Uhr Der_Wanderer Posts: 1229 Nutzer |
NTUI ist schnell genug, zumindest wesentlich schneller als MUI's NList. Kannst du denn die 200 Einträge alle sehen? Die Geschwindigkeit sollte sich eigentlich nur nach den sichtbaren Einträgen richten, egal obs nun 10 oder 10,000 Einträge sind. Ein bisschen aufpassen muss man bei ListViews schon, 68K Assmelber schützt vor ineffizientem Code nicht ;-) -- -- Author of HD-Rec, Sweeper, Samplemanager, ArTKanoid, Monkeyscript, Toadies, AsteroidsTR, TuiTED, PosTED, TKPlayer, AudioConverter, ScreenCam, PerlinFX, MapEdit, AB3 Includes und viele mehr... Homepage: http://www.hd-rec.de [ - Antworten - Zitieren - Direktlink - ] |
|
26.07.2011, 21:22 Uhr AGSzabo Posts: 1663 Nutzer |
@Der_Wanderer: Ich sehe 10 oder 20 zeilen. so schaut es aus: Bild: http://images.quicktunnels.net/oxlibinfo.jpg -- Sam mini os4.1 upd. 2 / e-uae 39bb2 / A4000D 3.0 & 3.9 2mbchip 8mbfast Ariadne_II ide DVD und HD / A500 3.1 (mkick) adide 50mb / Athlon ii X2 Ubuntu Linux [ - Antworten - Zitieren - Direktlink - ] |
|
27.07.2011, 09:15 Uhr Der_Wanderer Posts: 1229 Nutzer |
Ich weis nicht wie du es implementiert hast. Viel kann ich also nicht dazu sagen. Evtl. schickst du mir mal die Exectuable, dann kann ich es unter meinem WinUAE laufen lassen. Was ist denn langsam? Das Zeichnen oder das Befüllen des Listview? -- -- Author of HD-Rec, Sweeper, Samplemanager, ArTKanoid, Monkeyscript, Toadies, AsteroidsTR, TuiTED, PosTED, TKPlayer, AudioConverter, ScreenCam, PerlinFX, MapEdit, AB3 Includes und viele mehr... Homepage: http://www.hd-rec.de [ - Antworten - Zitieren - Direktlink - ] |
|
27.07.2011, 09:22 Uhr AGSzabo Posts: 1663 Nutzer |
@Der_Wanderer: Das executable sende ich dir nachdem ich einige Änderungen bezüglich der vereinfachung der komplexität vorgenommen habe. Ich weis noch nicht wo der flaschenhals liegt, es dauert wohl alles etwas länger bei vielen zeilen. ich erhoffe mir das es nach der vereinfachung schneller löppt. zeichnen sollte schnell gehen, weil ich alles gleich ausmustere was nicht im cliprect liegt. befüllen passiert, ausser bei einer directory lost nur einmal, das sollte auch schnell gehen. bleibt noch das layouten. genau da soll meine vereinfachung greifen. die ist, daß ich statt extra objekten für jeden text und änliches diese zu spezielle listengruppe und listenzeile zusammenbaue. als schmankerl erlaubt diese zusammennahme auch folders... -- Sam mini os4.1 upd. 2 / e-uae 39bb2 / A4000D 3.0 & 3.9 2mbchip 8mbfast Ariadne_II ide DVD und HD / A500 3.1 (mkick) adide 50mb / Athlon ii X2 Ubuntu Linux [ Dieser Beitrag wurde von AGSzabo am 27.07.2011 um 09:24 Uhr geändert. ] [ Dieser Beitrag wurde von AGSzabo am 27.07.2011 um 09:25 Uhr geändert. ] [ - Antworten - Zitieren - Direktlink - ] |
|
27.07.2011, 10:43 Uhr Holger Posts: 8116 Nutzer |
Zitat:Das ist zwar ineffizient, dürfte aber kaum zum Problem werden. Zitat:Das ist schon ein anderes Kaliber. Gibt es denn irgendeinen sinnvollen Grund, warum Du das Layout neuberechnest, obwohl definitiv kein Objekt seine Größe geändert hat? Zitat:Viel mehr noch, es verführt zu ineffizientem Code. -- Good coders do not comment. What was hard to write should be hard to read too. [ - Antworten - Zitieren - Direktlink - ] |
|
27.07.2011, 10:54 Uhr Der_Wanderer Posts: 1229 Nutzer |
Bei NTUI ändert sich beim Scrollen nichts, ausser dem Offset (1 Integerwert). Der Rest ist immer gleich, also das Zeichnen des Listviews. Ich glaube du hast folgendes Problem: 1. Um das erste zu zeichnende Element zu finden, suchst du von 0 an. Das ist nur notwendig, wenn die Einträge unterschiedliche Höhe haben können. Bei meinem "normalen" Listview ist das nicht so, deshalb kann ich den Index des obersten Elements direkt berechnen, ohne durch die Liste zu iterieren. Bei Listen mit sehr vielen Einträgen wird sich das bemerkbar machen, >>100.000 Einträge. Bei 200 allerdings noch nicht. Lösung: a) alle Elemente gleich hoch. b) falls die unterschiedlich sein sollen, dann kannst du beim Scroller trotzdem annehmen, sie wären gleich hoch, allerdings änderst du die Visible Größe, je nachdem wie hoch die sichtbaren Elemente dann tatsächlich sind (nur die hand-voll sichtbaren!). Ein Nebeneffekt ist, dass der Knob des Scrollers leicht in der Größe Variiert, wenn man durch die Liste scrollt. Wenn man damit leben kann, ist das sehr viel effizienter. Android macht das so. 2. Zitat:Das dürfte die Zeit kosten. Lösung: Der Inhalt muss relativ zum ListView layouted werden, und beim Zeichen wird immer der Offset des ListView-Inhalts addiert. Hat dann zwar leichte Mehrkosten beim Zeichen, aber keinerlei Kosten für das Scrollen. Merke: Was nicht nichtbar ist, muss auch nicht Layouted werden. -- -- Author of HD-Rec, Sweeper, Samplemanager, ArTKanoid, Monkeyscript, Toadies, AsteroidsTR, TuiTED, PosTED, TKPlayer, AudioConverter, ScreenCam, PerlinFX, MapEdit, AB3 Includes und viele mehr... Homepage: http://www.hd-rec.de [ Dieser Beitrag wurde von Der_Wanderer am 27.07.2011 um 10:55 Uhr geändert. ] [ - Antworten - Zitieren - Direktlink - ] |
|
27.07.2011, 10:57 Uhr Der_Wanderer Posts: 1229 Nutzer |
Zitat:Noch schlimmer, es verhindert möglicherweise die Implementation eines effizienten Algorithmus, weil es zu kompliziert ist, und statt dessen wird der naive Algorithmus (meistens "Brute-Force") gewählt.Zitat:Viel mehr noch, es verführt zu ineffizientem Code. -- -- Author of HD-Rec, Sweeper, Samplemanager, ArTKanoid, Monkeyscript, Toadies, AsteroidsTR, TuiTED, PosTED, TKPlayer, AudioConverter, ScreenCam, PerlinFX, MapEdit, AB3 Includes und viele mehr... Homepage: http://www.hd-rec.de [ - Antworten - Zitieren - Direktlink - ] |
|
27.07.2011, 11:11 Uhr AGSzabo Posts: 1663 Nutzer |
@Holger: > Gibt es denn irgendeinen sinnvollen Grund, warum Du das Layout neuberechnest, obwohl definitiv kein Objekt seine Größe geändert hat? Optimierungsklausel? Ganz allgemeine Lösungen zu verwenden machte bisher das coden leicht. Aber dank eurer Tips kann ich jetzt den code diese Sonderfälle berücksichtigen lassen, ich finde bestimmt eine Lösung. -- Sam mini os4.1 upd. 2 / e-uae 39bb2 / A4000D 3.0 & 3.9 2mbchip 8mbfast Ariadne_II ide DVD und HD / A500 3.1 (mkick) adide 50mb / Athlon ii X2 Ubuntu Linux [ - Antworten - Zitieren - Direktlink - ] |
|
27.07.2011, 11:36 Uhr Holger Posts: 8116 Nutzer |
Zitat:So sollte es sein. Zitat:http://de.wikipedia.org/wiki/Interpolationssuche Richtig auf das konkrete Problem zugeschnitten implementiert, wirst Du keinerlei Performance-Unterschied zu Elementen fester Größe feststellen. Ein Scroller, der seine Knob-Größe während des scrollens verändert, ist für mich ein Armutszeugnis. Egal, welche große Firma das so macht… Zitat:Man sollte generell die Koordinaten der Kinder relativ zum Elternelement halten. Die Mehrkosten sind praktisch nicht existent: alle Zeichenoperationen eines Gadgets sind eh in der Anwendung relativ zu ihrer eigenen Position implementiert, die wiederum vom OS relativ zum Fenster ausgeführt wird. Die Relation zwischen Kind und Elternelement wird dagegen vor dem Beginn des Zeichnen vorberechnet und hat auf die Zeichenoperationen gar keinen Einfluss. -- Good coders do not comment. What was hard to write should be hard to read too. [ - Antworten - Zitieren - Direktlink - ] |
|
27.07.2011, 11:43 Uhr Holger Posts: 8116 Nutzer |
Zitat:Genau das meinte ich mit: „es verführt zu ineffizientem Code“. Der wird einerseits geschrieben, weil der effiziente mit Assembler schwieriger zu machen ist oder nicht mit der damit verbundenen Denkweise zusammenpasst, andererseits ist ein ineffizienter Assemblercode oftmals bis zu einem gewissen Grad trotzdem noch schnell genug, um dann gerne in Situationen, die der Programmierer nicht getestet hat, einzubrechen. Zitat:Mir scheint, Du verwechselst gerade das Allgemeine mit dem Besonderen. Der allgemeine Fall lautet: Größe hat sich geändert ⇒ Layout muss neuberechnet werden. Das Besondere ist Deine Implementierung, die etwas tut, ohne dass es einen Grund dafür gibt. Defragmentiert Dein Programm auch beim Start die Festplatte? Oder ist es da doch naheliegend, Dinge nur dann zu tun, wenn es auch einen Grund dafür gibt? -- Good coders do not comment. What was hard to write should be hard to read too. [ - Antworten - Zitieren - Direktlink - ] |
|
29.07.2011, 09:41 Uhr AGSzabo Posts: 1663 Nutzer |
Ok, nun habe ich es so gemacht, daß nur diejenigen Listviewzeilen gezeichnet werden, die innerhalb des clips liegen. Jetzt rennt es! Allerdings scheint es ab einer gewissen Zahl von Zeilen einen grafischen Überlauf zu geben, ich meine die Koordinaten werden wieder negativ oder positiv oder so. Was kann da Abhilfe schaffen? ps: es könnte evtl auch der scroller sein, der bei zu großen zahlen nicht mehr richtig funktioniert? -- Sam mini os4.1 upd. 2 / e-uae 39bb2 / A4000D 3.0 & 3.9 2mbchip 8mbfast Ariadne_II ide DVD und HD / A500 3.1 (mkick) adide 50mb / Athlon ii X2 Ubuntu Linux [ Dieser Beitrag wurde von AGSzabo am 29.07.2011 um 11:13 Uhr geändert. ] [ - Antworten - Zitieren - Direktlink - ] |
|
29.07.2011, 11:54 Uhr Holger Posts: 8116 Nutzer |
Zitat:Das musst Du doch wissen. Also selbst mit Deinem Gewürge mit 0xffff als Maximum, sprich 16Bit-Arithmetik wären bei 16 Pixel hohen Zeilen 4096 Elemente ohne Probleme möglich, bzw. bei 20 Pixel pro Element immer noch deutlich über 3000. Wenn Du bei weniger Elementen Probleme hast, hast Du irgendwo Mist gebaut. Wenn Dir dagegen diese maximale Anzahl Elemente nicht reicht, musst Du ordentliche 32 Bit-Arithmetik verwenden (bzw. deren Bugs beheben, falls Du schon in 32 Bit gerechnet hast). -- Good coders do not comment. What was hard to write should be hard to read too. [ - Antworten - Zitieren - Direktlink - ] |
|
29.07.2011, 12:07 Uhr AGSzabo Posts: 1663 Nutzer |
@Holger: > bei 20 Pixel pro Element immer noch deutlich über 3000. Sie sind jetzt mal 19 pixel hoch. Das mal 3000 sind $dea8. Das liegt mit vorzeichen (bei grafikoperationen wichtig) außerhalb der $7fff, funktioniert also nicht. Oder was hast du gemeint? -- Sam mini os4.1 upd. 2 / e-uae 39bb2 / A4000D 3.0 & 3.9 2mbchip 8mbfast Ariadne_II ide DVD und HD / A500 3.1 (mkick) adide 50mb / Athlon ii X2 Ubuntu Linux [ Dieser Beitrag wurde von AGSzabo am 29.07.2011 um 12:31 Uhr geändert. ] [ - Antworten - Zitieren - Direktlink - ] |
|
29.07.2011, 15:03 Uhr Holger Posts: 8116 Nutzer |
Zitat:Dein Scroller hat laut Deiner Aussage einen Range von 0-0xffff, also ohne Vorzeichen. Dass Du auch für Deine Gadget Koordinaten 16Bit-Zahlen benutzt, wusste ich nicht. Jetzt wird es für Dich wirklich mal Zeit, über Deine Konzepte nachzudenken. -- Good coders do not comment. What was hard to write should be hard to read too. [ - Antworten - Zitieren - Direktlink - ] |
|
29.07.2011, 15:27 Uhr AGSzabo Posts: 1663 Nutzer |
@Holger: der scroller arbeitet inzwischen mit den nativen pixelgrößen der view und des inhalts. kein ffff. allerdings sind die mulus und divus auf wort. alleinstehende objekte sind jetzt bloch noch - die listview die das zusammenspiel ihrer objekte verwaltet - das raster das die view und die scroller positioniert - die scroller - die rahmen um die view - die view selber (zwei verschachtelte views, damit die titelzeile nur beim vertkalen scrollen an ihrem platz bleibt, horizontal aber mitscrollt) - die titelzeile der liste mit variablen spaltenbreiten - die gruppe die die zeilen der liste enthällt - jede zeile der liste Der Vorteil ist: "write less, do more". Man kann aber überlegen, ob man die zeilen und die zeilengruppe als private klassen der listview anlegt, dann hätten alle drei gegenseitig zugriff auf ihre strukturen. da es aber jetzt schnell genug ist, warum sollte ich es noch ändern... -- Sam mini os4.1 upd. 2 / e-uae 39bb2 / A4000D 3.0 & 3.9 2mbchip 8mbfast Ariadne_II ide DVD und HD / A500 3.1 (mkick) adide 50mb / Athlon ii X2 Ubuntu Linux [ Dieser Beitrag wurde von AGSzabo am 29.07.2011 um 15:41 Uhr geändert. ] [ Dieser Beitrag wurde von AGSzabo am 29.07.2011 um 15:42 Uhr geändert. ] [ - Antworten - Zitieren - Direktlink - ] |
|
29.07.2011, 18:54 Uhr Der_Wanderer Posts: 1229 Nutzer |
Warum hast du das auf so viele Objekte unterteilt? Wenn die Zeilen einer Liste wiederum Objekte sind, warum dann überhaupt einen ListView machen, es wäre viel flexibler eine scrollende Gruppe zu machen. Bei NTUI gibt es einen "ScrollView", dessen Inhalt ein beliebiges Objekt ist, z.B. eine VGroup. Damit kann man ListViews machen, die sehr speziell sind, z.B. durch eine Settings Page scrollen (mit jeder Menge verschiedenen Einstellungen,Grafiken, Checkmarks, Slidern, TextBoxen etc.) Das ist aber nicht so effizient wenn man eine VGruppe mit 10.000 Zeilen als TextView einfügen würde. Bei solchen langen Listen benötigt man aber meistens selten so spezifische Kontrolle über die einzelnen Einträge. bzw. alle sehen gleich aus. Deshalb gibt es noch einen dedizierten ListView, der ein paar Einschränkungen hat bezüglich der Listen Elemente, dafür aber auch mit 1.000.000 Einträgen noch lange nicht ins schwitzen kommt. Idealerweise würde man einen ListView mit hilfe eines sog. ListView Adapters implemnentieren (so macht es Android), das hat den Vorteil dass die Listen Elemente wieder komplett individuell sein können, das gnaze aber trotzdem extrem effizient ist, da nur die Listen Elemente angelegt werden die man gerade sieht, d.h. man befüllt den ListView nicht vorweg, sondern der ListView stellt über den Adapter anfragen wie das x-te Element aussehen soll und er zeugt es, wenn es sichtbar wird. Das ist allerdings ein typischen Java Kontrukt, mit dem eher unerfahrene Programmierer überhaupt nicht klar kommen. Auch stelle ich mir das in Assembler relativ schwierig vor, vor allem bei deinem Ansatz, da du die GUI Definition recht statisch hast, oder? -- -- Author of HD-Rec, Sweeper, Samplemanager, ArTKanoid, Monkeyscript, Toadies, AsteroidsTR, TuiTED, PosTED, TKPlayer, AudioConverter, ScreenCam, PerlinFX, MapEdit, AB3 Includes und viele mehr... Homepage: http://www.hd-rec.de [ Dieser Beitrag wurde von Der_Wanderer am 29.07.2011 um 18:57 Uhr geändert. ] [ - Antworten - Zitieren - Direktlink - ] |
|
29.07.2011, 19:03 Uhr AGSzabo Posts: 1663 Nutzer |
@Der_Wanderer: Es IST eine scrollende Gruppe, habe mich wohl falsch ausgedrückt. Mit "view" (kann beliebige objekte enthalten) meinte ich das was du mit scrollview meintest. Blos habe ich es nicht scrollview genannt, weil die view-fähigkeit bei mir als extra klasse implementiert ist, ohne scroller. die version mit scrollen heisst dann scrollview, welche die view und die scroller benutzt. aus diversen gründen benutzt die list-view nicht die scrollview sondern baut sich selber aus den oben gelisteten objekten zusammen. die listview ist eine variante der scrollview, zuzüglich titelzeile und der fähigeit zb eine 'hinzufügen' methode in eine neue zeile umzuwandeln. die listview kann dynamisch neue zeilen zur laufzeit aufnehmen. was sollte denn _nicht_ statisch sein so wie bei android? -- Sam mini os4.1 upd. 2 / e-uae 39bb2 / A4000D 3.0 & 3.9 2mbchip 8mbfast Ariadne_II ide DVD und HD / A500 3.1 (mkick) adide 50mb / Athlon ii X2 Ubuntu Linux [ - Antworten - Zitieren - Direktlink - ] |
|
01.08.2011, 18:24 Uhr Holger Posts: 8116 Nutzer |
Zitat:Die beschriebene Technik zielt auf folgendes ab: Statt von vornherein 3000 Objekte für 3000 Listenelemente zu haben, hast Du evtl. nur ein großen Plain-Text Objekt, von dem Du aber schon weißt, dass es 3000 Zeilen besitzt. Der List-View würde so implementiert sein, dass er ausschließlich für sichtbare Elemente ein Objekt anlegt. Diese Objekte würden dann on-the-fly auf dem Plain-Text generiert werden. Um daraus einen Nutzen zu ziehen, muss der Code aber einige Anforderungen erfüllen. So darf z.B. niemand auf die Idee kommen, durch die Liste zu gehen und für sämtliche Elemente das Layout berechnen zu wollen. Diese spezielle Implementierung muss davon ausgehen, dass alle Elemente dieselbe Höhe haben und eine bestimmte Breite erzwungen wird. Das entbindet Dich dann aber auch nicht davon, Pixelpositionen in 32 Bit zu berechnen. -- Good coders do not comment. What was hard to write should be hard to read too. [ - Antworten - Zitieren - Direktlink - ] |
|
01.08.2011, 21:59 Uhr Der_Wanderer Posts: 1229 Nutzer |
Zitat:Nein, muss es nicht. Es kann dann nur sein, dass sich eben der Scoller Knob in der Größe leicht verändert beim Scrollen. So ist es bei Android. Der Scroller muss nur wissen, wieviele Elemente es sind. Er braucht aber keinerlei Kenntnis über die Größe oder Inhalt der Elemente. Die werden eben erst erstellt, wenn die anfangen hineinzuscrollen. Für die Datenanbindung gibt es dafür ein "Adapter" Objekt, welches vom ListView angefragt wird, ein Listen-Element zu bauen. Der Adapter ist also eine Callback Hook und kennt die Daten quelle (z.B. Array, Datenbank, File auf Platte etc.) und muss ein GUI Object zurückgeben, was dann in der Liste dargestellt wird. Das ist eigentlich ein Super Konzept, da die Liste weder lange beim Initialisieren noch beim Scrollen braucht, und der Speicheroverhead ist auch minimal, eben nur das was man sieht. Nur ist das ganze etwas komplizierter und wenn man "mal eben" eine simple Liste braucht kommt es einem überkompliziert vor. Man braucht keine Angst zu haben, dass jemand über irgendwelche Objekte iterieren will. Denn wenn das GUI Toolkit richtig implementiert ist, dann darf ja nur der ListView die Unterelemente anfassen, und der weis ja was er tun muss. Das ist ja nicht mehr so wie bei einem naiven ListView, der gleichzeitig Anzeige und Datenbank ist, wo der Progger gerne mal drüberhuscht und irgendwelche Werte setzt. Das macht der Progger auf seiner Datenbank, der ListView selbst enthält keine Kopie der Daten. Bei NTUI habe ich das Konzept leider (noch) nicht umgesetzt. Z.b ist es schon erwas nervig bei einem Filemanager, der Echt-Icons anzeigt. Wenn man einen Folder öffnet mit 10.000 Files, dann dauert das schon mal ne Weile bis was angezeigt wird. Würde man so einen Adapter nutzen, müssten nur die sichtbaren, sagen wir mal 10-20 Icons geladen werden. Der Rest erst bei Bedarf. Bild: http://www.hd-rec.de/pics/filemanager4.png -- -- Author of HD-Rec, Sweeper, Samplemanager, ArTKanoid, Monkeyscript, Toadies, AsteroidsTR, TuiTED, PosTED, TKPlayer, AudioConverter, ScreenCam, PerlinFX, MapEdit, AB3 Includes und viele mehr... Homepage: http://www.hd-rec.de [ Dieser Beitrag wurde von Der_Wanderer am 01.08.2011 um 22:03 Uhr geändert. ] [ - Antworten - Zitieren - Direktlink - ] |
|
02.08.2011, 10:41 Uhr Holger Posts: 8116 Nutzer |
Zitat:Und warum verändert er sich? Weil die Implementierung davon ausgeht, dass alle Elemente gleich hoch sind (was sie offenbar nicht sind). Also kein Widerspruch zu dem von mir gesagten. Was ich dagegen von sich verändernden Scrollern halte, habe ich bereits gesagt. Ich bezweifle auch einfach mal, dass der Performancegewinn durch diese Technik real ist. Ich habe einfach schon zu viel Programmcode gesehen, der mit exakt dieser Technik exakt null Einsparung erzielt, weil der Overhead der Verwaltung solcher Strukturen höher als die mögliche Einsparung ist. Zitat:Sofern der Entwickler des ListViews wusste, was er tut. Der Adressat meines Beitrags waren nicht die Android Entwickler. Zitat:Nur braucht man dazu kein solch komplexes Konzept. Solche Datei-Listen sehen mit unterschiedlichen Höhen sowieso bescheiden aus, weshalb man i.A. das Layout auf eine bestimmte, angenommene Icon-Höhe fixiert und evtl. vorhandene größere Icons bei Bedarf skaliert. D.h. man braucht die Icons gar nicht, um das Layout zu berechnen. Insofern können die Elemente der Liste die Icons problemlos on-demand laden, ohne dass der ListView spezielle Algorithmen benötigt. Btw. schon mal bewusst wahrgenommen, was im Windows-Explorer bei hoher Systemlast oder wenig freiem Speicher passiert? Der lädt nämlich Icons auch bei Bedarf, bzw. asynchron ohne das GUI zu blockieren. Und wirft sie auch weg, falls der Speicher für andere Dinge benötigt wird. -- Good coders do not comment. What was hard to write should be hard to read too. [ - Antworten - Zitieren - Direktlink - ] |
|
02.08.2011, 10:49 Uhr Holger Posts: 8116 Nutzer |
@Der_Wanderer: PS: Der Screenshot sieht ganz nett aus. Allerdings leidet er an der sehr verbreiteten Krankheit der Rahmen-Inflation. Zur Entschärfung empfiehlt sich, wenigstens den überflüssigen senkrechten Divider in der Mitte zu entfernen und vielleicht den Rahmen der Statuszeile unten zu entfernen und stattdessen eine einfache Trennlinie zwischen Statuszeile und Toolbar einzuführen. -- Good coders do not comment. What was hard to write should be hard to read too. [ - Antworten - Zitieren - Direktlink - ] |
|
02.08.2011, 11:16 Uhr Der_Wanderer Posts: 1229 Nutzer |
Zitat:Oh, ich fühle mich geehrt ;-) Das mit den Rahmen stimmt, der Screenshot ist auch schon etwas älter. Die Gruppen haben jetzt dezentere Rahmen. Der Seperator in der Mitte sollte ein Balancer sein, gabs damals aber noch nicht. Man kann den Seperator aber auch borderless machen. Im Grunde war das auch nur ein ListView Test, ohne dabei eine ernsthafte App im Kopf zu haben. Ich wollte Mason zeigen, wie "schlecht" seine Copy/Move/Paste/Rename Icons sind. Man erkennt kaum einen Unterschied => ziemlich nutzlos ohne Text. Das hat er aber inzwischen verbessert. Das mit dem verzögerten Laden der Icons ließe sich auch anders lösen, da gebe ich dir Recht. Das macht NTUI auch so. Bilder werden erst beim Layouten angelegt. Evtl. sollte ich das bis auf das tatsächliche Zeichnen hinauszögern. Leider geht er momentan noch das Listview komplett durch. Übrigends: Die Icons passen sich an die Höhe der Listenzeile an, nicht umgekehrt. NTUI kennt bei Bildern verschiedene logische Größen, z.B. "Native", "Inline", "Button". "Inline" wird bei Listviews benutzt, und entspricht der Fonthöhe. Ich denke das ist eines der coolen Features von NTUI, dass man so leicht mit Bildern umgehen kann, die sich dem Gesamtlayout anpassen, z.B. größere Font => größere Bilder etc. Z.b. die Vorgabe von AISS sind meistens 24x24 Pixel, das passt ganz gut zu Toolbars, aber z.b. nicht so gut in einen Button oder in einen ListView. Mason hat deswegen eigene "ListView" Versionen von einigen Bildern erstellt, die kleiner sind. Das ist aber nicht der richitge Weg denke ich. Denn dadurch gibt Mason indirekt die Fontgröße vor, in denen das ganze gut aussieht. Das habe ich ihm auch des öfteren vorgeschlagen, alle Bildchen einfach 48x48 oder noch größer zu machen, und zur Kompatibelität beim Installieren die finale Größe wählen lassen. Apps die resizen können, dürfen dann aber auch die "große" Variante nutzen. Beispiel was möglich wäre: Bild: http://www.hd-rec.de/pics/aiss_save_c7.png Ich denke die skalierten Versionen sehen nicht schlechter aus als die original bilder, vergl. die 24px AISS mit meinem 24px skaliertem. Auch Posteprocessing ließe sich beim Installieren anwenden (oder in einer Art AISS Manager configurieren), z.b. für Leute die auf den Glow Effekt stehen: Bild: http://www.hd-rec.de/pics/toolbar2.png -- -- Author of HD-Rec, Sweeper, Samplemanager, ArTKanoid, Monkeyscript, Toadies, AsteroidsTR, TuiTED, PosTED, TKPlayer, AudioConverter, ScreenCam, PerlinFX, MapEdit, AB3 Includes und viele mehr... Homepage: http://www.hd-rec.de [ Dieser Beitrag wurde von Der_Wanderer am 02.08.2011 um 11:29 Uhr geändert. ] [ Dieser Beitrag wurde von Der_Wanderer am 02.08.2011 um 11:53 Uhr geändert. ] [ - Antworten - Zitieren - Direktlink - ] |
|
02.08.2011, 12:06 Uhr AGSzabo Posts: 1663 Nutzer |
@Der_Wanderer: Wie verwaltest du denn die images? -- Sam mini os4.1 upd. 2 / e-uae 39bb2 / A4000D 3.0 & 3.9 2mbchip 8mbfast Ariadne_II ide DVD und HD / A500 3.1 (mkick) adide 50mb / Athlon ii X2 Ubuntu Linux [ - Antworten - Zitieren - Direktlink - ] |
|
02.08.2011, 15:06 Uhr Der_Wanderer Posts: 1229 Nutzer |
Es gibt ein Bitmap Objekt (das ist ausnahmsweise mal kein Widget!), und nicht zu verwechseln mit dem Image Widget. Das hat eine ID (der Dateiname oder z.B. "FILE" für einige generische Images) Es kann entweder Vektor Bilder oder Bitmaps enthalten. Die Bitmaps haben wiederum das original Bild und auf Anfrage diverse Scalierungsstufen, die aber erst erstellt werden wenn das Bild gezeichnet werden soll. Die Skalierungsstufe wird nicht in Pixeln angegeben, sondern in logischer Größe, z.B. native, inline etc. "native" ist relativ klar, aber z.B. "inline" entscheidet sich je nach eingestellter Font. Zudem gibt es noch verschiedene "Draw Modi" pro Bitmap, z.b. Normal, Selected, Ghosted, Focused und Mover. (hier nur N/S/G zu sehen) Je nachdem aus welcher Quelle das Bild kommt, werden die einzelnen Modi geladen oder errechnet. Z.b. bei AISS wird nach *_s für Selected gesucht. Wird das nicht gefunden, erzeugt NTUI entprechend den Preferences ein Selected Bild, z.B. mit Glow. Man kann auch per NTUI Prefs die internen Vektor Bilder nach AISS mappen. Das muss der App Programmierer aber nicht wissen. Es werden auch Nine-Patch Images unterstützt, damit arbeiten für gewöhnlich die Strechable-Bilder für die Skins. Das Skin System macht eigentlich nichts anderes, als z.B. die "Vektor-Bilder" eines Button Rahmens mit einer Bitmap auszutauschen. Für Skins habe ich also keinerlei extra Arbeit, das geht alles über die normalen Zeichenroutinen. Auch kann man seine App programmatisch individuell skinnen. Das eigentliche NTUI Skin agiert ja nur als Default Grafik. So kann ich einem Button z.b. per SetAttr(button,ATTR_BGIMAGE,"DH0:mybutton.png") ein eigenes "Skin" verpassen. Bild: http://www.hd-rec.de/pics/ntui_images1.png -- -- Author of HD-Rec, Sweeper, Samplemanager, ArTKanoid, Monkeyscript, Toadies, AsteroidsTR, TuiTED, PosTED, TKPlayer, AudioConverter, ScreenCam, PerlinFX, MapEdit, AB3 Includes und viele mehr... Homepage: http://www.hd-rec.de [ Dieser Beitrag wurde von Der_Wanderer am 02.08.2011 um 15:10 Uhr geändert. ] [ - Antworten - Zitieren - Direktlink - ] |
|
02.08.2011, 16:02 Uhr AGSzabo Posts: 1663 Nutzer |
@Der_Wanderer: hmmm, mächtig mächtig. das mit dem "jeder button eigenes image" hab ich anfangs so geplant gehabt aber dann verworfen weil ich dachte dass das keiner braucht. ich hab auch ein bitmap-objekt, das kein widget ist: code:STRUCTURE ImageNode,MLN_SIZE APTR oxIN_imagename APTR oxIN_dtobject APTR oxIN_bitmap APTR oxIN_bitmapheader APTR oxIN_screen UWORD oxIN_userscount LABEL oxIN_SIZEOF Das was da drin steht ist bei mir momentan immer das Ergebnis eines Calls zu Datatypes. Ich weiss schon dass das nicht befriedigend ist. Zudem ist dann jedes Image immer auf einen bestimmten Screen remappt, oder? Also wenn man zwei screens hat dann gibts den button zweimal im speicher. geht das anders? -- Sam mini os4.1 upd. 2 / e-uae 39bb2 / A4000D 3.0 & 3.9 2mbchip 8mbfast Ariadne_II ide DVD und HD / A500 3.1 (mkick) adide 50mb / Athlon ii X2 Ubuntu Linux [ - Antworten - Zitieren - Direktlink - ] |
|
02.08.2011, 16:34 Uhr Der_Wanderer Posts: 1229 Nutzer |
Das Ur-Bild wird immer in 24/32 Bit und original Größe im Speicher gehalten. Die andere Bildchen werden in einem Bitmap Cache verwaltet und erzeugt bzw. zerstört, je nach Anfrage. Bei 24bit screens muss nichts dupliziert werden. Bei Farb-Indizierten Screens bekommt aber jeder Screen seine remapped Bildchen, das kann man nicht anders lösen. Aber so wahnsinnig viel ist das nicht. Die Images werden Inner- und Cross-Application geshared. Ich brauche also z.B. ein Scroller-Arrow nur einmal, auch wenn er in zig Scrollern benutzt wird. Zitat:Also z.B. als Background Image kann zwar jeder Button ein eigenes haben, bei einem Skin haben sie aber logischerweise alle das gleiche Bild und nur einmal im Speicher. Jeder Button hat nur einen Verweis darauf. Das ist nicht teurer als ein "Border" Flag setzen oder sowas, ausser dass der Use-Count des Bildes hochgezählt wird. -- -- Author of HD-Rec, Sweeper, Samplemanager, ArTKanoid, Monkeyscript, Toadies, AsteroidsTR, TuiTED, PosTED, TKPlayer, AudioConverter, ScreenCam, PerlinFX, MapEdit, AB3 Includes und viele mehr... Homepage: http://www.hd-rec.de [ Dieser Beitrag wurde von Der_Wanderer am 02.08.2011 um 16:36 Uhr geändert. ] [ Dieser Beitrag wurde von Der_Wanderer am 02.08.2011 um 16:37 Uhr geändert. ] [ - Antworten - Zitieren - Direktlink - ] |
|
02.08.2011, 16:56 Uhr Thore Posts: 2266 Nutzer |
> Use-Count des Bildes hochgezählt Und ist dieser bei 0 wird das Image wieder gefreed? [ - Antworten - Zitieren - Direktlink - ] |
|
02.08.2011, 17:01 Uhr AGSzabo Posts: 1663 Nutzer |
@Thore wird wieder gefreed. @Der_Wanderer > Aber so wahnsinnig viel ist das nicht. ich habs geschafft mit meinem bischen skin auf 2mb zu kommen. -- Sam mini os4.1 upd. 2 / e-uae 39bb2 / A4000D 3.0 & 3.9 2mbchip 8mbfast Ariadne_II ide DVD und HD / A500 3.1 (mkick) adide 50mb / Athlon ii X2 Ubuntu Linux [ Dieser Beitrag wurde von AGSzabo am 02.08.2011 um 17:02 Uhr geändert. ] [ Dieser Beitrag wurde von AGSzabo am 02.08.2011 um 17:03 Uhr geändert. ] [ - Antworten - Zitieren - Direktlink - ] |
|
02.08.2011, 17:21 Uhr Der_Wanderer Posts: 1229 Nutzer |
2MB ist ja nicht viel. Skins sind was für "High-End" Rechner, z.B. mit 1GB RAM oder so. Für einen nackigen A1200 würdest du niemals Skins nehmen, das ist zu langsam und zu viel speicher. Die Skins machen eigentlich erst ab 24bit Screens Sinn. Sonst ist man mit dem "klassischen" Look besser bedient. Und sooo schlecht sieht der ja auch nicht aus. -- -- Author of HD-Rec, Sweeper, Samplemanager, ArTKanoid, Monkeyscript, Toadies, AsteroidsTR, TuiTED, PosTED, TKPlayer, AudioConverter, ScreenCam, PerlinFX, MapEdit, AB3 Includes und viele mehr... Homepage: http://www.hd-rec.de [ - Antworten - Zitieren - Direktlink - ] |
| -1- 2 | [ - Beitrag schreiben - ] |
| amiga-news.de Forum > Programmierung > UAE zu langsam oder Programmierfehler? | [ - Suche - Neue Beiträge - Registrieren - Login - ] |
|
|
Impressum |
Datenschutzerklärung |
Netiquette |
Werbung |
Kontakt
Copyright © 1998-2024 by amiga-news.de - alle Rechte vorbehalten. |
|
