Pytanie W iOS Safari zabrakło pamięci za pomocą "-webkit-transform"


http://jsfiddle.net/ES4xG/8/ rozbija większość urządzeń Retina.

iOS Safari "łatwo" zabrakło pamięci i ulega awarii podczas korzystania z niektórych -webkit-transform instrukcje. Takie podejście zapewnia imponującą grafikę, ale, szczególnie na wyświetlaczach Retina, wydaje się zużywać dużo pamięci i powodować awarie.

Powyższe demo pokazuje tekst wyświetlany 150 razy, który normalnie działałby w przeglądarce PC:

Rozmiar czcionki i liczba elementów jest przesadzona, powodując awarię. The -webkit-transform: translate3d(0,0,0) ma na celu wymuszenie na procesorze graficznym przyspieszonego rysowania każdego elementu.

W prawdziwej aplikacji używamy translateX,Y,Z, scale i inne, które wydają się być połączone z wykorzystaniem GPU w ten sam sposób. Obrazy i sprite'y są również używane, ale nie są bezpośrednio łączone z awariami.

Biorąc pod uwagę powyższy scenariusz:

1) Czy jest to błąd powodujący awarię Safari na iOS?

2) Podłączenie monitora pamięci instrumentu Apple Instruments, wirtualnej pamięci wspina się i wydaje się być przyczyną awarii. Co dokładnie używa tej pamięci?

3) Czy istnieje inne akcelerowane podejście GPU, które nie zużywa dużo pamięci?


20
2017-07-24 02:05


pochodzenie


Masz dużo niesamowicie dużego tekstu (1500px), który tworzy duże bufory na GPU - szczególnie na urządzeniach siatkówki. To z pewnością pochłonie dużo pamięci ... - i47
Tak, masz rację, zużycie pamięci jest problemem. Ale czy safari nie powinno się rozbić? Czyli ta pamięć rzeczywiście jest zużywana przez Gpu? Nie sugeruję, że rozmiar czcionki jest właściwy, to tylko uproszczenie problemu. Możesz mieć wiele elementów z mniejszymi czcionkami, które spowodują awarię w ten sam sposób. Twoje zdrowie. - Zero Distraction
Niezły kod. Rozbił się mój iPad 2 (bez siatkówki) na Google Chrome. To jednak dużo renderingu. - TheDoctor
Google Chrome obecnie korzysta z Safari pod maską, więc problem z renderowaniem jest zasadniczo taki sam. - Zero Distraction
Chyba pytanie brzmi: jaka jest twoja aplikacja? Czy istnieje inny sposób na uzyskanie tego, czego chcesz? - nielsbot


Odpowiedzi:


Zawiesza się, ponieważ wysokość wszystkich przyspieszanych sprzętowo elementów wynosi 257 250 piksli w twoim przykładzie. W moich testach okazało się, że mobilne safari może obsłużyć około 20 000 pikseli wysokości, zanim się zawiesi.

Akceleracja sprzętowa jest świetna, ale nie nadużywaj jej, wykorzystując ją do wszystkiego.

Aby pomóc w debugowaniu, będziesz musiał uruchomić Safari na komputerze Mac z terminalu za pomocą następujących kluczy:

$> export CA_COLOR_OPAQUE=1 
$> export CA_LOG_MEMORY_USAGE=1
$> /Applications/Safari.app/Contents/MacOS/Safari

CA_COLOR_OPAQUE pokazuje, które elementy są akcelerowane.CA_LOG_MEMORY_USAGE pokazuje nam ile pamięci jest używane do renderowania.

Aby uzyskać szczegółowe informacje, zapoznaj się z poniższymi linkami:


27
2017-07-30 14:49



Dzięki za odpowiedź. Rzeczywiście to użycie pamięci i czerwony / zielony kolor są bardzo przydatne. Coś, co robimy też, to MobileSafari podłączane do Instrumentów z OSX, uzyskujesz podobne wyniki i monitorujesz rzeczywistą pamięć iPada. Z łatwością dociera do 600 MB! Jednak niewiele można zrobić tylko przy użyciu pamięci. Wydaje się, że na iPadzie procesor GPU renderuje ogromne "bitmapy" w pamięci wirtualnej, więc gdy aktywność ekranu podskoczy, szczególnie w przypadku dużej ilości elementów, nie jest łatwo określić, co zajmuje dużo pamięci. Proces działa, ale wciąż szuka lepszego debugowania ... - Zero Distraction
Dzięki, też miałem problem z wysokością. Było to spowodowane dużym wcięciem tekstu w element. Lekcja dowiedziała się! Uważaj na wcięcia tekstowe i animacje. - Adam Tomat


spróbuj użyć tego na elemencie macierzystym przekształcanego elementu

-webkit-transform-style: preserve-3d;
-moz-transform-style: preserve-3d;
transform-style: preserve-3d;

i to dla lepszej wydajności dla ciebie transformowanego elementu

-webkit-backface-visibility: hidden;
-moz-backface-visibility: hidden;
backface-visibility: hidden;

7
2017-07-26 16:28



Dzięki za odpowiedź. Spojrzałem na te dwie właściwości, myślę, że pomogłyby w bardzo konkretnych przypadkach. Nadal szukam więcej wskazówek na temat tego, co dzieje się na GPU itp. - Zero Distraction
Dzięki, właśnie tego potrzebowałem! - Guy Sopher


Google Chrome ulega awarii kilka minut po uruchomieniu -webkit-transform Animacja JavaScript na tekst. Użyłem obu rotate() i rotateZ(), a szczególnie, gdy widoczny jest animowany tekst, użycie pamięci zgłoszone przez system zwiększyło się aż do Kurza twarz! występuje błąd.

Korzystanie z przeglądarki Google Chrome 31.0.1650.63, silnika Blink 537.36, w systemie Windows 7 w wersji 64-bitowej.

Przetestowano tę samą animację w Firefoksie 25.0.1 i nie było problemów.

Sądziłem nawet, że Tristan Engine (moja własna biblioteka JS) ma poważne wycieki pamięci, ale sprawdził się na wykresie Developer> Timeline i nie pokazuje żadnego wskazania.

Mający -webkit-transform na obrazie lub pustym DIV nie pokaże tego błędu.

Animowanie tego samego tekstu za pomocą prostych właściwości CSS2, takich jak left: lub top: nie pojawi się ten błąd.

Już złożyłem zgłoszenie błędu w Google. Zajęło mi to trzy godziny, aby dowiedzieć się, co jest nie tak.

Zgłoszenie błędu:  https://code.google.com/p/chromium/issues/detail?id=328245&thanks=328245&ts=1386906785


-2
2017-12-13 07:55



Cześć Marco, dzięki za twoją odpowiedź. Ale ten problem dotyczy tylko iOS Safari i jest uruchamiany przez renderowanie bez żadnego JavaScriptu. Jeśli masz jakieś ustalenia w iOS, daj mi znać. - Zero Distraction