Я думаю светодиодов там гораздо больше. Навскидку там около 500 «пикселов» всего и в каждом 3 цвета. итого 1500 каналов управления. Обычно для таких штук используют DMX или Art.NET. Софта готового полно. Главная трудность сделать все максимально дешево.
и? может надо думать, а не тупо следовать рекомендациям? В данном случае ничего страшного не случится и не может случиться, а запись короче. Разве что какой-то нуб увидит это и станет везде его так использовать.
Впрочем автор недалеко ушел- там setTimeout вообще не нужен.
И нужно добавить init и вернуть из него { controlsDescendantBindings: true }. Кроме того, если в шаблоне будет:
<div> ... </div>
<div> ... </div>
Т.е. не один корневой элемент, то биндинги применятся только к первому.
Короче — надо читать статью из первого комментария.
А по поводу синхронизации. Полезно прочитать вот это. Обычно DirectShow сам выбирает источник синхронизации и как правило это устройство записи звука. Может в вашем случае он выбрал что-то другое. Стоит попробовать явно задать Audio Capture Filter в качестве SyncSource.
Я так понимаю делалось приложение для записи презентаций или лекций. Два года назад решал подобную задачу. И тоже на c# и DirectShow. Моя прога пишет два потока — камера, направленная на докладчика в SD, и сигнал, который идет на проектор в HD. Ну графы я и «руками» строить умею без кодогенерации, поскольку с DirectShow наигрался достаточно. Только я не пытался сразу сжимать потоки. Захват делал в формате DV (по-моему) а потом сделал перекодировщик в разные форматы. Перекодировщик на основе ffmpeg. Да и еще стояла задача компоновать оба потока в один файл, где картинка презентации занимает большую часть, а докладчик в маленьком окошке, чтобы можно было просто выложить на видеохостинг. Вот ffmpeg ее прекрасно решил, только помню долго искал сборку, которая умеет это делать(комбинировать кадры). Самому разбираться со сборкой ffmpeg под Windows не хотелось.
До сих пор использую ActiveScripting. Клиент — набор объектов управляемых через ActiveScripting, сервер на NodeJS. Клиенту уже лет 7, изначально общался с сервером по HTTP long polling, на сервере был PHP. Теперь на сервере NodeJS и общение идет через Socket.IO. Минимальными усилиями прикрутил в клиента поддержку WebSockets ну и пришлось сделать пару шимов чтоб Socket.IO-client работал. Так что вещь все еще годная. Да JS медленный, но у меня все, что требует скорости в нативных объектах. Впрочем, если бы писал клиента с нуля, наверно ActiveScripting уже не использовал бы.
Тут есть табличка по шатлу. Единственный многоразовый ЖРД для подобных целей. Там для основного двигателя указан ресурс 8 ч и 55 запусков(двигателя). Нашел еще отсылки на желание NASA сделать двигатель на 100 часов. Так что про 50 запусков я ближе ткнул пальцем.
Я так понимаю сделать жидкостный реактивный двигатель с большим ресурсом вполне реально. Там же нет движущихся частей, в отличие например от турбореактивных, которые на порядок сложнее. Т.е. по сути изнашиваться нечему, если не считать вспомогательные системы — гидравлику, компрессоры насосы, которые тоже вполне могут иметь приличный ресурс. Т.е. 5 запусков это пальцем в небо. Так же может быть и 50.
Ну там небольшой аппарат, который в космос не собирались запускать. У него 4 двигателя. Полезная нагрузка у того, что развилось бы их этого проекта, была бы судя по всему никакая.
Тут сравнительно большая первая ступень ракеты (тоже в космос по сути летать не будет). Двигатель один. Тут полезная нагрузка больше.
Ну и балансировка длинной трубы на одном мощном двигателе наверно посложнее балансировки «конуса» на четырех.
Статья без претензии на супер производительность. В большинстве случаев не надо никому копаться в дереве на 1500 узлов. Но если очень хочется можно прикрутить постепенную загрузку данных. Не обязательно рендерить все сразу.
Кроме того стоит попробовать подход использованный тут для таблиц. Говорят быстрее стандартных шаблонов в 10 раз. Я не пробовал и не вдавался. Я просто стараюсь не выводить сразу много данных.
eachне нужен — есть встроенная функция для этой задачи.Впрочем автор недалеко ушел- там setTimeout вообще не нужен.
И нужно добавить init и вернуть из него
{ controlsDescendantBindings: true }. Кроме того, если в шаблоне будет:Т.е. не один корневой элемент, то биндинги применятся только к первому.
Короче — надо читать статью из первого комментария.
Ах да есть и за 400 вариант. Но если .NET то лучше уж Kendo UI Complete for ASP.NET MVC за 999
Да и наврал, что я только в DV пишу. У меня там оказывается был сделан выбор, чем кодировать.
Тут сравнительно большая первая ступень ракеты (тоже в космос по сути летать не будет). Двигатель один. Тут полезная нагрузка больше.
Ну и балансировка длинной трубы на одном мощном двигателе наверно посложнее балансировки «конуса» на четырех.
Вот это работает.
IE10 — 1604
Chrome — 890
FF — 1300
А вот так:
IE10 — 8
Chrome — 6
FF — 6
Но это нечестный прием :-).
Кроме того стоит попробовать подход использованный тут для таблиц. Говорят быстрее стандартных шаблонов в 10 раз. Я не пробовал и не вдавался. Я просто стараюсь не выводить сразу много данных.