unixman
Он не в счёт.
«I actually hate programming, but I love solving problems» © Rasmus Lerdorf, PHP's Creator
Отсутствует
Еще не факт, какая графика сильнее грузит проц - векторная или растровая.
векторная. по определению. ибо любой вектор для показа на экране - растеризуется.
задрали анимированные аватары у некоторых на десятки, а то и сотни кил
для локалки это - мелочи
Сама среда разработки (тогда еще 5-я) не тормозила вообще.
Мои флэшки на этом компе тоже летали (несмотря на достаточно навороченную анимацию).
как я уже сказал - тогда флеш ещё небыл куплен адобом. современный флеш изърядно тормозитс...
!
Отсутствует
Deleter
А лицензионное соглашение к плееру читал? В топку его.
Почитаю.
Но повторяю вопрос: кто-нибудь пытался общаться с производителем по этому вопросу? Мб они просто не задумывались над таким вариантом?
Встраиваются. И SVG встраивается, но пока не встраивается через img.
А оно надо? Нет конечно удобнее все вставлять одним тэгом, но тогда сам тэг img усложнится и не факт, что будет короче сегодняшнего варианта.
Опять же здесь писали, что работы в этом направлении (компактизация кода вставки) ведутся.
Dark-Demon
Еще не факт, какая графика сильнее грузит проц - векторная или растровая.
векторная. по определению. ибо любой вектор для показа на экране - растеризуется.
Мб я конечно чего-то не понимаю (если не понимаю, прошу кинуть в меня ссылкой с подробным описанием), но работает это так:
1. Для растра:
а. Проводится распаковка (копирование для битмапа) изображения в буфер
б. Буфер копируется в видеопамять
2. Для вектора:
а) Проводится распаковка программы (только если это сжатый формат - для несжатого этот пункт опускается)
б) Программа выполняется, формируя в буфере картинку (видимо это и есть растеризация)
в) Буфер копируется в видеопамять
У растра самый затратный этап - а).
У вектора - б) (трудоемкостью этапа а) можно пренебречь, так как размер файла обычно гораздо меньше - вектор с растровыми вставками не рассматриваем - иначе получаем промежуточный результат между 1. и 2.).
Я не вижу причин считать их не эквивалентными в среднем: если брать простое векторное изображение - тогда кол-во растеризаций будет небольшое и вектор точно потребует меньше ресурсов, так как растру в любом случае надо обрабатывать все изображение (даже если это просто однотонный черный квадрат); если же векторное изображение очень сложное - конечно оно может обрабатываться дольше, чем растр.
А если рассмотреть вопрос с точки зрения, что у современных процов мощь уже девать некуда, а подсистема памяти все так же не может догнать проц (причем это соотношение недогоняния более-менее одинаковое для разных систем), тот факт, что растру нужно больше памяти, вполне может склонить весы производительности не в его пользу.
Конечно это все очень умозрительно.
Просто не очень понятно, как сравнивать такие разные технологии
Но если очень хочется, можно и попробовать (если конечно это уже не сделано - но на вскидку не нашел).
Сразу приходят два варианта:
1. Делать векторные картинки различной сложности (разное кол-во объектов, применение/неприменение различных эффектов) и сравнивать их векторный оригинал с растровой растеризацией.
2. Брать растровые картинки и векторизовать их (но здесь важно подобрать качественный векторизатор - я вот ни одного не знаю, разве что для специфических случаев типа чертежей).
для локалки это - мелочи smile
Размер - только одна составляющая.
Когда у тебя на одной странице проигрывается с десяток таких анимашек, Лис вполне может начать подтормаживать
Вообще в правильных форумах просто вводят ограничение на размер - все таки это место для общения, а не выставка дизайнерского искусства
как я уже сказал - тогда флеш ещё небыл куплен адобом. современный флеш изърядно тормозитс...
То есть адоб его испортила?
Но все равно, как я понимаю даже по этой дискуссии, вектор в Лисе вполне востребован (тут писали про его использование в движке и для создания интерфейса самого Лиса).
Тогда почему это не развивается?
Когда я первый раз увидел SVG несколько лет назад, то подумал, что он просто вытеснит флэш, но похоже у них разные идеологии развития.
Или я чего-то не понимаю или одно из ...
Кстати, насчет загрузки флэшом проца: можно ведь двигаться и в обратном направлении
Флэша может оценивать производительность компьютера(косвенно, по скорости отрисовки) и менять соответственно нагруженность себя: менять частоту кадров (например пропуская их), качество сглаживания (то, что доступно из контекстного меню), не грузить часть графики или использовать разную по качеству графику
Или это можно сделать через меню настроек флэшки.
Конечно плохо, что это все не поддерживается производителем
Но такие вещи реализуются 1 раз
И растр такого делать уж точно не умеет
Проигрывание того же флэша можно поставить на паузу (редко соотв меню отключают), а вот с тем же анимированным гифом так не сделаешь (разве что глобально их выключить).
--- ---
Отсутствует
Forest
тот факт, что растру нужно больше памяти, вполне может склонить весы производительности не в его пользу
Так ли это на самом деле? При условии одинаковых размеров растра и вектора:
1. У них один и тот же размер буфера.
2. Растру не нужна лишняя оператива для просчета графики, а вектору нужна.
3. Растру не требуется хранить исходные данные для перерасчета (если не изменяется размер при показе), а вектору приходится.
Все это конечно обсуждаемо и можно приводить кучу противоположных примеров, однако давайте подумаем почему много народу в свое время (а может и сейчас) возмущались увеличению векторной графики в KDE4? Да потому что с векторными рисунками текущий KDE заметно притормаживает. Даже простая векторная картинка (без наворотов, в несколько линий) появляется обоиной на рабочем столе в первый раз заметно медленнее (потом кешируется в растровом виде). И это очень заметно на слабых машинах. У моего Celeron 1.1GHz эта разница составляет около двух секунд. Так что не только памяти вектор больше ест, но и требует больше остальных ресурсов.
Справедливости ради стоит отметить что Qt4 все же быстрее обрабатывает вектор.
...она старалась, чтобы я больше времени проводил в разных пионерлагерях и группах продлённого дня - кстати сказать, удивительную красоту последнего словосочетания я вижу только сейчас. (c) Виктор Пелевин
Отсутствует
Azathoth
1. У них один и тот же размер буфера.
С этим никто и не спорит.
2. Растру не нужна лишняя оператива для просчета графики, а вектору нужна.
Неужели?
И для чего конкретно она нужна вектору?
Если говорить про доп буфер - он в обоих случаях может использоваться, а может нет.
3. Растру не требуется хранить исходные данные для перерасчета (если не изменяется размер при показе), а вектору приходится.
Ну это уже вопрос оптимизации.
Масштабирование растра как, например, происходит?
однако давайте подумаем почему много народу в свое время (а может и сейчас) возмущались увеличению векторной графики в KDE4?
В свое время - это когда?
Так что не только памяти вектор больше ест, но и требует больше остальных ресурсов.
Я все таки настаиваю на формулировке со словом Может.
Так как контрпример такого утверждения делается элементарно - картинка, где кроме заливки фона одним цветом ничего больше нет.
Да и простые векторные картинки тоже сюда относятся.
У моего Celeron 1.1GHz эта разница составляет около двух секунд
А разница в результате есть?
Опять же процесс загрузки - достаточно экстремальный случай, когда загружаются практически все ресурсы компа.
Логичнее рассматривать обычную работу - в процессе при открывании новых окон в векторизированном варианте задержки больше, чем в растровом?
При работе с браузером вообще работа может идти только с одной векторной составляющей - самим сайтом.
Да и компы на месте не стоят - не использовать их возможности для увеличения удобства имхо не правильно.
Кроме того, здесь многие напирают на то, что флэш - это векторная графика - она тормознее - значит флэш тормознее.
Так векторная графика - только часть флэша (которая может быть очень легкой, если не использовать навороты).
Другая составляющая - возможность работать как полноценное приложение - уже напрямую связана с решаемыми задачами - а тут уж если задача тяжелая - мало что можно сделать, а если нет - то и проблемы нет
Я в общем-то и не предлагал засовывать вектор везде.
Например замена всех картинок на векторные в html странице далеко не факт, что будет оправдана (тот же размер html-я возрастет).
Скорее уж стоит написать такую страницу на флэше целиком - подозреваю, что во многих случаях результат будет лучше
--- ---
Отсутствует
Scarab
А как оптимизировал?
http://optipng.sourceforge.net/ Замечательная утилита, оптимизирует PNG, GIF, TIF в PNG, иногда результаты впечатляют, особенно при обработке гифа.
Отсутствует
Forest
2. Растру не нужна лишняя оператива для просчета графики, а вектору нужна.
Неужели?
И для чего конкретно она нужна вектору?
Если говорить про доп буфер - он в обоих случаях может использоваться, а может нет.
При чем тут дополнительный буфер? Я говорю про хранение промежуточных результатов при расчетах. Или Вы не программист и не знаете, что расчеты требуют промежуточных данных? А теперь представим что нам надо не только просчитать линии третьего порядка с хитрыми алгоритмами, а еще и залить сложные контуры. Зачастую сложной заливкой, типа градиента, да еще просчетом прозрачности. Я уже молчу про сглаживание линий, а там все гораздо сложнее чем сглаживание в растре.
А расход на парсинг векторного файла?
Отредактировано Azathoth (13-04-2007 14:39:05)
...она старалась, чтобы я больше времени проводил в разных пионерлагерях и группах продлённого дня - кстати сказать, удивительную красоту последнего словосочетания я вижу только сейчас. (c) Виктор Пелевин
Отсутствует
Scarab
Спасибо, буду иметь в виду эту утилитку, когда в следующий раз с графикой работать придется.
Gentoo Linux 2007-03-23 by XOR
Mozilla/5.0 (X11; U; Linux i686; ru; rv:1.9b3pre) Gecko/2008010104
Нас мало, но мы в кедах! ;)
Отсутствует
Azathoth
А теперь представим что нам надо не только просчитать линии третьего порядка с хитрыми алгоритмами, а еще и залить сложные контуры.
Как будто при обработке растра не используются сложные алгоритмы.
Просто я не придумал ничего лучшего, как назвать место для хранения промежуточных результатов тоже буфером.
В общем буфера бывают разные
А расход на парсинг векторного файла?
А файлы растра парсить не надо что ли?
Так спорить можно долго.
Надо проводить конкретные сравнения.
Либо придумывать конкретные тесты.
Либо сравнивать конкретные реализации (исходный код).
Конечно реализация преобразования векторного файла сложнее, чем растрового - там просто больше вариантов.
Но грубо говоря в растре один маленький алгоритм, но перемалывает каждый байт, а в векторе много больших алгоритмов, но применяемых строго при необходимости.
Мб я и недооцениваю сложность и частоту применения этих алгоритмов, но без конкретики (тестов и сравнений реализаций) спорить на эту тему считаю бессмысленным.
--- ---
Отсутствует
Forest
вообщето Azathoth прав абсолютно
небольшой по размеру pdf или кореловский файл весом в 20-30 кил способен повесить машину отправляясь на печать
просто потому что кривые пересчитываются с максимальным качеством
могу даже отогнать вам эту пдфку, там на заднем плане всего лишь полупрозрачные элементы, а вод ними простой фон
смысла делать их полупрозрачными особо то и не было, просто двигал один ползунок, дабы разнотоновости не было
интересно также то, что заменив векторный фон растовым в размере файла не проиграл(цветов мало, сжалось хорошо), но выросла скорость обработки в разы
это не просто аватара - это древний символ изгнания зла
Отсутствует
Punk_UnDead
Вообще-то пдф и корел - это издательские системы - там качество прежде всего и любой ценой.
То есть сравнение не очень удачное.
Тогда уж можно привести другой пример - 3д графика.
Тоже по сути своей вектор.
Причем существуют реализации, которые летают практически на всех существующих компах.
--- ---
Отсутствует
Я не вижу причин считать их не эквивалентными в среднем
распаковка изображения - потоковая операция, а растеризация - нет. в первом случае данные загружаются поблочно, обрабатываются и выгружаются, максимально задействуя кеш процессора. во втором же необходим рандомный доступ к итоговому растру.
а копирование в видеопамять - это практически мновенный процесс в котором ЦП даже и не учавствует
Когда я первый раз увидел SVG несколько лет назад, то подумал, что он просто вытеснит флэш, но похоже у них разные идеологии развития.
да просто вектор в вебе сейчас не очень-то и восстребован. он сейчас используется в основном для баннеров, "флешовых сайтов" и игрушек. есть, правда, интересный проект - fcmx.net. на svg такое лучше не делать, ибо поставит раком любую конфигурацию
!
Отсутствует
Forest
Как будто при обработке растра не используются сложные алгоритмы.
Для вывода на экран - не используются. Максимум используется масштабирование. Операция элементарна, даже со сглаживанием. Используются матричные операции. Не идет ни в какое сравнение с просчететом сплайна.
А файлы растра парсить не надо что ли?
Надо. Однако парсить их намного легче. Они как правило оптимизированы под потоковую распаковку.
...она старалась, чтобы я больше времени проводил в разных пионерлагерях и группах продлённого дня - кстати сказать, удивительную красоту последнего словосочетания я вижу только сейчас. (c) Виктор Пелевин
Отсутствует
У меня :::: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.9a4pre) Gecko/20070413 Minefield/3.0a4pre!
Добавлено Сбт 14 Апр 2007 13:03:07 :
А почему MineField иногда сбоит? Когда у меня была лиса версии 2 всё было нормально.
Юникс, Линукс, Mac OS X! Все против Хриндоус XP и Хриндоус Виста!
Как и linux'оиды, я тоже в кедах потому что пользуюсь BSD (Mac OS X) , а BSD создана на основе Unix'а , а Linux тоже создан на основе Unix'а
Отсутствует
unixman
Эту сборку поломали немного... за 12 число нормально работала... надо ждать следующую
F.I.R.E.F.O.X.: Fearsome, Intimidating, Redhead-Eating Fiend from the Ominous Xenopolis
Скиньтесь мне на новый MacBook Pro! Кто сколько может!
Отсутствует
красяво))
:::: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a4pre) Gecko/20070423 Minefield/3.0a4pre
показывает))
«I actually hate programming, but I love solving problems» © Rasmus Lerdorf, PHP's Creator
Отсутствует
И правильно пишут.
Потому как апнг был отклонен по вполне политическим мотивам - Мозилле показали, что стандарты создаются не браузерами, а стандартизирующими организациями.
Имхо, попытка протолкнуть АПНГ как стандарт не очень-то и отличается от создания эксклюзивных фич во время браузерных войн...разве что, хоть попытались легитимировать свою разработку.
А позиция Мозилла относительно МНГ вообще напоминает доводы капризного ребенка - "мы отказались от МНГ и все тут", а дальше идет какая-то ерунда о том, какие десятки байтов будет добавлять МНГ декодер и тра-ля-ля...(при том, что выкинув СОАП они освободили места как раз под МНГ декодер)
Вообще непонятно - юзеры просят и просят и просят и голсуют за баг - верните МНГ, но нет, Мозилла лучше разработает свой собственный формат, напишет декодер, включит его в транк, попытается навязать его Пинг-груп, где его вполне логично проваливают - из взаимной вредности
Безумие какое-то...
Свобода только тут - mozilla@conference.jabber.ru
Отсутствует
А то, что MNG не совместим с PNG, а APNG -- совместим, никого не волнует? Хотя бы статичная картинка видна будет... По моему одного этого преимущества достаточно, что бы забыть MNG, как дитя аборта.
Отсутствует