Comments 58
Спасибо! Интересная реализация
Красиво выглядит. Спасибо!
А как обстоит дело с русскими буквами?
А как обстоит дело с русскими буквами?
Поймал себя на мысли, что самое сложное в этом электронном табло — найти место для его непосредственного применения..)
Красиво, компактно. Главное — не есть столько ресурсов сколько оригинальная версия. осталось придумать куда это можно применить. ;)
UFO just landed and posted this here
Отличная статья, спасибо.
Есть одно маленькое замечание. При создании «светодиода» в Фотошопе, лучше включить привязку к пикселям, тогда изображение получится четче:
Есть одно маленькое замечание. При создании «светодиода» в Фотошопе, лучше включить привязку к пикселям, тогда изображение получится четче:
А зачем чётче? Это же лампочки светят, они и должны выглядеть немного размытыми по контуру. :)
Это уж как вам угодно :)
Я старался сделать больше похоже на оригинал. А так форма «лампочек» может быть любой.
Я старался сделать больше похоже на оригинал. А так форма «лампочек» может быть любой.
Изображение слева выглядит потеплее, это ж лампочки ;)
Мне изображение слева кажется размытым… Но я ни на чем не настаиваю.
Мне изображение слева кажется размытым… Но я ни на чем не настаиваю.
На вкус и цвет, как говорится, все фломастеры разные :)
На вкус и цвет, как говорится, все фломастеры разные :)
Если в горизонтальных точках (E-TABLO HORIZ. POINTS) поставить значение большее, чем ширина экрана, то электронное табло разъзжается.
Если же выставить, например, 100000 точек, то браузер просто повиснет (Opera, Firefox 3.5).
Если же выставить, например, 100000 точек, то браузер просто повиснет (Opera, Firefox 3.5).
А почему не миллион точек?
Вы просто посчитайте: если у вас 100000 в ширину, значит итоговое количество 800 000. Такое у вас получится количество элементов на странице. Любой современный браузер сойдет с ума от такого количества DOM узлов :)
Насчет больше чем ширина экрана, можно допились, например так:
Вы просто посчитайте: если у вас 100000 в ширину, значит итоговое количество 800 000. Такое у вас получится количество элементов на странице. Любой современный браузер сойдет с ума от такого количества DOM узлов :)
Насчет больше чем ширина экрана, можно допились, например так:
#e-tablo {
margin:0 auto;
overflow: hidden;
}
#e-tablo div {
…
width: 10000px;
}
поставил 10000 опера исправно проигрывала анимацию, загрузка проца 50%, памяти на процесс 130мб
Версия:
10.00 Beta
Сборка:
1601
Версия:
10.00 Beta
Сборка:
1601
Это прям какой то стресс-тест :)
На самом деле не думаю, что это имеет смысл, делать количество точек большее чем может уместиться в экран.
Опять же, цель статьи не показать как сделать самое крутое табло…
На самом деле не думаю, что это имеет смысл, делать количество точек большее чем может уместиться в экран.
Опять же, цель статьи не показать как сделать самое крутое табло…
ну это скорее тест движка браузера )
замечу что старый пример быстрее (cpu max 9%), но
ваш пример с количеством 10000 нормально работает,
а старый вешает браузер
замечу что старый пример быстрее (cpu max 9%), но
ваш пример с количеством 10000 нормально работает,
а старый вешает браузер
Весьма странно что быстрее. Возможно движок быстрее справляется со сменой классов, чем с перемещением DOM узлов (модификацией DOM). В случае с Оперой, это вполне возможно.
На 10000 работает нормально потому что делается всего 8 операций перемещения + 8 операций изменения класса. В первоначальном решении на каждом шаге меняется класс для 80 000 элементов.
На 10000 работает нормально потому что делается всего 8 операций перемещения + 8 операций изменения класса. В первоначальном решении на каждом шаге меняется класс для 80 000 элементов.
по ощущениям прожорливость увеличилась. Даже опера хватает 40% загрузке процессора чего не случалось с предыдущим (8-9% максимум). IE также и остался 50-60%
При увеличении ширины на 88 «лампочек» и выше (E-TABLO HORIZ. POINTS) увеличивается и высота, из за чего текст почти не читаем (смотрел в FF и Хроме)
в опере тоже, получается кракозябра.
Внес изменения как написал тут. Так что теперь то что не помещается просто обрезается.
Да, действительно гораздо быстрее работает теперь.
Еще неплохо было бы сделать, чтобы прокрутка прекращалась, если строка полностью влезает в ширину табло :)
Еще неплохо было бы сделать, чтобы прокрутка прекращалась, если строка полностью влезает в ширину табло :)
В смысле не начиналось движения? Можно перед установкой setInterval сделать проверку и если pipeline.length == tableWidth — 1 не начинать анимацию.
А так думаю, у каждого будут свои пожелания по улучшению. В статье я показал лишь подход, я специально старался сделать код более простым, чтобы было проще его понять. Что делать дальше — решать вам.
А так думаю, у каждого будут свои пожелания по улучшению. В статье я показал лишь подход, я специально старался сделать код более простым, чтобы было проще его понять. Что делать дальше — решать вам.
интересно конечно посмотреть реализацию, но где это можно вцепить в живом проекте ума не приложу :)
Ну вот смотрите:
а дальше в коде:
Раз уж взяли на себя миссию нести новые знания в массы, то будьте последовательны и описывайте все интересные моменты, а не только те, которые удобнее и проще описать.
Последнее время на Хабре появляется множество статей, которые либо дают, так скажем, не очень хорошие советы и примеры, либо же лишены практического смысла. [...] Но мы здесь не меряемся сами-знаете-чем, а делимся опытом, знаниями, новым.
а дальше в коде:
// это проще записать чем объяснить... кто не поймет, считайте это магией :) // копать в сторону битовых операций: здесь побитовое "или" и битовый сдвиг line = line | letters[letter][j * lineCount + i] << j;
Раз уж взяли на себя миссию нести новые знания в массы, то будьте последовательны и описывайте все интересные моменты, а не только те, которые удобнее и проще описать.
UFO just landed and posted this here
К сожалению, битовые операции довольно большая тема (конечно когда знаешь и понимаешь — маленькая), и так я бы ушел в сторону. По своему опыту знаю, что часто программисты не понимают суть битовых операций (даже матерые), не умеют их понимать и использовать, поэтому в двух словах не объяснишь и надо подробно описывать, с картинками, с примерами.
Потому не стал вдаваться в подробности, и указал направление в котором стоит искать, если кого заинтересует.
Потому не стал вдаваться в подробности, и указал направление в котором стоит искать, если кого заинтересует.
Заметил, что цифры не отображаются…
UFO just landed and posted this here
Я не в этом смысле, я имею в виду еще не поддерживаются, на ограничения я смотрел…
Вы можете добавить символы сами, если потребуется. Я думаю, что набор символов (таблицу символов) нужно подбирать в каждом отдельном случае. Универсальной таблицы не получится, мало ли кому какие символы потребуются. К примеру я добавил "!" и "%". При желании можно написать небольшой редактор для упрощения задачи.
Автору респект и уважуха за совершенствование истории. В будущем обязуюсь честно рассказывать о тонкостях своих поделок ;)
Бесполезные по большому счёту изменения.
Раскройте свою мысль.
Я по диагонали прочитал, но всё какая-то оптимизация по-мелочи. Там человек просто реализовал свою идею. Применений тоже кучу найти можно при желании. А ужимать массив, кому это надо?
Меня всегда удивляют коментаторы, которые делают критические замечания, прочитав по диагонали.
В статье не ужимается массив, а транформируется (конвертируется) для более удобного дальнешего использования. То что массив стал меньше в объеме, по сути побочный эффект.
Описаное в статье решение много проще (и в понимании и в реализации) нежели оригинальное. Но и даже это не основная цель статьи.
Если комментируете и голосуете, то удосужтесь прочесть статью — скорее всего ваше мнение изменится. Если читаете по диагонали, то не делайте ни того ни другого. Потому что неразобравшись Вы делаете неверные выводы.
В статье не ужимается массив, а транформируется (конвертируется) для более удобного дальнешего использования. То что массив стал меньше в объеме, по сути побочный эффект.
Описаное в статье решение много проще (и в понимании и в реализации) нежели оригинальное. Но и даже это не основная цель статьи.
Если комментируете и голосуете, то удосужтесь прочесть статью — скорее всего ваше мнение изменится. Если читаете по диагонали, то не делайте ни того ни другого. Потому что неразобравшись Вы делаете неверные выводы.
Прочитал статью, но мнение не изменилось. Пользы от такой оптимизации практической нет, просто как пример. Оптимизировать можно что угодно, но это делается уже под конкретные цели, а автор оригинальной статьи таких целей просто не ставил.
Очень жаль что Вы так и не увидили/не поняли основной цели статьи.
Насчет целей автора — лучше спросить у него, или же почитать комментарии к той статье.
Он тут оставил комментарий, так что думаю цель достигнута. Именно ради второго предложения она и была задумана.
Насчет целей автора — лучше спросить у него, или же почитать комментарии к той статье.
Он тут оставил комментарий, так что думаю цель достигнута. Именно ради второго предложения она и была задумана.
Ужимать массив в этом конкретном случае вполне оправдано. Экономия памяти компьютера. Однако, могут быть такие решения, когда в битовой маске могут встречаться не только 0 или 1. Например, для раскраски букв.
Вот такие статьи хочется видеть в веб-разработке )
В «Javascript: The Good Parts» Крокфорт описывал битовые операции в JS как очень медлительные, в отличии от Java, C (вроде как из-за отсутствия integer как такового парсеру постоянно приходится конвертить числа из float в int и обратно). И вообще это «Bad parts» ;)
Вопрос к знатокам :) оно вообще уместно для оптимизации?
Вопрос к знатокам :) оно вообще уместно для оптимизации?
JS вообще сам по себе медлительный по сравнению с Java и Cи. Не будем забывать что последние компилируемые, и имеют строгую типизацию.
Первый раз слышу что битовые операции являются «Bad parts». Все зависит от того как вы собираетесь их использовать. В данной статье, которая представлена в большей степени как пример, производится упаковка вектора нулей и единиц в число (байт) для более удобного использования. Можно было конечно использовать вместо числа (байта) массив размерностью 8 с нулями и единицами, но не думаю что это было как то быстрее. Замеров не делал, но склоняюсь к тому, что скорость в обоих случаях (битовые операции и массив) будет одинаковой, или все же меньше для битовых операций. Крокфорта не читал, но сомневаюсь что он делал сравнение скорости битовых операций и массивов?
В любом случае, на данной задаче не думаю что хоть как то будет заметно изменение скорости выбери вы другой метод кодирования столбца (массивом, или строкой, или еще как) так как основной overhead в другом (смена класса, перемещение DOM-узлов, reflow, перерисовка).
Первый раз слышу что битовые операции являются «Bad parts». Все зависит от того как вы собираетесь их использовать. В данной статье, которая представлена в большей степени как пример, производится упаковка вектора нулей и единиц в число (байт) для более удобного использования. Можно было конечно использовать вместо числа (байта) массив размерностью 8 с нулями и единицами, но не думаю что это было как то быстрее. Замеров не делал, но склоняюсь к тому, что скорость в обоих случаях (битовые операции и массив) будет одинаковой, или все же меньше для битовых операций. Крокфорта не читал, но сомневаюсь что он делал сравнение скорости битовых операций и массивов?
В любом случае, на данной задаче не думаю что хоть как то будет заметно изменение скорости выбери вы другой метод кодирования столбца (массивом, или строкой, или еще как) так как основной overhead в другом (смена класса, перемещение DOM-узлов, reflow, перерисовка).
Sign up to leave a comment.
Электронное табло 2 или с пользой для общества