На самом деле не все так хорошо как описано в статье, во первых compound let assigments все еще не оптимизируются (и возможно что-то еще, let менял на днях потому в нем уверен)
let s = 0;
for(let i = 0; i < 1000; i++) {
s += i;
}
console.log(s);
// то, что это деоптимизируется можно увидеть и в профайлере без всяких флагов
во вторых то, что код не вызывает деоптимизации и компилируется, еще не значит, что он будет работать быстро, так что для написания производительного кода все еще нужно будет держать в голове много информации о работе движка (тут к счастью все +- одинаково для все движков, хотя есть места на которых некоторые движки тупят и им приходится помогать уже отдельно, привет Сафари)
WebGL это низкоуровневый интерфейс для отрисовки точек, линий и треугольников, ни про какие контролы он не знает и знать не может, а библиотек которые рисуют контролы на WebGL достаточно, в том числе упомянутый рендер html gl. Есть еще интересный проект от мозиллы https://aframe.io/, но не думаю, что его стандартизируют.
Технология бесспорно полезная, но сама идея стара как мир. Как уже упоминалось выше можно рендерить контент порциями и просто считать высоту для принятия решения что нужно дорендерить/удалить.
По поводу доработки демки, тут проблема в том, что можно так скролльнуть что элемент не попадет в экран и событие не вызовется, с подсчетом высоты это решается легко, а вот с событиями — не все так просто.
Советы из анабиоза. Это всегда было плохим стилем, а теперь так вообще не актуально. Спецификация ES5 запрещает переопределять undefined. Для колекций лучше использовать Map или Set которые есть во всех актуальных версиях браузеров (и без проблем полифилятся массивами), а не насиловать браузеры вызывая деоптимизацию. Магии нет, есть спецификация и преобразование типов достаточно с ними разобраться и больше не смеяться с видео javascript WTF. Например массив с join не конвертирует пустые значения в пустую строку, а тупо их пропускает. Уже IE10 устаревший браузер, прекращайте поддерживать IE8 и всю эту китайщину. Если прямо нужно — лучше использовать shim.
Создавайте больше методов с небольшим количеством вложенных колбеков или используйте библиотеку асинк. Это не рекомендация промисы с асинк/евейт это здорово, но избежать ада можно было и без этого =)
for (var x=1, xSorted=''; x<=1000000; x++) — тут вы зачем проверяете число которое с 4 начинается? Если число х начинается с 4, то 3*x будет большей длины чем х и проверять этот случай смысла нет (даже такие случаи 4, 34, 334 и т.д.)
Да, это тяжело хотя и не невозможно. Если физики нет в игре — еще не факт, что ее нет в сборке, проверьте логи сборки. Но проблема конечно явно в другом, тут могут помочь такие танцы с бубном как удаление кеша эмскриптена, перестановка юнити, даунгрейд на предыдущие версии.
У нас как-то была ошибка которая появлялась исключительно на стейджингах, но не в дев версии — console.errorMessage is not a function, что решалось простым переопределением console.errorMessage = console.error, но я так и не понял почему она не проявлялась при разработке.
Если после танцев с бубном решите поковырять модуль — смотрите на общую структуру, скомпилированный асм из юнити практически всегда не читаем. Если это ошибка в лоадере — он в принципе читается даже в скомпилированом виде и его в любом случае лучше переписать иначе намучаетесь с багами сафари и прочими браузерными различиями.
Вы наверное грузите все одним скопом, нужны ассет бандлы, оптимизация ресурсов (сжатие и выпиливание все чего можно и нельзя) и жесткий контроль над памятью (не используете ресурс — выгрузили). В целом весь деплой в юнити заключается в нажатии кнопки, что круто, но у вас и контроля будет столько же, а захотите больше — прийдется страдать и лезть в скомпилированый жс+асмжс код.
Сразу советую переписать их загрузчик на свой собственный и проверить не делают ли они оптимизацию float32 на лету (делали вплоть до версии 5.4, сейчас не уверен), если делают — сделать ее сразу после компиляции, а не в рантайме, сейчас все достойные браузеры понимают Math.fround.
Общие рекомендации — если это не критично постарайтесь выпилить физику, она подло тянется со всякими колайдерами риджит бади и прочими безобидными на вид объектами.
Выпиливайте все сторонние библиотеки от которых вы зависите не очень жестко.
UI лучше делать средствами html+css давая обратную связь в игру с помощью жс.
Очень важно правильно подобрать формат текстур и настроить сжатие, иначе размер ресурсов будет слишком уж большой, а нужно рассчитывать максимум на 512 Мб размера кучи и не более того же по ресурсам (лучше 256 кучи и до 50 Мб ресурсов).
Минимизируйте колличество шейдеров — это заодно и видеопамять вам разгрузит.
В целом юнити собирает под вебжл весьма достойно, но лучше б они сделали открытой сборку без игровой логики — модели и шейдеры (они с этого собственно и начинали) и дали бы контроль к этим объектам в жс.
Такой фокус в целом возможен (отдельно экспорт моделей, отдельно компиляция шейдеров в жлсл), но это уже по сложнее чем одна кнопка и это явно не ваш случай ибо прийдется переписывать игровую логику.
Это даже не слухи, а заявление сотрудников Юнити. Они его не развивают уже несколько лет, и это правильно, он кроме фрустрации других чувств не вызывает.
Я про первое (понятно, что это работает только в ФФ, но в принципе и в других браузерах этот код оптимизируется лучше js).
Поддержку asm.js скорее всего уберут, когда все браузеры поддержат wasm.
А какой смысл убирать то, что уже добавлено. В ФФ — это отдельная прекомпиляция, а в других браузерах это ведь выполняется силами штатного компилятора, как это вообще можно убрать?
asm.js будет компилироваться браузером в wasm
А сейчас разве не так происходит? То есть не учитывая поддержку 64-разрядных целых разве wasm не просто бинарное представление asm?
но вообще его нет смысла тащить дальше, когда есть бинарный формат
Ну как сказать нет смысла — сейчас можно быстренько в asm критичные вещи завернуть и даже ничего не компилировать или на продакшн компилировать asmjs -> wasm. А если его уберут — прийдется на С писать и обязательно компилировать даже в стадии разработки.
В идеале было бы хорошо, чтоб asm развивался как один из языков которые компилируются в wasm. Опять же поддержка int64 в js совсем не помешает, эмуляция на int32 и правда медленная.
C → wasm работает плоховато, потому что поддержкой компиляторов пока что ещё не очень и занимаются
Ну не только по этому, рукописный код всегда аккуратнее сгенерированного, потому в случае asmjs -> wasm мы получим именно то, что написали, а вот c -> wasm иногда генерирует кучу ненужного мусора, нужно за этим следить. Но да, компиляторы и правда становятся лучше.
В целом asmjs сейчас очень помогает исправлять косяки в реализации браузерных API к примеру DataView и помогает писать критичные участки кода без предварительной компиляции. Очень хотелось бы, чтоб его развитие продолжилось и нововведения vm для wasm были портированы в asmjs и js.
во вторых то, что код не вызывает деоптимизации и компилируется, еще не значит, что он будет работать быстро, так что для написания производительного кода все еще нужно будет держать в голове много информации о работе движка (тут к счастью все +- одинаково для все движков, хотя есть места на которых некоторые движки тупят и им приходится помогать уже отдельно, привет Сафари)
По поводу доработки демки, тут проблема в том, что можно так скролльнуть что элемент не попадет в экран и событие не вызовется, с подсчетом высоты это решается легко, а вот с событиями — не все так просто.
Это все потому, что фф умеет асм прекомпилировать.
Похвастайтесть, интересно очень.
У нас как-то была ошибка которая появлялась исключительно на стейджингах, но не в дев версии — console.errorMessage is not a function, что решалось простым переопределением console.errorMessage = console.error, но я так и не понял почему она не проявлялась при разработке.
Если после танцев с бубном решите поковырять модуль — смотрите на общую структуру, скомпилированный асм из юнити практически всегда не читаем. Если это ошибка в лоадере — он в принципе читается даже в скомпилированом виде и его в любом случае лучше переписать иначе намучаетесь с багами сафари и прочими браузерными различиями.
Нет ничего невозможного, удачи =)
Сразу советую переписать их загрузчик на свой собственный и проверить не делают ли они оптимизацию float32 на лету (делали вплоть до версии 5.4, сейчас не уверен), если делают — сделать ее сразу после компиляции, а не в рантайме, сейчас все достойные браузеры понимают Math.fround.
Общие рекомендации — если это не критично постарайтесь выпилить физику, она подло тянется со всякими колайдерами риджит бади и прочими безобидными на вид объектами.
Выпиливайте все сторонние библиотеки от которых вы зависите не очень жестко.
UI лучше делать средствами html+css давая обратную связь в игру с помощью жс.
Очень важно правильно подобрать формат текстур и настроить сжатие, иначе размер ресурсов будет слишком уж большой, а нужно рассчитывать максимум на 512 Мб размера кучи и не более того же по ресурсам (лучше 256 кучи и до 50 Мб ресурсов).
Минимизируйте колличество шейдеров — это заодно и видеопамять вам разгрузит.
В целом юнити собирает под вебжл весьма достойно, но лучше б они сделали открытой сборку без игровой логики — модели и шейдеры (они с этого собственно и начинали) и дали бы контроль к этим объектам в жс.
Такой фокус в целом возможен (отдельно экспорт моделей, отдельно компиляция шейдеров в жлсл), но это уже по сложнее чем одна кнопка и это явно не ваш случай ибо прийдется переписывать игровую логику.
А какой смысл убирать то, что уже добавлено. В ФФ — это отдельная прекомпиляция, а в других браузерах это ведь выполняется силами штатного компилятора, как это вообще можно убрать?
А сейчас разве не так происходит? То есть не учитывая поддержку 64-разрядных целых разве wasm не просто бинарное представление asm?
Ну как сказать нет смысла — сейчас можно быстренько в asm критичные вещи завернуть и даже ничего не компилировать или на продакшн компилировать asmjs -> wasm. А если его уберут — прийдется на С писать и обязательно компилировать даже в стадии разработки.
В идеале было бы хорошо, чтоб asm развивался как один из языков которые компилируются в wasm. Опять же поддержка int64 в js совсем не помешает, эмуляция на int32 и правда медленная.
Ну не только по этому, рукописный код всегда аккуратнее сгенерированного, потому в случае asmjs -> wasm мы получим именно то, что написали, а вот c -> wasm иногда генерирует кучу ненужного мусора, нужно за этим следить. Но да, компиляторы и правда становятся лучше.
В целом asmjs сейчас очень помогает исправлять косяки в реализации браузерных API к примеру DataView и помогает писать критичные участки кода без предварительной компиляции. Очень хотелось бы, чтоб его развитие продолжилось и нововведения vm для wasm были портированы в asmjs и js.