Abo
  1. Foren
  2. Kommentare
  3. Handy
  4. Alle Kommentare zum Artikel
  5. › iOS 11+1+2=23: Apple-Taschenrechner…

HA HA, Reactive, Non-blocking am A****

Anzeige
  1. Thema

Neues Thema Ansicht wechseln


  1. HA HA, Reactive, Non-blocking am A****

    Autor: devman 23.10.17 - 15:35

    Erinnert mich an schlecht programmierte HTML5 Seiten...

  2. Re: HA HA, Reactive, Non-blocking am A****

    Autor: Cystasy 23.10.17 - 16:06

    devman schrieb:
    --------------------------------------------------------------------------------
    > Erinnert mich an schlecht programmierte HTML5 Seiten...


    Nicht einmal HTML5 Seiten sind so schlecht das sie Tasteneingaben nicht schnell genug aufnehmen.. und falls doch hats ein Programmieranfänger gescripted der noch keinerlei Plan von JS hat.. selbst wenn du nen Taschenrechner mit HTML5 Canvas renderst usw.. so verkacken kannst es eigendlich kaum das sowas bei rauskommt..

  3. Re: HA HA, Reactive, Non-blocking am A****

    Autor: GnomeEu 23.10.17 - 20:15

    Naja es wird halt auf die Animation gewartet bis eine Eingabe wieder möglich ist. Ist halt typisch, wir haben 100% unit test Abdeckung, nur nicht in der gui wo's drauf ankäme.

  4. Re: HA HA, Reactive, Non-blocking am A****

    Autor: logged_in 23.10.17 - 20:26

    GnomeEu schrieb:
    --------------------------------------------------------------------------------
    > Naja es wird halt auf die Animation gewartet bis eine Eingabe wieder
    > möglich ist.

    Also das glaub ich Dir jetzt nicht. Die läuft doch in einem anderen Thread, höchstwahrscheinlich auf der GPU, und der Rechner an sich wird sich wohl nicht wirklich danach orientieren, ob die Animation zuende gelaufen ist. Das wäre so was von schwachsinnig so was zu programmieren, macht überhaupt keinen Sinn bei einem Taschenrechner.

  5. Re: HA HA, Reactive, Non-blocking am A****

    Autor: GnomeEu 23.10.17 - 20:35

    Doch mann, das haben mind 2 Heinis hier schon geschrieben...

  6. Re: HA HA, Reactive, Non-blocking am A****

    Autor: Cystasy 23.10.17 - 21:19

    GnomeEu schrieb:
    --------------------------------------------------------------------------------
    > Naja es wird halt auf die Animation gewartet bis eine Eingabe wieder
    > möglich ist.

    Einfach weil ichs als Javascript Entwickler nicht verstehe - wer macht sowas bescheuertes? Animation & Handling von Touches sollten NIEMALS voneinander abhängig sein (bzw aufeinander warten). Die Animation läuft im Render Loop beim drücken ab.. da muss man nicht drauf warten bis die Animation fertig ist für eine weitere eingabe.. das wäre totaler Schwachsinn von Entwicklungstechnischer Sicht.. niemand würde das so programmieren.. und falls doch.. sollte er gefeuert werden. Das ist totaler quatsch.



    2 mal bearbeitet, zuletzt am 23.10.17 21:21 durch Cystasy.

  7. Re: HA HA, Reactive, Non-blocking am A****

    Autor: Lord Gamma 23.10.17 - 21:26

    Cystasy schrieb:
    --------------------------------------------------------------------------------
    > Einfach weil ichs als Javascript Entwickler nicht verstehe - wer macht
    > sowas bescheuertes? Animation & Handling von Touches sollten NIEMALS
    > voneinander abhängig sein (bzw aufeinander warten). Die Animation läuft im
    > Render Loop beim drücken ab.. da muss man nicht drauf warten bis die
    > Animation fertig ist für eine weitere eingabe.. das wäre totaler
    > Schwachsinn von Entwicklungstechnischer Sicht.. niemand würde das so
    > programmieren.. und falls doch.. sollte er gefeuert werden. Das ist totaler
    > quatsch.

    In iOS nimmt man Animationen noch ernst. Da soll keine Animation übersprungen werden, sondern lieber eine Eingabe. ;-)

  8. Re: HA HA, Reactive, Non-blocking am A****

    Autor: lear 23.10.17 - 21:47

    Vermutlich niemand. Ich weiß es nicht, aber würde davon ausgehen, daß die Eingabe *absichhtlich* ignoriert wird, wenn sie während einer Transition erfolgt ist und eine aktuellere Eingabe vorliegt.
    Input compression bei Bewegungen/Gesten macht schon Sinn und Apple hat das auch nicht erfunden/exklusiv - nur sollte man das nicht bei dem Äquivalent von "Clicks" machen...

  9. Re: HA HA, Reactive, Non-blocking am A****

    Autor: Cystasy 23.10.17 - 23:15

    lear schrieb:
    --------------------------------------------------------------------------------
    > Vermutlich niemand. Ich weiß es nicht, aber würde davon ausgehen, daß die
    > Eingabe *absichhtlich* ignoriert wird, wenn sie während einer Transition
    > erfolgt ist und eine aktuellere Eingabe vorliegt.
    > Input compression bei Bewegungen/Gesten macht schon Sinn und Apple hat das
    > auch nicht erfunden/exklusiv - nur sollte man das nicht bei dem Äquivalent
    > von "Clicks" machen...

    Also bei ner HTML5 App würdest du en eventhandler init'n, das feuert dann automatisch bei jeder Aktion (zb nem touch) das jeweilige event an eine vordefinierte Funktion weiter die dann das Touch Event händeln kann.. wenn man das so macht, kann man sogar mehrere Animationen gleichzeitig ablaufen lassen und auch den Input regeln ohne Probleme..selbst wenn da mehrere Buttons gleichzeitig gedrückt werden gäb das kein Problem. Und in andern Programmier & Scriptsprachen geht das alles auch ohne Probleme. Daher fände ichs schräg wenn es wirklich ein Entwickler gäbe der das ganze so löst das es echt input lags gäbe wegen ner Animation^^

  10. Re: HA HA, Reactive, Non-blocking am A****

    Autor: lear 23.10.17 - 23:39

    Du denkst hier auf der falschen Abstraktionsebene. Das hat nichts mit mit einer "onclick" Implementierung zu tun.
    Das event wird lange vorher und absichtlich verworfen - und mit serieller Verarbeitung von input und rendering hat das ebenfalls nichts zu tun. Im Gegenteil.
    Das Problem (sofern das hier wirklich der Bug ist) ist, daß input compression hier nicht angebracht ist - das macht nur beim rumgewische Sinn, aber nicht beim rumtouchen. Bzw. bei Letzterem (käme als alternativer Bug in Frage) könnte der Input absichtlich während der Transition gesperrt sein. Macht sehr viel Sinn wenn das UI dynamisch ist (also ein click die Buttons durcheinanderwirbelt, der Nutzer also gar keine Ahnung hat, was er als nächstes trifft) aber natürlich nicht, wenn es statisch ist.

  11. Re: HA HA, Reactive, Non-blocking am A****

    Autor: Cystasy 24.10.17 - 01:08

    lear schrieb:
    --------------------------------------------------------------------------------
    > Du denkst hier auf der falschen Abstraktionsebene. Das hat nichts mit mit
    > einer "onclick" Implementierung zu tun.

    Mir ging es vielmehr darum wie man sowas implementieren würde / könnte - nicht darum wie Apple das implementiert hat. Bei einem simplen Taschenrechner macht das eben keinen Sinn was Apple da veranstaltet hat..

  12. Re: HA HA, Reactive, Non-blocking am A****

    Autor: Dungeon Master 24.10.17 - 03:49

    Sieht danach aus, als hat Apple den Touch Listener schlecht implementiert. Der liefert zwar zuverlässig Events an den Renderer Thread (GUI), verwirft aber einige dieser Events, die an den Main Thread (Rechner) gehen sollten.

  13. Re: HA HA, Reactive, Non-blocking am A****

    Autor: dice2k 24.10.17 - 07:50

    logged_in schrieb:

    > Also das glaub ich Dir jetzt nicht. Die läuft doch in einem anderen Thread,
    > höchstwahrscheinlich auf der GPU, und der Rechner an sich wird sich wohl
    > nicht wirklich danach orientieren, ob die Animation zuende gelaufen ist.
    > Das wäre so was von schwachsinnig so was zu programmieren, macht überhaupt
    > keinen Sinn bei einem Taschenrechner.

    Genau das passiert.
    Willkommen in iOS:
    http://blog.grio.com/2014/04/understanding-the-ios-main-thread.html



    1 mal bearbeitet, zuletzt am 24.10.17 07:50 durch dice2k.

  14. Re: HA HA, Reactive, Non-blocking am A****

    Autor: S-Talker 24.10.17 - 11:03

    dice2k schrieb:
    --------------------------------------------------------------------------------
    > logged_in schrieb:
    >
    > > Also das glaub ich Dir jetzt nicht. Die läuft doch in einem anderen
    > Thread,
    > > höchstwahrscheinlich auf der GPU, und der Rechner an sich wird sich wohl
    > > nicht wirklich danach orientieren, ob die Animation zuende gelaufen ist.
    > > Das wäre so was von schwachsinnig so was zu programmieren, macht
    > überhaupt
    > > keinen Sinn bei einem Taschenrechner.
    >
    > Genau das passiert.
    > Willkommen in iOS:
    > blog.grio.com

    Das ist nun wirklich keine iOS Spezialität. Alle GUI Frameworks, die ich kenne, lassen Zugriffe auf GUI Objekte nur aus dem GUI Thread zu, weil alles andere im Chaos enden würde. Das erklärt aber noch nicht, warum hier ein Event verloren geht - eigentlich landet es in einer Warteschlange und wird abgearbeitet, wenn die GUI nicht mehr blockiert ist. So ist es üblich und so steht es auch in dem verlinkten Artikel. Hier ist eher das Problem, dass der Button während der Animation scheinbar explizit deaktiviert ist.

  15. Re: HA HA, Reactive, Non-blocking am A****

    Autor: My1 24.10.17 - 11:10

    die warteschlange ist sicher nicht sinnfrei, jedoch ist es offenbar nöglich zahlen zu tippen, die sofort reagieren während der + button noch animiert wird, das genaue handling ist auf jedenfalls interessant

    Asperger inside(tm)

Neues Thema Ansicht wechseln


Um zu kommentieren, loggen Sie sich bitte ein oder registrieren Sie sich. Zum Login

Anzeige
Stellenmarkt
  1. GIGATRONIK Stuttgart GmbH, Stuttgart
  2. Wilken Neutrasoft GmbH, Greven bei Münster/Westfalen
  3. weil engineering gmbh, Müllheim
  4. Verve Consulting GmbH, Köln

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Hardware-Angebote
  1. 229,99€
  2. und Assassin´s Creed Origins gratis downloaden


Haben wir etwas übersehen?

E-Mail an news@golem.de


Smartphoneversicherungen im Überblick: Teuer und meistens überflüssig
Smartphoneversicherungen im Überblick
Teuer und meistens überflüssig
  1. Winphone 5.0 Trekstor will es nochmal mit Windows 10 Mobile versuchen
  2. Librem 5 Das freie Linux-Smartphone ist finanziert
  3. Aquaris-V- und U2-Reihe BQ stellt neue Smartphones ab 180 Euro vor

Erneuerbare Energien: Siemens leitet die neue Steinzeit ein
Erneuerbare Energien
Siemens leitet die neue Steinzeit ein
  1. Siemens und Schunk Akkufahrzeuge werden mit 600 bis 1.000 Kilowatt aufgeladen
  2. Parkplatz-Erkennung Bosch und Siemens scheitern mit Pilotprojekten

Cubesats: Startup steuert riesigen Satellitenschwarm von Berlin aus
Cubesats
Startup steuert riesigen Satellitenschwarm von Berlin aus
  1. Arkyd-6 Planetary Resources startet bald ein neues Weltraumteleskop
  2. SAEx Internet-Seekabel für Südatlantikinsel St. Helena
  3. Sputnik Piep, piep, kleiner Satellit

  1. SuperSignal: Vodafone Deutschland schaltet Smart-Cells ab
    SuperSignal
    Vodafone Deutschland schaltet Smart-Cells ab

    Nutzer können die von Vodafone zugelassenen Smart-Cells Supersignal nicht mehr betreiben. Zum Jahresende werden die Femtozellen technisch abgeschaltet. Wi-Fi Calling soll hier der Ersatz sein.

  2. Top Gun 3D: Mit VR-Headset kostenlos ins Kino
    Top Gun 3D
    Mit VR-Headset kostenlos ins Kino

    Oculus Rift oder ein anderes VR-Headset aufgesetzt - und ab ins virtuelle Kino: Zusammen mit Paramount Pictures zeigt ein Startup im Dezember 2017 kostenlos den Actionfilm Top Gun 3D.

  3. Übernahme: Marvell kauft Cavium für 6 Milliarden US-Dollar
    Übernahme
    Marvell kauft Cavium für 6 Milliarden US-Dollar

    Konkurrenz für AMD und Intel: Der Chiphersteller Marvell übernimmt Cavium und hat künftig Zugiff auf die ThunderX2 genannten ARM-Server-CPUs. Zudem sollen Synergien unter anderem bei Netzwerk- und Storage-Lösungen entstehen.


  1. 17:26

  2. 17:02

  3. 16:21

  4. 15:59

  5. 15:28

  6. 15:00

  7. 13:46

  8. 12:50