Укажите, что работает JS-функция с процессором (GIF-ролики не оживляют)
Показывать, что скрытие анимированных индикаторов /spinner gif - хороший способ показать пользователю, что их действие сработало, и что что-то происходит, пока они ждут завершения своего действия - например, если действие требует загрузки некоторых данных из сервера (ов) через AJAX.
Моя проблема:, если причиной замедления является процессор -интенсивная функция, зависает gif.
В большинстве браузеров GIF останавливает анимацию, когда процессор-голодная функция выполняет. Для пользователя это похоже на то, что что-то рухнуло или сработало, когда на самом деле оно работает.
Примечание. Кнопка "Это медленная" будет поддерживать процессор на некоторое время - около 10 секунд для меня, будет варьироваться в зависимости от характеристик ПК. Вы можете изменить, насколько это происходит с помощью "att-attps" attr в HTML.
![enter image description here]()
- Ожидание: При щелчке анимация запускается. Когда процесс будет завершен, текст изменится (мы обычно скроем индикатор, но пример будет более ясным, если мы оставим его вращением).
- Фактический результат: Анимация запускается, а затем зависает, пока процесс не завершится. Это создает впечатление, что что-то сломано (пока оно неожиданно не завершится неожиданно).
Есть ли способ указать, что процесс работает, который не замерзает, если JS удерживает процессор занятым? Если нет способа получить что-то анимированное, я прибегну к отображению тогда скрывая статическое текстовое сообщение с сообщением Loading...
или что-то подобное, но что-то анимированное выглядит намного активнее.
Если кто-то задается вопросом , почему я использую более интенсивно использующий код, а не просто устраняя проблему, оптимизируя: это очень сложный рендеринг. Код довольно эффективен, но то, что он делает, является сложным, поэтому он всегда будет требовать от процессора. Это занимает всего несколько секунд, но это достаточно долго, чтобы сорвать пользователя, и много исследований, которые долгое время показывают, что индикаторы хороши для UX.
Вторая связанная проблема с gif-прядильщиками для тяжелых функций процессора заключается в том, что счетчик фактически не показывается до тех пор, пока не будет запущен весь код в одном синхронном наборе, а это означает, что он обычно не будет отображать счетчик, пока не наступит время, чтобы скрыть прядильщик.
- Пример JSBIN.
- Одно простое исправление, которое я нашел здесь (используется в другом примере выше), - это обернуть все, указав индикатор в
setTimeout( function(){ ... },50);
с очень коротким интервалом, чтобы сделать его асинхронным. Это работает (см. Первый пример выше), но он не очень чистый - я уверен, что есть лучший подход.
Я уверен, что должен быть какой-то стандартный подход к индикаторам для интенсивной загрузки процессора, о которой я не знаю - или, может быть, нормально использовать текст Loading...
с setTimeout
? Мои поиски ничего не изменили. Я прочитал 6 или 7 вопросов о подобных проблемах, но все они оказываются не связанными.
Изменить Некоторые замечательные предложения в комментариях, вот несколько подробностей моей точной проблемы:
- Комплексный процесс включает обработку больших файлов данных JSON (как, например, операций манипулирования данными JS в памяти после загрузки файлов) и визуализации SVG (через Raphael.js) визуализации, включая сложную, детально масштабируемую карту мира, основанную на результаты обработки данных от JSON. Итак, некоторые из них требуют манипуляции с DOM, а некоторые нет.
- Мне, к сожалению, нужно поддерживать IE8 НО, если это необходимо. Я могу дать пользователям IE8/IE9 минимальный запасной текст, например
Loading...
, и дать всем что-то новое.
Ответы
Ответ 1
Современные браузеры теперь запускают анимацию CSS независимо от потока пользовательского интерфейса, если анимация реализована с использованием преобразования, а не путем изменения свойств. Статья об этом можно найти на http://www.phpied.com/css-animations-off-the-ui-thread/.
Например, некоторые из CSS-роликов в http://projects.lukehaas.me/css-loaders/ реализованы с помощью преобразований и не будут зависеть, когда поток пользовательского интерфейса занят (например, последний счетчик эта страница).
Ответ 2
У меня были подобные проблемы в прошлом. В конечном итоге они были исправлены путем оптимизации или выполнения работы в небольших патронах, реагирующих на действия пользователя. В вашем случае различные уровни масштабирования будут вызывать различные алгоритмы рендеринга. Вы обрабатывали бы только то, что может видеть пользователь (плюс, возможно, буферный запас).
Я считаю, что единственным простым обходным решением для вас, которое будет кросс-браузер, является использование setTimeout, чтобы дать нити ui возможность запускать. Запустите свою работу в совокупности операций и соедините их вместе, используя несколько вызовов setTimeout. Это замедлит общее время обработки, но пользователю, по крайней мере, будет предоставлена обратная связь. Очевидно, это предложение требует, чтобы ваша обработка была легко отсечена. Если это так, вы можете также рассмотреть возможность добавления индикатора выполнения для улучшения UX.