как конвертировать svg в canvas?
 

наверно темой все сказано. поиски в интернете привели к canvaSVG, но все ссылки приводят на сайт с другой тематикой.
сам написал небольшой конвертер, но не устраивает его ограниченная функциональность. дописывать себе дороже, так сказать "зачем изобретать велосипед".
еще интересует вопрос: "а на сколько часто вы используете canvas или svg?"

да-да, правильно. зачем если есть flex

В принципе не понимаю, зачем нужен канвас, что, делать чтоль нечего?

Да и тем более, если когда-нибудь он будет востребован, то уж точно не раньше 2011 года - тогда примерно будут полностью вытеснены ИЕ6 и 7


Если по теме - придётся изобретать велосипед (хотя, по чему велосипед?), ибо это пока очень не распространённая технология

Например, чтобы делать вот такие интересные штуки:
http://chikuyonok.ru/u/demo/excavator.html
http://chikuyonok.ru/2009/08/webweb-howto/
Причем здесь IE? В нем вообще нет поддержки Canvas и врядли будет, им достаточно своих VML и Silverlite.

Спасибо, Octane. Очень помогло. Демки можно найти еще здесь http://www.canvasdemos.com/

Хотя может общими усилиями и повлияют на Microsoft :)

Canvas меня очень заинтересовал и заставил отказаться от IE в пользу Opera.
Во-первых, я всегда мечтал иметь возможность реально рисовать в HTML;
Во-вторых, сжатие PNG очень подходит для работы сайта без перегрузки страниц гораздо проще, чем JShttpRequest известный;
В-третьих, если посмотреть серъёзнее, то Canvas очень полезная вещь!

Допустим, мне необходимо быстро получить какой-то чертёж. Использование Си - это снова десяток Copy'n'Paste + отладка и компиляция. В таких случаях я отлично обходился SmallHTTP server с библиотекой PHP. На скорую руку писал алгоритм, затем в IE через localhost открывал и сохранял картинку.
Таким образом я иногда делал достаточно серъёзные чертежи.
Но недостаток в том, что требуется три инструмента: SmallHTTP server, Блокнот и браузер.

С помощью Canvas, который я изучаю вторую неделю, я очень просто могу заниматься своим делом уже в одном браузере Opera! Могу на ходу изменять параметры и видеть результат за доли секунды.
Я думаю, как коммерческая бизнес графика Canvas имеет свою сильную сторону. А всякие там Flash-анимации я никогда не понимал.
Масяна - это круто. Но писать кучу специфического Flash-скрипта, компилировать и запускать, используя многотонную студию - это не моё.
Я не дизайнер или вэб-мастер. Просто иногда очень нужно повернуть снимок печатной платы на несколько градусов из-за неверного сканирования кем-то.
Раньше для этого я ставил 3D-Studio или Photoshop, хотя толком не пользуюсь ими.
А теперь: Canvas и всех делов-то!

Мсье знает толк в извращениях.

Как это связано?

Для чертежей автокад придумали.

Для такого ImageMagik уж хотя бы.

Как это как связано!?:blink:
Сжимаем Javascript… с помощью PNG и Canvas
Сжатие с использованием canvas и png
compression using canvas and png
Иными словами, огромные HTML-страницы, с доками например, можно сжать в PNG-картинку на стороне сервера, а со стороны клиента маленьким скриптом декодировать её и развернуть хоть в мегабайтовый документ.
Я раньше мучался с HttpRequest библиотекой и zlib, а теперь ничего подключать "лишнего" не надо:)

Это я знаю, причем здесь JsHttpRequest?

О скорости распаковки в данном методе умолчим.

Да, верно. Давайте может все на клиент перенесем -- вместо gzip пакованые скрипты в eval'e, данные в пнг + канвас... Бедный клиентский проц :(

jshttprequest - когда я писал движок своего ресурса на нём, то в ie он работал, а в opera у друга - нет. это было года 4 назад.

А сейчас canvas+png-сжатие я планирую для оффисного хранения своих отчётов или алгоритмов. ну предоставлять свои утилиты коллегам один раз, если им нужно там быстро что-то сделать.

Был случай недавно. Надо было у кое-кого геометрию CRT-монитора проверить. Самый быстрый способ: Paint - рисуем картинку 2x2 шашечкой и мостим ею стол. Разные цвета помогают быстро увидеть искажения экрана.
Так вот, тот перец у себя винт чистил и Paint стёр. Флоппака, сидюка и флэшки, как и сетевой - не было на том компе. Пришлось повозиться...
Хотя случай не имеет никакого отношения, но будь тогда Canvas под рукой, я бы в блокноте набросал скрипт и сделал бы ему шахматный битмап в два счёта!Да что вы суетитесь? Не сегодня, так завтра PNG распаковка будет аппаратная на уровне процессора;) Люди с вашим мышлением и создали проблему 2000 в фортране 40 лет назад! :D

Я вот последнее время нервничаю, когда какой-нибудь открытый в фоновой вкладке сайт по полной загружает 1,3 гигагерцевый проц новенького недешевого нетбука, вызывая подвисания всей системы :-E

Opera 4 года назад была гораздо глючнее сегодняшней. Вы что-то опять не ответили на вопрос: как Canvas+SVG может заменить JsHttpRequest?

Я давно ответил на вопрос! Но косвенно...
 

Запрашиваем картинку, PHP-сервер генерирует её из данных (html/txt/css) в PNG, а JS её после загрузки декодирует canvas.getImageData и применяет к странице (стили или посты чата/форума).
Такой "движок" я пытался давно писать, только из-за отсутствия доступа к отдельным пикселам я данные передавал в image.width и image.height, т.е. два байта. Правда скорость была хуже телеграфа XIX века.
Вот что я имел ввиду...

Отличная замена :)

А что с IE предлагаете делать? И что там со скоростью?

Paguo-86PK,
Вы злодей. Вы хотите юзать МОЙ проц для каких-то своих темных делишек :) Если сайт, построенный таким макаров, у меня будет тормозить (что вполне вероятно) -- хрен я на него зайду.

а что за проблема :-?

Да чито Вы говорите?
 

До лета этого года я сидел за Pentium-90MHz 48mb-RAM... В течении 8-ми лет сидел, так-как средств небыло на апгрейд.
И ничего. Даже с тюнера видео захватывал до 2-х часов и потом сжимал в MP-4 в течении 2-х суток. Терпеть не мог Opera, так-как запускалась 20 секунд и рисовала меню/панели прямо на глазах, а IE запускался всего 10 секунд...
Только летом повезло. Теперь видео сжимаю на лету с тюнера и тут сижу без тормозов в Opera.

А мой P-90 ща стоит сбоку с модемом, так-как сижу в сети через локалку через него. Там и Си, и файрволл, а даунлодер, и 3D-Studio, мануалы, Unreal IRC server, Proxy server и т.д...
А на новом - лишь Opera и OrCAD... Virtual Dub, так-как тюнер здесь разумнее гонять;)

А вы говорите про свой комп!:lol:
Вы наверное i286, i386, P-133 на картинках видели. А у меня они 5 лет назад инструментами были, даже спалил один из-за долбанного куллера:dance:

Paguo-86PK, что ты тут сопли пускаешь, я год сидел на 132MHz и 24 оператива, а потом еще пол года на 200MHz и 32 оператива, причем нашел его выброшенным и просто заменил видюху, там оказалось на жестком бехгалтерия какой-то фирмы :) И это в то время когда народ уже в CS наигрался.

Работать надо, а не сопли пускать, как тяжело на старой машинке.

Не на картинках я видел Корвет, Поиск, P-133. А что, Вы, собственно, пытаетесь мне доказать? Что я должен тратить ресурсы своей машины, только потому, что "почему бы и нет, черт побери?". Разговор был о том, что все Ваши сжатия, с последующей распаковкой на клиенте, как png, так и eval(function(p,a,c,k,e,d){..}), это говноидеи. Есть gzip. Как Вы собираетесь проводить все это на мобильных девайсах? Их владельцы уж точно не будут рады тупящему телефону/КПК.

А чем eval(function(p,a,c,k,e,d){..}) плох?

А чем он хорош? Насколько сжатие таким образом превосходит gzip? (Учитываем, что гзипить eval -- только увеличивать размер) Стоит ли выгода очень серьезной нагрузки на клиент?

packer хуже gzip, т.к. у него еще распаковщик в комплекте вынужден присутствовать. Ну и время на распаковку больше требуется, разумеется.

а как вообще этот gzip работает? Принцип в общих чертах расскажите кто-нибудь.

Kolyaj,
какой распаковщик? Это же eval на клиенте.
Riim,
http://ru.wikipedia.org/wiki/Gzip

А перед eval что?

Ты имеешь в виду серверный распаковщик aka unobfuscator? Так особо не актуально, если для себя, то есть несжатый вариант. А на клиенте-то никакого распаковщика нет...

UPD либо мы друг друга не поняли, и под распаковщиком имеется в виду преобразования кода, которые происходят в eval'e?

Kolyaj, ты говорил, что сделал штуку, которая собирает все скрипты в один, сжимает и отдает клиенту. Я тут думал на эту тему, скажи, насколько верно я мыслю:

1. обработчик собирает все js-файлы с какой-то папки, если он сам лежит в этой папке, то не нужно учить его, откуда ему все собирать.

2. неясно как определять порядок сборки файлов, можно создать массив в самом обработчике, но если я захочу добавить еще файл, то придется лезть в код и что-то менять, мне это совсем не нравится. Можно рядом положить xml и в нем определять порядок - не многим лучше. Еще вариант: в самих файлах первой строкой дописывать комментарий, в котором что-то вроде z-index-а. Вроде получше, только сами эти z-index-ы мне всегда не нравились, например, определил я порядок {5,6,7,8,9} , далее хочу добавить что-то между 6 и 7, придется искать всех у кого 7+ и увеличивать на 1 - это нудно очень.

3. обработчик собрал все что нужно в один файл, теперь нужно пропустить через какой-нибудь YUICompressor, но это долго, делать так при каждом запросе совсем нельзя, значит нужно где-то сохранить результат, например в all.min.js . При следующих запросах обработчик просто ищет all.min.js и отдает его клиенту, важно время последнего изменения проставлять одно и тоже (такое же как у all.min.js), что бы браузер тоже кэшировал.

4. изменил я какой-нибудь файл, как объяснить обработчику, что он должен заново сгенерировать all.min.js , простейший вариант вручную удалять all.min.js , но желательно обойтись без "вручную". Можно просматривать все js-файлы и если есть такой, у которого дата изменения позже чем у all.min.js , то обновлять all.min.js . Опять же медленно получится, но как лучше я не знаю.

5. не очень хорошо то, что all.min.js на виду лежит, куда бы его запрятать так, что бы совсем нигде не видеть? В asp хоть application есть, не ясно как быть с другими ЯП.

Пойдем с другой стороны: packer Дина Эдвардса сжимает скрипт в набор каких-то непонятных символов. Внимание вопрос: кто эти символы распаковывает обратно в рабочий JavaScript?

Не сжимает, сжималку мне все лень как-то писать, тем более, что есть YUICompressor.

2. Механизм работы препроцессора аналогичен механизму работы препроцессора языка C с некоторыми дополнениями: строка //#include_once "script.js" в любом файле заменяется на содержимое файла script.js, если в этом сеансе он еще не подключался.

4. Стандартные механизмы работы с кэшем. Например, каждый час/день/месяц обновлять содержимое.

5. Почему нехорошо?

Ну да, это я и имел в виду. Ниасилил, что его можно назвать распаковщиком :)

Ну это фактически самораспаковывающийся архив.

Да, согласен.

Я как раз и хочу сделать, что бы из обработчика YUICompressor использовался. Свой мне тоже лень писать.

вот это мне нравится, вроде встречался уже с подобными системами, но что-то здесь не сообразил.

тоже думал над этим, не очень хорошо может получиться: изменяется html и под него меняется скрипт, html у клиента сразу новый будет, а скрипт только через час/день/месяц обновится. Видно здесь придется все же вручную какие-то действия делать.

Ну, как-то на глаза он попадается, не то что бы так уж плохо, просто если бы его не было, то .... хуже бы не было.

http://habrahabr.ru/blogs/webdev/38771/ первая ссылка по запросу "теория кэша" в Яндексе. (Надо будет тоже почитать )))

Ну в какой-нибудь temp закинуть. Все равно он только на продакшне должен появляться.

Да мы почти коллеги!
 

Поиск???:blink:
Эх, он два года у меня был вторым серъёзным инструментом, после РАДИО-86РК, как видно по нику моему.
Жаль, что Орион-128 и Специалист я увидел лишь в эмуляторе: Отец купил платы, но не собрал:cray:
А вот Atari-XE и ST - там было где развернуться. Но не одолел. Дальше Бейсик-игр не ушёл с примитивными графикой и взрывами звука.

Так что не говорите:haha: Я калькуляторами набаловался подростком. Только ZX-Spectrum не любил: Прикладное ПО с большим трудом отыскивал и магнитофон измучал. А вот Радио-86РК - использовал до 98 года, пока Поиск не нашёл на рынке запчастей:dance:

лучше уж продолжение + скорее всего автору не хватает практики