Comments 58
Иногда страшно смотреть как нагружают процессор, ради такой простой штуки. А потом удивляются, а что это у мобильных девайсов батарейка так быстро кончается.
Я конечно за прогресс и если выбирать делать прогресс бар так или на флеше, то лучше так. Но блин почему бы не нарисовать бы две картинки и не выводить их поверх друг друга?? Даже просто по размеру это будет меньше, чем ваш код (без сжатия правда). А если бы внедрили 9patch images — то и размер был бы меньше.
Я конечно за прогресс и если выбирать делать прогресс бар так или на флеше, то лучше так. Но блин почему бы не нарисовать бы две картинки и не выводить их поверх друг друга?? Даже просто по размеру это будет меньше, чем ваш код (без сжатия правда). А если бы внедрили 9patch images — то и размер был бы меньше.
с точки зрения морочиться, встраивая флеш в страницу и потом передавать ему параметры — верно — флеш тут как обуза, но в условиях чистого эксперимента (в обоих случаях используем только draw-функции) — синусы и арктангенсы явно затормозят проц и посадят батарею быстрее флеша (у которого давно присутствует методы типа drawRoundRectangle...).
Можно отрисовать в буфер, а потом оттуда рисовать две картинки. ProgressBar в LibCanvas так и делает.
Сомневаюсь, что тормозить будут синусы и арктангенсы, если они не вычисляются в цикле. (Я имею ввиду за один этап обновления прогресса).
На крайняк можно делать precompute перед «сборкой». Т.е. дописать в код таблицу значений.
Но вообще картинами будет быстрей. Тем более, там можно ограничиться вообще одной картинкой + css-slicing.
На крайняк можно делать precompute перед «сборкой». Т.е. дописать в код таблицу значений.
Но вообще картинами будет быстрей. Тем более, там можно ограничиться вообще одной картинкой + css-slicing.
согласен, с изображениями было бы быстрее, но для того чтобы поменять цвет/размер/другие параметры пришлось бы рисовать новые картинки, а здесь можно быстро поэкспериментировать с этим,
на самом деле можно даже такой прогресс-бар сделать с помощью html+css3, я это тоже попробовал, но разметка иногда ведёт себя неадекватно)
на самом деле можно даже такой прогресс-бар сделать с помощью html+css3, я это тоже попробовал, но разметка иногда ведёт себя неадекватно)
но для того чтобы поменять цвет/размер/другие параметры пришлось бы рисовать новые картинки, а здесь можно быстро поэкспериментировать с этим,
Ну и отрисовали бы, в чём проблема? ;)
Да нет никакой проблемы, просто в данном случае я экспериментировал с canvas)
Дык я в контексте Canvas и говорю. Отрисовывать все каждый раз — моветон.
Смотрите
Когда изменен стиль через
Каждый же ж кадр вызывается метод drawLine, который рендерит буфер на холст.
Смотрите
LibCanvas.Utils.ProgressBar:Когда изменен стиль через
setStyle вызывается preRender, который рендерит в буфер this.line прогрессбар. Это происходит только при изменении параметров.Каждый же ж кадр вызывается метод drawLine, который рендерит буфер на холст.
Охрененная штука. Давно искал, как это реализовать. Но вы тут мне помогли. Зачет!
Великолепно!
оно здорово конечно, но почему-то (скорее-всего оправданно), по быстродействию легче вывести пару картинок чем вычислять всякое и рисовать линии. не так давно пытался написать игру с как бы векторной графикой. и оказалось что картинка рисуется побыстрее 20-ти линий. хотя, правда я сильно не вникал — лыжи не едут или у меня не слава богу
Можно ещё, наверное, средствами CSS3 попробовать.
Да, я это тоже попробовал, но пока так и не получилось сделать правильное заполнение при ширине меньше радиуса, возможно из-за того что не очень хорошо знаю вёрстку
Неплохо, а можно ли на CSS3 сделать правый край не закруглённым? Без картинок
Эммм. Ес-сно, можно.
border-radius: 50% 0 0 50%;Я имел в виду чтобы он при этом скруглялся при дохождении до правого края, а в вашем случае не будет.
Можно поставить overflow: hidden для контейнера, тогда будут скругляться.
В фаерфоксе по крайней мере точно не будет
смотрите http://stackoverflow.com/questions/1280339/have-border-radius-cover-inner-divs
смотрите http://stackoverflow.com/questions/1280339/have-border-radius-cover-inner-divs
Через SVG не проще было?
а зачем напрягать процессор лишней ерундой?
если можно обойтись, в большей степени, css. Вот свёрстано на коленке
pastehtml.com/view/1d8jg4e.html
если еще сделать «тень» да цвета подобрать — выйдет не хуже, да и тормозить меньше будет…
если можно обойтись, в большей степени, css. Вот свёрстано на коленке
pastehtml.com/view/1d8jg4e.html
если еще сделать «тень» да цвета подобрать — выйдет не хуже, да и тормозить меньше будет…
Скоро будем использовать для этих целей спец. тег progress. Пока работает (визуально отображается) только в webkit, но стоит ждать, кода в 1050 раз меньше
pastehtml.com/view/1d8jlzi.html
pastehtml.com/view/1d8jlzi.html
Так часто вижу статьи на Хабре про canvas-progressbar. Сам такую писал)
Вместо «Your browser does not have support for canvas» лучше написать «Operation in progress…».
А в чем сложность, используя этот пример, добавить callback от какого-нибудь загрузчика?
Или вам лишь бы придраться?
Или вам лишь бы придраться?
Плавности бы непомешало. Слошком резко меняется положение прогресса, из-за создаётся неприятное ощущение.
А вообще, интересная это идея. И реализация понравилась.
А вообще, интересная это идея. И реализация понравилась.
да, со всем этим можно поиграться в параметрах setInterval и увеличении ширины на каждой итерации, мне казалось вполне плавным. Спасибо
Слушайте, но это ведь жесть. Я далек от веб разработки и разработки вообще, но чтобы сделать простой прогресс-бар надо столько кода написать! Определенно что-то не то с прогрессом…
Sign up to leave a comment.
Индикатор прогресса с помощью HTML5 Canvas