|
ENGLISH VERSION |
|
 |
| Links | | | Forum | | | Kommentare | | | News melden |
|
| Chat | | | Umfragen | | | Newsticker | | | Archiv |
|
| amiga-news.de Forum > Suche | [ - Suche - Neue Beiträge - Registrieren - Login - ] |
|
||||||
|
Der_Wanderer
Nutzer
29.08.2011, 13:56 Uhr [ - Direktlink - ] |
Thema: Skalieren und so
Brett: Programmierung Das hier sind die Benchmark ergebnisse auf meinem i5 unter WinUAE. Ist alelrdings mit etwas Vorsicht zu geniessen, da Windows die Files cached. Ich habe daher von RAM Disk nach RAM Disk gemacht. Resizen von (1920x1080) => (800x450) using window interpolation Time for loading: 53 ms (JPEG) Time for loading: 84 ms (BMP) Time for loading: 95 ms (PNG) Time for scaling: 19 ms (none) Time for scaling: 234 ms (Window) Time for scaling: 3145 ms (GUI) Time for scaling: 3681 ms (linear) Time for saving: 73 ms (JPEG) Time for saving: 174 ms (BMP) Time for saving: 335 ms (PNG) Interessant finde ich dass JPEG so Hölle schnell ist. Hätte ich nicht erwartet. Lineare Interpolation sollte eigentlich schneller sein, das habe ich wohl nicht wirklich optimiert. Scheint auch etwas seltsam, dass GUI so viel langsamer als Window ist. Eigentlich sollte es nur etwa 3x so langsam sein. -- -- 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 |
|||||
|
Der_Wanderer
Nutzer
29.08.2011, 13:38 Uhr [ - Direktlink - ] |
Thema: Skalieren und so
Brett: Programmierung @gerograph Dir ist irgendwie der Alpha Kanal verloren gegangen. Daher kann man das nicht ganz vergleichen. Die Filter sehen ehrlich gesagt alle sehr ähnlich 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 |
|||||
|
Der_Wanderer
Nutzer
29.08.2011, 10:13 Uhr [ - Direktlink - ] |
Thema: Skalieren und so
Brett: Programmierung @gerograph Das Entpacken kannst du nicht beschleunigen. Und auch nicht parallelisieren. Das müsste der Datatype Author machen. Das Entpacken benötigt in der Regel deutlich länger als das holen der Daten von Disk. Deshalb würde ich mir darüber keinen Kopf machen was Holger da in den Raum geschmissen hat. Das gleiche gilt für das Packen, dass vermutlich nochmal deutlich länger dauert als das Entpacken. Ich mache mal bei mir einen Timing Test, damit du ein Bild davon hast wie die Relationen sind. -- -- 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 |
|||||
|
Der_Wanderer
Nutzer
29.08.2011, 00:23 Uhr [ - Direktlink - ] |
Thema: Skalieren und so
Brett: Programmierung @gerograph Entscheidend sind alle drei Dinge die passieren, wenn du den kompletten Vorgang misst. 1. Laden (= von Platte holen und entpacken) 2. Resizen 3. Speichern (= packen und auf Platte schreiben) Uns interessiert hier aber eigentlich nur das Resizen, und die einzelnen Programme können sich bereits sehr stark beim Laden und Speichern unterscheiden. Das Problem mit den Fotos ist, dass sie auf 1:1 Pixelebene recht unscharf sind. Deshalb hier bereits ein kleines Bild mit vielen Details. Dadurch kann man besser sehen, was der Algorithmus macht. Wenn er darauf gut funktioniert, dann sicher auch auf deinen Fotos. @holger Parallelisieren ja, aber uns interessiert hier der Algo, weniger die Anwendung oder das eigentliche Batch Processing. Der Algo kann auch für andere Dinge eingesetzt werden, z.B. bei einem Spiel um die Sprites zu skalieren oder Icons in einer GUI. Also bitte nicht Off-Topic gehen, es geht hier darum die verschiedenen Algos zum Resizen, vor allem Herunterscalieren, zu evaluieren. Die tatsächliche Laufzeit spielt auch keine so große Rolle wie die Komplexität des Algorithmus, da die Laufzeit stark von der Optimierung und dem Geschick der Implementation abhängt. -- -- 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.08.2011 um 00:24 Uhr geändert. ] [ Dieser Beitrag wurde von Der_Wanderer am 29.08.2011 um 00:27 Uhr geändert. ] |
|||||
|
Der_Wanderer
Nutzer
28.08.2011, 21:34 Uhr [ - Direktlink - ] |
Thema: Skalieren und so
Brett: Programmierung Und hier mit den von mir implementierten Algorithmen (von 512x320 => 320x200 das sind auf 62.5%) Nearest Neighbour / Lineare Interpolation (ohne Tiefpass) Bild: http://www.hd-rec.de/pics/testpic_nn.png Bild: http://www.hd-rec.de/pics/testpic_lin.png Window Scaling / Window Scaling + 0.5 sharpnes Bild: http://www.hd-rec.de/pics/testpic_win.png Bild: http://www.hd-rec.de/pics/testpic_win05.png Weighted Window Scaling (für Icons) Bild: http://www.hd-rec.de/pics/testpic_gui.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 |
|||||
|
Der_Wanderer
Nutzer
28.08.2011, 21:18 Uhr [ - Direktlink - ] |
Thema: Skalieren und so
Brett: Programmierung So, hier wäre mein Vorschlag zu testen: Bild: http://www.hd-rec.de/pics/testpic.png Die Icons (und damit das Bild) ist mit Alpha Transparenz. -- -- 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 |
|||||
|
Der_Wanderer
Nutzer
28.08.2011, 20:14 Uhr [ - Direktlink - ] |
Thema: Skalieren und so
Brett: Programmierung Also erstmal brauchen wir einen normalen Skalierungslagorithmus, bevor was experimentelles auf den Tisch kommt. Für Fotos und sonstige 24bit Grafiken, auch mit Alpha Channel. Und zwar einen der schnell und passabel ist, und einen der langsamer (aber vertretbar) ist und sehr gute Ergebnisse liefert. Und das auf beliebigen Bitmaps. Wenn man das hat, kann man sich um spezielle Geschichten kümmern. Das habe ich aber eigentlich nicht vor, wer braucht schon sowas wie HQ3x, ausser für Pixelgrafik von alten Spielen? Wie schon erwähnt, wenn man Icons resized, dann liegt das Bild in der Regel in höherer Auflösung oder als Vektor Bild bereits vor, sonst hat man was beim Erstellen falsch gemacht. Vektorisieren um danach Hochzuskalieren ist in etwa so wie Zucker in die Suppe schütten weil man sie vorher versalzen hat, eine Art Verzweiflungsakt eben, weil es keine bessere Quelle gibt. @gerograph Wenn du incl. Laden und Speichern misst, dann machst du ja eher einen Benchmark der Datatypes bzw. der Speicherroutine. Das ist nicht wirkich aussagekräftig wie schnell der eigentliche Algorithmus zum skalieren ist. Die Plattengeschwindigkeit spielt dabei auch eine verschwindend geringe Rolle. Unter Windows wird die Datei sowieso erstmal nur gecached. Wenn das speichern 1s dauert, dann sind davon 999ms das packen bzw. aufbereiten des Bildes zum abspeichern. Und da ist ein i5 halt bestimmt 50x so schnell wie der PPC im SAM. Die Dinger gehen nämlich richtig ab. Die Testbilder von dir finde ich etwas unglücklich gewählt, weil sie bereits so unscharf sind, dass es fast egal ist was für einen Algorithmus man darauf los lässt. Ich werde ein Testbild vorbereiten, was die schwächen der Algorithmen richtig bloßstellt. -- -- 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 |
|||||
|
Der_Wanderer
Nutzer
28.08.2011, 17:27 Uhr [ - Direktlink - ] |
Thema: Skalieren und so
Brett: Programmierung Das mit den schnellen Algos ist schon richtig, aber wenn die Qualität unbrauchbar ist, dann nützt das auch nix (Nearest Neighbour). Auch sollte das Verhältnis zum laden und Speichern des Bildes gewahrt bleiben. Es nützt nichts, wenn der NN in 10ms resized, laden und speichern des Bildes aber 2 sec dauert. Dann kann ich mir 0,5 sec leisten fürs resizen, ohne dass es auffällt. Bei dem Speed Test vom Resizen würde mich interessieren, wie der Sharpen Parameter beim Window Scaling war. Wenn er 0 ist, sollte es deutlich schneller sein. Auch beim neuesten AB3 sind ein paar Speedups drin. https://sourceforge.net/projects/amiblitz3/files -- -- 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 |
|||||
|
Der_Wanderer
Nutzer
28.08.2011, 13:40 Uhr [ - Direktlink - ] |
Thema: Skalieren und so
Brett: Programmierung Ich hoffe der lange Einleitungstext hat nicht zu viele abgeschreckt!  Also eigentlich geht es hier darum, erstmal einen gewöhnlichen Skalierungsalgorithmus auszuwählen der für allgemeine Zwecke gut funktioniert, ohne dass z.B. zu iBatch immer Kommentare kommen über die angeblich schlechte Skalierungsqualität. eigentlich bin ich auch der Meinung, dass Window-Scaling vollkommen ausreicht, aber lasse mich gerne eines besseren belehren. Dinge wie Vektorisieren oder HQ3x sind Spezial-Algorithmen für ein Nischenproblem, das ich in meiner Abhandlung der Vollständigkeit halber aufgeführt habe. Wirklich interessant ist das für den Thread erstmal nicht. Also dann werde ich mal ein Test-Bild generieren und die Ergebnisse meiner bisher implementierten Algorithmen vorstellen. -- -- 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 |
|||||
|
Der_Wanderer
Nutzer
27.08.2011, 17:37 Uhr [ - Direktlink - ] |
Thema: Skalieren und so
Brett: Programmierung Dieser Thread geht über das Skalieren von Bildern, und welchen Algorithmus man am besten dafür wählt. Gundsätzlich kann man Hoch- (Anzahl der Pixel erhöhen, engl. upscaling) oder Runterskalieren (Anzahl der Pixel verringern, engl. downscaling). Hochskalieren Informationstheoretische Betrachtung: Zum Speichern eines Bildes ist Hochskalieren wenig sinnvoll, da man keinerlei neue Information hinzufügt, sondern lediglich die gleiche Information mit mehr Pixeln darstellt. Da ein Kompressionsalgorithmus wie zlib oder JPEG das nicht weis, versucht er die Information dann so zu packen als könnte jedes neue Pixel komplett Information enthalten. Die daraus resultierende Datei ist i.A. größer, auch wenn keinerlei Information dazu gekommen ist. Als Beweis könnte man sich einen Algorithmus vorstellen, der das Hochskaliere Bild wieder exakt auf das original Bild herunterskaliert, speichert, und beim entpacken das Original lädt und wieder hochskaliert. Damit ist gezeigt, dass es einen Algorithmus gibt, der das Hochskalierte Bild genauso klein packen kann wie der beste vorstellbare Packer des Originalbildes. Es kann also keine neue Information dazu gekommen sein. Beispiel für Hochskalieren: Original 3x3 => Nearest Neighbour / Lineare Interpolation / Cosinus Interpolation: Bild: http://www.hd-rec.de/pics/int_none.png => Bild: http://www.hd-rec.de/pics/int_nn.jpg Bild: http://www.hd-rec.de/pics/int_lin.jpg Bild: http://www.hd-rec.de/pics/int_cos.jpg Hochskalieren kann sinnvoll sein, wenn man eine bestimmte Auflösung liefern muss, und das eigene Bild ist kleiner, z.b. um es Vollbild anzuzeigen. In der Regel ist ein Hochskalieren aber nicht erstrebenswert, da das Resultat in der ein oder anderen Form immer unscharf oder seltsam detailarm aussieht. Eine kleine Ausnahme gibt es dennoch, das sog. "Hollywood Scaling". Man kennt das aus Filmen oder Serien wie CSI, wenn das Standbild einer Sicherheitskamera grossgezoomed wird, das zunächst furchbar noisy und unscharf ist, dann aber durch einen Filter (der auf die Frage "Kriegen Sie es noch ein wenig schärfer?" reagiert) wieder "scharf" gemacht wird, sodass neue Details erkennbar werden die vorher nicht zu sehen waren. Das geht natürlich auch mehrmals hintereinander bis man den Mörder erkennen kann ;-) Das geht in Wirklichkeit aber nur, wenn neue Information dem Bild hinzugefügt wird, die vorher nicht im Bild war. Und das geht tatsächlich. Man versucht dabei aus einer (sehr grossen) Bilder-Datenbank (wie z.B. dem Internet) Teile wiederzuerkennen, die im eigenen, durch Hochskalieren unscharf gewordenen Bild vorkommen. Der Ausschnitt aus der Datenbank, z.B. ein Gesicht, das eine höhere Auflösung besitzt, ergänzt dann die hohen Frequenzen im unscharfen Bild (unscharf = mangel an hohen Frequenzen). Die so neu gewonnen Information sind allerdings nur geraten, und nicht aus der Wirklichkeit abgeleitet, sodass man natürlich keine kriminalistischen Schlüsse daraus ziehen kann. Für das Auge sieht es trotzdem plausibel aus. Für unsere Amigas ist das aber sowohl vom Rechenaufwand als auch vom Speicheraufwand utopisch, und in unserer limitieren Freizeit auch nicht nachprogrammierbar (... obwohl? ;-) Es gibt noch weitere Tricks, wie man ein Hochskalieren kann ohne "unscharf" zu werden. Oft macht das aber nur für eine ganz bestimmte Anwendung oder Bilder-Art Sinn. Z.b. der HQ3x Algorithmus (http://www.hiend3d.com/hq3x.html) versucht Linien/Muster zu erkennen und durch eine feinere Auflösung zu ersetzen. Bei Farb-Indizierten oder comichaften Bildern, wo sich die Farbe nicht ständig von Pixel zu Pixel ändert, kann man damit ganz gute Ergebnisse erzielen. Bei Emulatoren von Systemem mit niedriger Auflösung (C64, Amiga OCS/AGA) kann man oft durch sog. Scannlines die Auflösung verdoppeln, wobei jede zweite Zeile einfach keine Information, nur einen schwarzen Balken enthält. Man überlässt dann dem Gehirn, sich die zusätzliche Information dazu zu denken, was erstaunlich gut funktioniert. Oft wird hier auch das simple Wiederholen der Pixel und die daraus resultierenden Pixel-Blöcke als besser empfunden als eine Interpolation, die das Bild unscharf macht. Für Fotos oder beliebige Bilder sind solche Verfahren aber alle nicht geeignet. Beispiele: Original => Normale Interpolation / Pixel Verdopplung, Nearest Neighbour / Scanlines / HQ3x Bild: http://www.hd-rec.de/pics/randam_orig.png => Bild: http://www.hd-rec.de/pics/randam_lin.png Bild: http://www.hd-rec.de/pics/randam_nn3x.png Bild: http://www.hd-rec.de/pics/randam_sl3x.png Bild: http://www.hd-rec.de/pics/randam_hq3x.png * Bild genommen von http://www.hiend3d.com/hq3x.html Runterskalieren Beim Runterskalieren verringert man die Anzahl der Pixel im Vergleich zum original Bild, und verliert daher Information. Die resultierende Datei ist dann i.A. kleiner als das original Bild, was oft der Hauptgrund des Herunterskalierens ist. Der Vorgang ist aber nicht mehr umkehrbar. Die JPEG Kompression nutzt z.B. Herunterskalieren, um Bilder noch kleiner zu packen (allerdings nur der Farbe, nicht der Helligkeit, weil unser Auge für Helligkeit sensibler ist als für Farbgebung). Neben dem Einsparen von Speicher gibt es für das Herunterskalieren viele weitere Gründe. Z.B. man möchte ein Foto auf dem Bildschirm anzeigen, das heutzutage oft in einer sehr viel höheren Auflösung als die des Bildschirms vorliegt. Beim Bearbeiten von Grafiken ist es oft vorteilhaft, in einer höheren Auflösung zu arbeiten, als das Bild später benötigt wird. Das nennt man auch Super-Sampling. Zum einen werden dadurch kleinere Fehler und Ungenaugigkeiten verziehen, man bekommt Anti-Aliasing geschenkt und hält sich die Möglichkeit offen, verschiedene kleinere Größen zu erzeugen, z.B. bei Icons. Bild: http://www.hd-rec.de/pics/aiss_save_c7.png (hier im Vergleich mit AISS, die nur in 24px vorliegen, wodurch der Anwendungsbereich eingeschränkt wird) Man erhält deutlich bessere Ergebnisse, wenn man z.B. in 400px arbeitet und daraus eine 100px und 90px Version erzeugt, als wenn man in 100px arbeitet und daraus eine 90px Version erzeugt. Das liegt daran, dass die 400px Version mehr Informationen enthält wo genau die Farbwerte im 90px Bild liegen müssen. Generell sind Skalierungsfaktoren zwischen 0.5 und 1.0 unvorteilhaft, was am Aliasing liegt. Bild: http://www.hd-rec.de/pics/400_90x.png Die Skalierung von 100=>90px lässt das Bild (oben) deutlich mehr vermatschen als die Skalierung von 400=>90px, obwohl die Skalierung von 400=>100px durch den ganzzahligen Faktor sehr gut gemacht werden kann. Aliasing Beim Runterkalieren hat man nicht das Problem (Pseudo-)Information hinzufügen zu müssen, sondern Information wegzuschmeissen. Das ist in der Regel sehr viel einfacher. Aber es wäre zu schön, wenn es da nicht noch das Problem mit dem Aliasing gäbe. Wenn wir ein Bild herunterskalieren, können wir die feinsten Details (=hohe Frequenzen) des original Bildes nicht mehr darstellen. Wenn wir nichts unternehmen, und das Bild einfach neu abtasten, dann kann es sein dass wir wichtige Punkte im Bild überspringen, z.b. eine dünne Linie. Dadurch können unerwünschte Effekte im Bild auftreten, die man Aliasing nennt. Um dem entgegen zu wirken muss man vor dem Runterskalieren also erstmal alle Details entfernen, die in der Zielauflösung nicht dargestellt werden können. I.A. macht man das mit einem Tief-Pass Filter. Das Resultat ist erstmal ein unscharfes Bild, dass dann aber durch Neu-Abtatung in der niedrigeren Auflösung kein Aliasing mehr aufweist und der Auflösung entsprechend wieder "scharf" ist. Da es in der Natur und in der digialen Welt keinen perfekten Filter gibt, vor allem was die flankensteilheit anbelangt ist nun auch klar, warum Skalierungsfaktoren zwischen 0.5 und 1.0 unvorteilhaft sind. Um Aliasing zu vermieden, muss man hohe Frequenzen herausfiltern. Da die Flankensteilheit aber nicht unandlich ist, muss man zu viel wegfiltern und das Resultat ist etwas unschärf. Oder man filtert gar nicht, bekommt dann aber Aliasing Effekte. Original => Bild: http://www.hd-rec.de/pics/scalingtest.png => Nearest Neighbour / Lineare Interpolation / Window Interpolation / Weighted Window Interpolation Bild: http://www.hd-rec.de/pics/scalingtest_nn2.png Bild: http://www.hd-rec.de/pics/scalingtest_lin2.png Bild: http://www.hd-rec.de/pics/scalingtest_win2.png Bild: http://www.hd-rec.de/pics/scalingtest_gui2.png * Neaest Neighbour: Man sieht deutlich, wie einzelne Linien verloren gehen, weil sie übersprungen werden * Linear Interpolation: Schon viel besser, aber da vorher kein Tiefpass Filter angewand wurde, "verpasst" auch die lineare Interpolation ein paar Details. * Window Interpolation: Die Window Interpolation hat automatisch einen Tiepass Filter mit drin, und "verpasst" daher kein Detail, allerdings werden die dünnen linien grau, obwohl sie vorher schwarz waren. * Weighted Window Interpolaton: Hier werden Farbwerte höher gewichtet, die lokal seltener sind. Dadruch bleiben die schwarzen Linien fast schwarz, Details werden nicht mit dem Hintergrund verschmolzen und drohen unterzugehen. Nachteil ist, dass die Geometrie die Pixel leidet, z.B. die Abstände der Linien scheint nicht mehr äquidistant zu sein. Man sieht auch schön, dass bei dem grossen unscharfen Fleck so gut wie kein Unterschied besteht, egal welche Interpolation und mit oder ohne Tiefpass, weil der Fleck nur aus tiefen Frequenzen besteht. Gefahr durch Aliasing besteht hier also nicht. Algorithmen Es gibt viele verschiedene Algorithmen zum skalieren. Man könnte sie grob so einteilen: 1. Simple Neuabtastung (Nearest Neighbour) Vorteile: sehr schnell, farbentreu (das Zielbild enthält nur Farbwerte die im Original auch vorkommen, daher praktikabel für farb-indizierte Grafiken) Nachteile: ohne Tiefpass Filter Aliasing Effekte, Unstetigkeiten im Bild (Treppeneffekte) 2. Neuabtastung mit Interpolation (linear, cosinus, quadratisch, cubisch, sinc/lanscoz, splines) Vorteile: keine Unstetigkeiten/Treppeneffekte Nachteile: Je nach Interpolationsmethode deutlich aufweniger/langsamer 3. Algorithmen die den Inhalt des Bildes interpetieren (Weighted Widnow/Entropy, HQ3x) Vorteile: In speziellen Fällen oft deutlich bessere Skalierung Das wird dadruch erreicht, dass ein Bild nicht starr neu abgetastet wird, sondern bestimmte Kriterien angelegt werden, welcher Pixel wie viel Beitrag zum Zielpixel leisted. Z.b. kann ein Nearest Neigbour beim herunterskalieren so modifiziert werden, dass er Pixel überspringt die ähnlich zu bereits übernommenen Pixeln sind, und Pixel bevorzugt, die deutlich anders sind als die Umgebung. Dadurch können Details erhalten bleiben. Nachteile: aufwendig, nicht generell einsetzbar, manchmal unpassende Vorhersage und dadurch Artefakte Beispiel: Weighted Window Interpolation (funktioniert gut für kleine Icons): Bild: http://www.hd-rec.de/pics/iconscale2_c.png Lineare Interpolation / Entropy Weighted / Original Nach all dieser Theorie möchte ich jetzt die Suche nach einem praktikablen Algorithmus starten da ja des öfteren Kritik geäussert wurde. Dabei hoffe ich auf eure Mithilfe. Diese Algorithmen würde ich dann in meinen Algorithmen Pool aufnehmen, der Hauptsächlich in Amiblitz3 abgebildet ist (als App zu finden z.B. in iBatch oder dem ImageConverter oder NTUI), allerdings nutze ich diese Dinge auch woanders. Beurteilung der Algorithmen Die Geschwindigkeit könnte man unterteilen in * echtzeitfähig (<<20ms@1MP) * schnell (<1s@1MP) * langsam (<10s@1MP) * experimentell (>10s@1MP). Anmerkung: 1MP = 1 Megapixel, also ein Bild mit etwa 1000x1000 Auflösung oder z.B. die gängige Laptop Auflösung 1280x800. "Echtzeit" ist heutzutage eher uninteressant, weil das die Hardware macht, und ohne HW kommt eigentlich nur NN in Frage oder linear ohne AA Filter. "Schnell" sollte so laufen, dass man damit eine Stapelverarbeitung in erträglicher Zeit durcharbeiten kann, z.B. ein Verzeichnis mit Fotos auf Website größe oder Thumbnails zu skalieren. Oder in einem Spiel Grafiken auf die gewählte Auflösung skaliert, wie in AmegaOne oder PanZers. Mit "langsam" wäre das auch möglich, aber auf schwächeren Rechnern kaum noch erträglich, da er Minuten bis Stunden oder gar über Nacht laufen müsste. Und bei "experimentell" spielt die Zeit keine Rolle, es geht nur um das Ergebnis. Der Rechner darf also ruhig einen Tag lang am Ergebnis rechnen. Die Qualität in * schlecht * zur Darstellung geeignet * zur Verarbeitung geeignet * ausserordentlich "Schlecht" wäre, wenn man deutliche Artefakte sieht, z.B. NN., das Bild also wirklich kein Augenschmaus mehr ist. "Zur Darstellung geeignet" wäre die Qualität in einem Bildbetrachter oder in einem Thumbnail, aber noch nicht gut genug um das in einem Grafikbearbeitungsprogram zu akzeptieren. (z.B. linear?) "Zur Verarbeitung geeignet" wäre die Qualiät, wenn man damit bedenkenlos sein Fotoalbum skalieren könnte für eine Website oder Grafiken auf ihre finale Auflösung in einer GUI bringt. "ausserordentlich" ist alles, was überdurchschnittlich gute Qualität liefert, die auch von Photoshop oder anderen Referenzprogrammen nicht übertroffen wird. Test-Bild Damit man Algorithmen vergleichen kann, sollte man auch das gleiche Bild skalieren. Dabei ist es wichtig, dass in dem Bild alles vertreten ist was man testen möchte. Vorschläge? -- -- 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 |
|||||
|
Der_Wanderer
Nutzer
08.08.2011, 11:59 Uhr [ - Direktlink - ] |
Thema: Enthüllungen über die Bibel
Brett: Get a Life @Holger: Du hast recht. Ich meinte eher den Bildungstand eines 10 Jährigen (in unserer Zeit). Trotzdem kommt dazu, dass die Leute sich wesentlich schlechter entwickeln konnten. Ließ mal Berichte von deutschen Ausbildern, die afghanische Sicherheitskräfte ausbilden. Oder Berichte von Helfern aus der dritten Welt über die kognitiven Fähigkeiten von Mangel- oder Fehlernährten. Das trifft natürlich auf die "Schriftgelehrten" weniger zu, weil die aus reichen Verhältnissen stammten. Trotzdem war die damalige Weltanschauung aus unserer heuten Perspektive unglaublich naiv. Das merkt man, wenn man mal eine Bibelgeschichte ohne die üblichen Floskeln (wie "Und es begab sich...") im heutigem Sprachgebrauch zusammenfasst. Da muss ich immer an Ritter der Kokosnuss denken, wo die Beweiskette aufgebaut wird, warum die Frau keine Hexe sein kann... > Heutige Verschlüsselungen sind auch in einigen Jahren nichts mehr wert. Jein. Nur weil die Rechenleistung steigt, heißt das nicht, dass das Verfahren schlecht ist. Dann muss man lediglich die Schlüssellänge erhöhen. Aber heute ist man sich dessen bewusst, das ist der Unterschied. Ein Ceasar Chiffre ist aber im Verfahren bereits schlecht. Auch die Enigma hatte verschiedene "Design Flaws". > Abgesehen davon ist die Aussage des Professors, selbst als Scherz, unsinnig. Dann hast du den Scherz wohl nicht verstanden. Er bewertet die Codierung der Nachricht als Text als stärkeres Chiffre als das anschließende Ceasar Chiffre, weil nur wenige Leute lesen konnten. Damit wollte er zeigen, wie wenig das Chiffre bringt. > Ich käme aber trotzdem nicht auf den Gedanken, Deinem Prof den Verstand eines zehnjährigen zuzuschreiben. Polemik, sorry. -- -- 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 |
|||||
|
Der_Wanderer
Nutzer
08.08.2011, 11:22 Uhr [ - Direktlink - ] |
Thema: Enthüllungen über die Bibel
Brett: Get a Life @AGZsabo Jetzt mal Spaß beiseite. Ich habe mir einige Passagen des Textes durchgelesen. Du hast da unglaublich viel Zeit und Mühe hineingesteckt, deshalb sollten wir hier auch respektvoll damit umgehen. ABER: Da sind einige Trugschlüsse drin, die man mit Hilfe von Informationstheorie ad absurdum führen kann. Es mag sein, dass die Bibelschreiber hier und da mal Informationen aus Spaß "versteckt" haben, aber du solltest nicht zu viel erwarten. Die meisten Menschen in dieser Zeit hatten den Verstand eines 10 Jährigen, einmal wegen der nicht vorhandenen Bildung, aber auch wegen der Ernährung. Leute wie Archimedes waren absolute Ausnahmeerscheinungen aber eher wie ein Abiturient einzuschätzen. Supertolle Weisheiten aus heutiger Sicht wird man also nicht erwarten können. Beispiel "Ceasar Chiffre". Unser Professor meinte damals aus Scherz, die kryptologische Stärke lag in der Tatsache, dass die Information überhaupt *aufgeschrieben* wurde, und so der Bote den Inhalt nicht kannte (also unter Folter nicht erzählen konnte), weniger an der Tatsache, dass sie chiffriert war. -- -- 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 |
|||||
|
Der_Wanderer
Nutzer
07.08.2011, 21:16 Uhr [ - Direktlink - ] |
Thema: Enthüllungen über die Bibel
Brett: Get a Life In der Zahl PI sind alle Kinofilme und Musikstücke drin, die es jemals gegeben hat - und, noch viel besser, geben wird! Und zwar in allen Datei Formaten und Auflösungen, auch die, die wir heute noch gar nicht abspielen können. Urheberrechtlich also höchst bedenklich diese Zahl ;-) Ob Archimedes damals schon einen Super-Quantencomputer mit Alientechnologie hatte? Nein, denn es kommt immer darauf an, wieviel Information die Suche nach der Nadel im Heuhaufen bereits enthält. Enthält die Suche mindestens genauso viel Information wie die Nadel, lässt sich logischerweise alles finden, weil man es vorher schon weis. -- -- 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 |
|||||
|
Der_Wanderer
Nutzer
02.08.2011, 21:46 Uhr [ - Direktlink - ] |
Thema: UAE zu langsam oder Programmierfehler?
Brett: Programmierung Zitat:Ja richtig. Gute Idee. Momentan läuft NTUI als Sourcecode in die App hineinkompiliert, deshalb habe ich da noch nicht auf die Library Funktionalität eingegangen. -- -- 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 |
|||||
|
Der_Wanderer
Nutzer
02.08.2011, 21:38 Uhr [ - Direktlink - ] |
Thema: UAE zu langsam oder Programmierfehler?
Brett: Programmierung @ARGzabo Also für 4 Farb Pens habe ich noch nicht optimiert und vertraue derzeit auf ObtainBestPen. Bei 4 Farben ist es allerdings doch ratsam, die evtl. fest vorzugeben da man garantieren muss, dass z.B. Button Borders auch wirklich nicht auf der Background Farbe landen sondern sichtbar, in dem Fall "anders" als der Hintergrund sind. Das stellt aber kein Grundsätzliches Problem dar, wenn die GUI Engine auf einen Screen "poppt", dann kann man das ja abfragen und die Pens entsprechend setzen. Generell habe ich noch keinen so grossen Wert auf "abwärtskompatibelität" gelegt, d.h. Pen basierende Screens. Das fällt bei mir unter Optimieren (wir erinnern uns: Don't optimize yet!). Mein Ziel ist es eher, ein modernes Toolkit zu machen was sehr einfach für den App Programmierer ist und 24Bit anständig unterstüzt. Danaben soll es natürlich auch von 1-24Bit laufen, also auch auf einem Classic, aber dann sollte man in den Prefs einigen Schickschnack ausschalten. Auch ohne Skin finde ich dass NTUI ganz gut aussieht, vergleiche das mal mit Gadtools!! @Holger: Zitat:NTUI macht das mit allen Bilder so, egal ob sie von einem Icon, einem AISS (also .png) oder beleibigen Datatype geladen werden.Zitat:So sollte es sein. Hatte allerdings die Amiga-Workbench-Icons oder klassische Icon-Sammlungen, wie eben AISS im Hinterkopf. In meinem Scalingbeispielbildern siehst du einen bunten mix aus Icons und AISS Bildchen. Die Icons sind Ken Icons in 48px, die AISS 24px. Das mit dem Scalieren geht normalerweise gut bei 1:2, 1:3 etc., aber z.b. schlecht bei 24:21 oder so etwas. Das ist in NTUI nur zufriedenstellen möglich mit einem speziellen GUI Scaling algorithmus, der die Pixel Details versucht zu erhalten. Mit einem "normalen" Algorithmus sieht das Ergebnis nicht befriedigend aus. Beispiel: Das ist: 1. Photoshop "normal" 2. Photoshop "irgendwas Tolles" (Lanczos IIRC) 3. Mein patentiertes GUI Scaling 4. das Original Bild: http://www.hd-rec.de/pics/iconscale3_c.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 |
|||||
|
Der_Wanderer
Nutzer
02.08.2011, 17:27 Uhr [ - Direktlink - ] |
Thema: UAE zu langsam oder Programmierfehler?
Brett: Programmierung Bei einem Use Count von 0 muss noch nicht freigegeben werden. Erst wenn der "Garbadge Collector" anfängt Speicher frei zu machen, je nach Situation. Spätestens beim Beenden des letzen NTUI Programms (also beim Schließen der ntui.library), sonst hat ja NTUI keine Möglichkeit mehr. -- -- 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 |
|||||
|
Der_Wanderer
Nutzer
02.08.2011, 17:21 Uhr [ - Direktlink - ] |
Thema: UAE zu langsam oder Programmierfehler?
Brett: Programmierung 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 |
|||||
|
Der_Wanderer
Nutzer
02.08.2011, 16:34 Uhr [ - Direktlink - ] |
Thema: UAE zu langsam oder Programmierfehler?
Brett: Programmierung 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. ] |
|||||
|
Der_Wanderer
Nutzer
02.08.2011, 15:06 Uhr [ - Direktlink - ] |
Thema: UAE zu langsam oder Programmierfehler?
Brett: Programmierung 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. ] |
|||||
|
Der_Wanderer
Nutzer
02.08.2011, 11:16 Uhr [ - Direktlink - ] |
Thema: UAE zu langsam oder Programmierfehler?
Brett: Programmierung 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. ] |
|||||
|
Der_Wanderer
Nutzer
01.08.2011, 21:59 Uhr [ - Direktlink - ] |
Thema: UAE zu langsam oder Programmierfehler?
Brett: Programmierung 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. ] |
|||||
|
Der_Wanderer
Nutzer
29.07.2011, 18:54 Uhr [ - Direktlink - ] |
Thema: UAE zu langsam oder Programmierfehler?
Brett: Programmierung 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. ] |
|||||
|
Der_Wanderer
Nutzer
27.07.2011, 10:57 Uhr [ - Direktlink - ] |
Thema: UAE zu langsam oder Programmierfehler?
Brett: Programmierung 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 |
|||||
|
Der_Wanderer
Nutzer
27.07.2011, 10:54 Uhr [ - Direktlink - ] |
Thema: UAE zu langsam oder Programmierfehler?
Brett: Programmierung 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. ] |
|||||
|
Der_Wanderer
Nutzer
27.07.2011, 09:15 Uhr [ - Direktlink - ] |
Thema: UAE zu langsam oder Programmierfehler?
Brett: Programmierung 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 |
|||||
|
Der_Wanderer
Nutzer
26.07.2011, 21:13 Uhr [ - Direktlink - ] |
Thema: UAE zu langsam oder Programmierfehler?
Brett: Programmierung 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 |
|||||
|
Der_Wanderer
Nutzer
26.07.2011, 15:47 Uhr [ - Direktlink - ] |
Thema: Jetzt nochmal das Notify
Brett: Programmierung Zitat:Genau, weil das wiederum bedeutet, dass du dir gar nicht wirklich klar bist, wie und was du machst. Und dann läuft du Gefahr Dinge zu mischen die auseinander gehören oder Dinge zweimal zu machen die zusammengehören. @Holger Ja, als Aktion sollte man das Ganze verstehen, d.h. zur Aktion gehört auch der App Code, richtig? @Holger Mit deiner Kritik, dass die XML z.b. keine Default Werte oder Wertebereiche setzen darf, bin ich nicht einverstanden. Alle GUI Toolkits die ich kenne machen das so. Man kann sie natürlich programmatisch auch setzen, muss man aber eben nicht. Welche Object IDs es gibt, und welche Notify an die App es gibt, definieren letztendlich beide, die App und das XML. Beides muss logischerweise matchen. In integrierten Umgebungen erstellt daher der GUI Builder ein automatisches Include mit den #defines, die man im Programmcode benutzt. Mein Ziel war es aber, nicht an eine bestimmte Sprache(n) gebunden zu sein. Deshalb muss man darauf "vertrauen", dass die XML die IDs und Notifys in der gleichen Schreibweise enthält wie die App. Das ist die Achillesverse meines Systems, habe aber keine bessere Möglichkeit gefunden. In der Praxis funktioniert das aber trotzdem sehr gut, wie man bei stormwizard sehen kann, dort ist es genauso. (Frei-Text IDs ohne festes #define) -- -- 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 |
|||||
|
Der_Wanderer
Nutzer
26.07.2011, 10:41 Uhr [ - Direktlink - ] |
Thema: Jetzt nochmal das Notify
Brett: Programmierung Dann verlangst du aber zu viel von den Lesern, die erst aus deinen langen Erklärungen herausknobeln müssen, wovon du redest. Du läuft dann auch schnell Gefahr, dinge zu verwischen die eigentlich verschieden sind, oder Dinge zweimal zu tun die man auch als eins abhandeln kann. Z.b. "dein" Binding" und "dein" Notify sieht mir suspekt aus ;-) Wehre dich nicht gegen das, was kluge Köpfe bereits vorgedacht haben. Ziehe deinen Nutzen daraus. -- -- 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 |
|||||
|
Der_Wanderer
Nutzer
26.07.2011, 09:53 Uhr [ - Direktlink - ] |
Thema: Jetzt nochmal das Notify
Brett: Programmierung Ich kann mich Thore nur anschließen. Du kannst ja deine Engine implementieren wie du willst, es gibt keine "Norm", deshalb ist ein Attribut aber immer noch ein Attribut und eine Methode eine Methode. Du solltest dir diese Begriffe korrekt aneignen, das hilft nicht nur mit anderen zu kommunizieren, sondern auch dir selbst. Denn wir "denken" in Sprache. Wenn man etwas korrekt benennen kann, dann kommt man gedanklich auch viel besser klar wenn man plant. Zitat:Ja, so habe ich das auch gesehen und deshalb heißen bei mir die Ereignisse (ich sage jetzt bewusst nicht Event...), die der App Programmierer "registiert" hat und empfangen möchte, Notifies. Ich denke das kommt dem Sinn eines Notifies recht nahe. Ich glaube Holger hat das "Action" genannt. Bitte korrigiere mich, wenn ich falsch liege. -- -- 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 |
|||||
|
Der_Wanderer
Nutzer
25.07.2011, 15:27 Uhr [ - Direktlink - ] |
Thema: Jetzt nochmal das Notify
Brett: Programmierung Zitat:Nein, nicht "bei dir". Das oben ist auch nicht "bei mir", sondern so werde die Ausdrücke in der Fachsprache verwendet, und darauf sollten wir uns einigen. Sonst schreibst was von Methoden und ich denke es sind Funktionen, während du Events meinst o.Ä. Ohne gemeinsame Sprache können wir schlecht kommunizieren. Zitat:Nein. Eine Message ist etwas, was von A nach B geschickt wird. Das hat überhaupt nichts mit dem Parameter eine Methode zu tun. Wobei ich jetzt wieder unsicher bin ob du tatsächlich eine Methode meinst, oder das was du "Methode" nennst. Zitat:Können wir uns auf die Terminologie von oben einigen, oder was sollte ich ändern? -- -- 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 |
|||||
|
||||||
|
|
Impressum |
Datenschutzerklärung |
Netiquette |
Werbung |
Kontakt
Copyright © 1998-2024 by amiga-news.de - alle Rechte vorbehalten. |
|
