Marek wrote:

> On Wed, 12 Aug 2015 17:50:50 +0200, Sebastian
> Biały<h...@p...onet.pl> wrote:
>> Na PC wszystkie 3 wiodące przeglądarki otwierają pluginy w wątku
> GUI co
>> zamraża mi je na kilka sekund jesli dysk jest zajety. Chrome na
> androida
>> przy wolnmym laczu (np. lejek 4kB/s) szarpie interfejsem bo coś
> czeka na
>> dane w wątku gui, inne przeglądarki mają gorzej. 99% aplikacji
> obrabia
>> dane w onkilkach co powoduje nieznośne lagi w GUI. Nikt nie
> deleguje
>> akcji od razu w tlo, tylko z lenistwa obrabia sie dane w tych
> onklikach.
>> Wliczając w to "wiodące aplikacje na androida" jak choćby liczenie
>> zajętości aplikacji w pamieci.
>> Oni wszyscy uzywają gui i watków ale byle jak.
>
> Jak sobie wyobrażasz synchronizacje gui->user gdy wszystko wrzucisz
> w tło? Przecież musi to być zsynchronizowane. Wynik zadania w tle w
> 99% ma być jakoś odzwierciedlony w zmianie stanu w gui (coś ma się
> "narsować").
> Najprostrzy sposób to progress bar (długa operacja) lub zamrożenie
> gui (krótka operacja). Co wybierasz? Wszędzie progress bary??
> Jeśli ani jedno i ani drugie to wtedy gui aplikacji będzie dla usera
> zachowywać się kompletnie niedetermistycznie, To pozbawienie usera
> sprzężenia zwrotnego z gui. User nie będzie wiedział czy już może coś
> kliknąć czy poczekać, czy w ogóle coś się dzieje.

a co za problem wyszarzyć guzik i włączyć go z powrotem po powricie z
tła?
Bo jak watek wisi to i tak uzytkownik nie ma pojęcia czy może coś
nacisnąć czy nie. Do tego czesto nie może wykonać żadnej innej akcji

--
mst <at> gazeta <.> pl
"-Mam lęk gruntu! -Chyba wysokości?
-Wiem co mówię. To grunt zabija!" T.Pratchett