Халтурщики в графике - Пользовательский интерфейс: проектирование, usability

Это ответ на сообщение:
http://rsdn.ru/Forum/Message.aspx?mid=1406037&only=1Получилось длинно и в другом направлении, поэтому завожу отдельную тему.

Здравствуйте, Sinclair, Вы писали:

S>Знаешь, то новое, чего остро не хватает в соврменном UI — это нормальной, полноценной графики.

Ща будет "ацкий отжыг". Микрософт, лежать-бояться!

S>Попробую изложить свою точку зрения:
S>1. Принципиально важна векторная графика.
S>Это позволило бы эффективно использовать устройства вывода для самых разных разрешений.

Я даже больше скажу — почему разрешение мониторов остановилось на уровне 1600x1200 (массовое, конечно же — всякий Hi-End мы не берем)? Не по техническим причинам. А просто потому, что винда больше не тянет.
Но здесь все гораздо сложнее. При увеличении разрешения хочется увеличить размер шрифтов. А от этого в диалогах что-нибудь где-нибудь да отъедет. Из за чего? Из за хинтов. Точнее сказать, из за слишком агрессивных хинтов. Длина строки меняется скачками, а не плавно и при определенных условиях текст налезает на контролы. Надо либо приколачивать размер шрифта в пикселах гвоздями и таким образом, сразу делать оговорку — "при разрешениях более 120dpi вы ничего не разглядите". Либо делать значительный запас — что и сделано во всех виндовых диалогах и от этого они выглядят образцом уродливости в дизайне. Есть третий вариант — отказаться от агрессивных хинтов вообще. Это вполне возможно уже сейчас — откройте любой pdf в Акробате и меняйте Zoom по одному проценту. Никто никуда не отъезжает и общий вид полностью сохраняется — вплоть до мизерных размеров. Это от того, что хинты в Type I гораздо менее агрессивны. Но текст при этом выглядит чуть более размытым — это неизбежная плата (и небольшая, я считаю) за возможность свободного масштабирования. Более того, чем выше разрешение, тем хинты становятся все менее и менее важными и примерно при 300dpi они не нужны вообще. При этом сглаживание (anti-aliasing) все еще сохраняет актуальность, но не приводит к визуальной размытости. В этом тоже легко убедиться, если сделать Zoom в том же Acrobat в 300-400% и отодвинуться от монитора на соответствующее расстояние.
Фирма Microsoft подложила большую свинью в виде TrueType с их агрессивными и патентованными хинтами (а TrueType — это прежде всего байт-код хинтов и ничего более, все остальное — тривиально). Кстати сказать, патент на хинты TrueType принадлежит Apple, но сами они как-то не очень активно этим пользуются. TrueType стойко ассоциируется именно с Microsoft. Почему "свинью"? Да потому что это — профанация типографической идеи вообще.

Это они называют Times New Roman?! Да любого типографского дизайнера стошнит от такой пошлятины. Нет в шрифте "Times New Roman" таких зверских засечек. Ну нету! Это выглядит очень вульгарно и пошло. Вот нормальный Times New Roman:

Да, я знаю, что большинство людей предпочтет именно первый вариант. Почему? Потому что правильное начертание шрифта им пофигу. По причине дурного вкуса, насажденного фирмой Microsoft. Это не наезд на большинство людей, люди не виноваты, они — жертвы. Это — наезд на Microsoft. Точно так же, как со всякими петросянами и лолитами — почему все мои знакомые считают их образцом пошлятины, и тем не менее они столь популярны? По причине насаждения дурного вкуса ради сиюминутной прибыли. Людей целенаправленно и планомерно превращают в быдло. TrueType — это та же попса, тот же Петросян. Смотрите, что получается.
Ради визуальной четкости текста (для увеличения продаж), фирма Microsoft затормозила развитие графики на много лет. Ни один диалог не является свободно масштабируемым. В то же время, это вполне технически возможно даже сейчас — Адоба тому пример. Почему диалоги нельзя свободно масштабировать? Потому что тогда текст не будет столь четким. А раз нельзя масштабировать, значит высокое разрешение не имеет смысла! Кто-нибудь может себе представить винду с разрешением 8000x6000 на 19 дюймах? Я — нет. Но если преодолеть порог в 300dpi, то как раз и появится возможность свободно масштабировать безо всяких хинтов. Но этот порог не преодолевается по причине "покривения" всего на промежуточных разрешениях — 120, 150 dpi. Получается замкнутый круг, который и является основным тормозом. Я глубоко убежден в том, что для дальнейшего прогресса требуются прежде всего свободно масштабируемые формы и диалоги (ну и векторные пиктограммы, конечно же). Но для этого сейчас надо пожертвовать визуальной четкостью. Вот, например: http://antigrain.com/stuff/page_demo.exe — поменяйте размер окна, подвигайте скролл-бар справа (за красные "блямбы" тоже можно таскать), посмотрите, как ведут себя контролы — все остается полностью работоспособным.
Но текст выглядит размытым. Но если преодолеть этот стереотип TrueType (название-то какое издевательское), насажденный Microsoft, вот тогда и будет стимул для увеличения разрешения. Тогда и ClearType станет ненужным (это, кстати, тоже очередная профанация и я могу это доказать). А после 600dpi и anti-aliasing можно будет списать на помойку (что, кстати, резко увеличит производительность — в десятки раз). Но пока что такого стимула нет и не предвидится.

Остальные пункты — позже. Но вообще-то, это все тянет на целую статью. Да, очень спорную, но мне чем-то симпатична эта роль "диссидента-правдоруба"

. Ставьте минусы — я буду ими по-мазохистски гордиться

VlaD2, ау!

Здравствуйте, McSeem2, Вы писали:

M>Вот, например: http://antigrain.com/stuff/page_demo.exe — поменяйте размер окна, подвигайте скролл-бар справа (за красные "блямбы" тоже можно таскать), посмотрите, как ведут себя контролы — все остается полностью работоспособным.

Балдею от expanding scrollbars в page_demo.exe !

MS>Это ответ на сообщение:
MS>http://www.rsdn.ru/Users/Profile.aspx?uid=5743
Админы, поправьте пожалуйста ссылку на вот эту (не туда нажал)
http://www.rsdn.ru/Forum/Message.aspx?mid=1406037&only=1

Во-вторых, небольшое дополнение (ну как же себя не похвалить?)

http://antigrain.com/stuff/page_demo.exe

Если уменьшить размер, то с формой становится невозможно работать:

Что это за пятнышки там наляпаны?

Но если включить линзу (Lens), то диалог сразу становится работоспособным:

То есть, это не выпендреж и не "kinda-c001-stuff". Это тоже может быть реальной необходимостью.
Что для этого нужно? — векторная графика и тривиальные нелинейные преобразования.

Пиксельную графику надо постепенно начинать закапывать в могилу. Все, для чего она требуется — это отображение фо-то-гра-фий. Все! Больше ни для чего (формат djvu и вообще любые сканы — тоже является частными случаями фотографии).

Здравствуйте, McSeem2, Вы писали:

Гхм... Начнем с конца.
MS>Ставьте минусы — я буду ими по-мазохистски гордиться

MS>VlaD2, ау!

Ну я за него.

Макс, я очень ценю твой опыт и умения. Но у меня есть 2 глобальных возражения.

1 (по стилю). Он кажется мне неконструктивным. Микрософт — не враг, а обстоятельство. Враг — это тот, кто сознательно тебе вредит, и поэтому его нужно победить и уничтожить. Обстоятельство — это то, что "просто есть". Можно с ним смириться, можно с ним бороться, можно искать обходные пути. Единственное, что бессмысленно — поливать его руганью. Ему пофик, а реальные оппоненты теперь станут тебя убеждать, что "Микрософт хороший" вместо обсуждения по существу.

2 (по существу). Попробуй объяснить мне (не мне — Зверьку, а "мне" — некоторому среднестатистическому пользователю), зачем мне разрешение 6000х9000 (в условиях обычного монитора)? На графическом устройстве вывода (aka монитор) возможно вывести всего 2 типа информации — текст и графику. Размер выводимого текста ограничен снизу физическими (а не логическими) размерами монитора: даже если монитор способен отобразить текст высотой 1мм — кто станет его читать? А пользователи, много работающие с графикой (и которым реально нужны большие разрешения) — это уже отнюдь не "все пользователи", а достаточно ограниченное их количество.

Итого — что ты пытаешься предложить пользователям? Заплатить четкостью изображения за некоторую абстрактную "крутость"?

Здравствуйте, Зверёк Харьковский, Вы писали:

ЗХ>Макс, я очень ценю твой опыт и умения. Но у меня есть 2 глобальных возражения.

Возражения принимаются, оценка — тоже (типа "круто, но не согласен"). К слову, оценка "-" на РСДН является выражением несогласия (совершенно нормальное явление в дискуссии), в то время как большинство людей воспринимают ее как выражение неодобрения. Почему? — парадокс.

ЗХ>1 (по стилю). Он кажется мне неконструктивным. Микрософт — не враг, а обстоятельство. Враг — это тот, кто сознательно тебе вредит, и поэтому его нужно победить и уничтожить. Обстоятельство — это то, что "просто есть". Можно с ним смириться, можно с ним бороться, можно искать обходные пути. Единственное, что бессмысленно — поливать его руганью. Ему пофик, а реальные оппоненты теперь станут тебя убеждать, что "Микрософт хороший" вместо обсуждения по существу.

О! вот это очень интересная интерпретация. Microsoft как явление природы.

Как дождь, снег или стихийное бедствие.

Впрочем, так оно и есть.
На самом деле, ты в чем-то прав — у меня есть склонность к гиперболам из некого "духа противоречия". Ну, трудное детство, диссидентство, развалил комсомольскую организацию в свое время...

На самом деле, я хочу таким эмоциональным способом донести некую мысль — чем чревата эта самая внешняя гламурность Microsoft. А вот чем — тормозом. Все эти дот-неты с их требоавниями к гигабайтам и гигагерцам только подстегивают индустрию. А вот пиксельная графика — наоборот тормозит.

ЗХ>2 (по существу). Попробуй объяснить мне (не мне — Зверьку, а "мне" — некоторому среднестатистическому пользователю), зачем мне разрешение 6000х9000 (в условиях обычного монитора)? На графическом устройстве вывода (aka монитор) возможно вывести всего 2 типа информации — текст и графику. Размер выводимого текста ограничен снизу физическими (а не логическими) размерами монитора: даже если монитор способен отобразить текст высотой 1мм — кто станет его читать? А пользователи, много работающие с графикой (и которым реально нужны большие разрешения) — это уже отнюдь не "все пользователи", а достаточно ограниченное их количество.

Это не так просто как кажется. Вот скажи, много ли сейчас осталось матричных иголочных принтеров? Лазерники-струйники с их 600 или 1200 dpi давно победили. Почему? Потому что "так красивше". Экстраполируя, могу предположить (гипотетически), что если ты пару месяцев поработаешь с полноценной экранной графикой в 600dpi, ты будешь воспринимать современные мониторы 1280x1024 как "полный ацтой" и скажешь "что это за издевательство над зрением?!" Разве не так?

ЗХ>Итого — что ты пытаешься предложить пользователям? Заплатить четкостью изображения за некоторую абстрактную "крутость"?

Да ХЗ, на самом деле.

Я по жизни хочу сделать некий прорыв — изобрести источник ЩАСТЯ

(а кто этого не хочет?) И я нашел область, где у меня есть хоть и мизерный (ноль-ноль-ноль-ноль-один-какой-то-там-процент), но все-таки шанс внести свою лепту в общее развитие.

Здравствуйте, Зверёк Харьковский, Вы писали:

ЗХ>1 (по стилю). Он кажется мне неконструктивным. Микрософт — не враг, а обстоятельство. Враг — это тот, кто сознательно тебе вредит, и поэтому его нужно победить и уничтожить. Обстоятельство — это то, что "просто есть".

Можно, конечно, объявить компанию по предотвращению зимы, шаманить, нажравшись мухомора, бить в бубны, выкрикивать заклинания, но лучше все-таки шить шубы и покупать валенки...

(А. и Б. Стругацкие, "Улитка на склоне")

Здравствуйте, McSeem2, Вы писали:

MS>...развалил комсомольскую организацию в свое время...

Поделись

ЗХ>>2 (по существу). Попробуй объяснить мне (не мне — Зверьку, а "мне" — некоторому среднестатистическому пользователю), зачем мне разрешение 6000х9000 (в условиях обычного монитора)? На графическом устройстве вывода (aka монитор) возможно вывести всего 2 типа информации — текст и графику. Размер выводимого текста ограничен снизу физическими (а не логическими) размерами монитора: даже если монитор способен отобразить текст высотой 1мм — кто станет его читать? А пользователи, много работающие с графикой (и которым реально нужны большие разрешения) — это уже отнюдь не "все пользователи", а достаточно ограниченное их количество.

MS>Это не так просто как кажется. Вот скажи, много ли сейчас осталось матричных иголочных принтеров? Лазерники-струйники с их 600 или 1200 dpi давно победили. Почему? Потому что "так красивше". Экстраполируя, могу предположить (гипотетически), что если ты пару месяцев поработаешь с полноценной экранной графикой в 600dpi, ты будешь воспринимать современные мониторы 1280x1024 как "полный ацтой" и скажешь "что это за издевательство над зрением?!" Разве не так?

Мммм... Вот это интересный вопрос. Если продолжать аналогию с принтерами — на матричном можно было ткнуть пальцем и сказать "вот смотри, все в точках, текст читается плохо, фотографии вообще не различить; с этим надо бороться". А вот чем "огромные разрешения" будут лучше современных — не так очевидно.

К слову, у меня в этой дискуссии своя цель — я-то тоже хочу изобрести источник ЩАСТЯ, ага. И мой путь — изменение интерфейса, его логических элементов. Таким образом, я сейчас пытаюсь не "обломать тебя", а наоборот, понять, куда мне приложить усилия, чтобы твое ЩАСТЯ и мое ЩАСТЯ стали всеобщим. Вот так где-то. Так что давай думать, что мы можем выиграть от "крутых разрешений".

Здравствуйте, Зверёк Харьковский, Вы писали:

MS>>...развалил комсомольскую организацию в свое время...

ЗХ>Поделись

Эх... Было это давно, когда я после института, в 89 году работал на нашей кафедре. И случилось страшное — меня выбрали комсоргом. Наверное, ради прикола, потому как более разгильдяйского комсорга трудно было найти. Фактически, единственной обязанностью было собирать взносы. Один раз я это проделал и это показалось мне самой унизительной процедурой в жизни. Я составил эту ведомость и с чувством выполненного долга честно сдал все взносы в бюро. Два дня жЫзни было полностью потеряно, но я очень гордился собой, что мне удалось это проделать. А дальше произошло вот что. Комсомольская барышня, очень напоминающая Вяземскую из "Собачьего сердца" (и, кстати, тоже в кепке — как щас помню) сообщила мне, это все хорошо, но теперь еще надо пойти в бухгалтерию и собрать данные по всем сотрудникам о премиях и прочих дополнительных доходах. Посчитать взносы, причитающиеся с них и включить их на следующий месяц. Не моргнув глазом я сказал "хорошо" и... забил. Такое издевательство было выше моих сил. На протяжении где-то года я кормил завтраками это самое бюро, и наверное, попал бы в конце концов под раздачу, тем более, что на меня уже было заведено некое неофициальное дело со стороны партхозактива. Но зато люди с кафедры не видели лучшего комсорга в своей жизни и все как один меня поддерживали.

И через пару лет комсомол по всей стране приказал долго жить. Такие дела...

Хоть это и злостный офтопик, но надеюсь простят.

Мне очень понравилось недавнее высказывание Шендеровича. Хотя вообще-то фуфла у него тоже много, но вот с этим высказыванием я согласен на все сто (не обсуждать и не начинать флеймов! Это приказ!)

Для начала – экскурс в недалекое прошлое, в год восемьдесят девятый. Съезд народных депутатов. Академик Сахаров предлагает распустить СССР и заключить новый, на самом деле добровольный Федеративный договор. В этом случае, конечно, отвалилась бы Прибалтика, но Украина, Белоруссия, Казахстан и, с большой вероятностью, закавказские республики — договор бы подписали.

Партхозактив затопывает сахаровское предложение ногами и заулюлюкивает его. Академика сгоняют с трибуны. Через несколько дней он умирает. Еще через пару лет СССР идет вразнос явочным порядком; напоследок партхозактив устраивает нам ГКЧП — и единое пространство разлетается вдребезги, да так, что до сих пор не видно перспективы хоть какого-то реального объединения бывших союзных.

Что мы имеем в сухом остатке? А вот что. Антисоветчик Сахаров пытался сохранить единое экономическое и культурное пространство Советского Союза, а верные ленинцы общими усилиями расфигачили СССР в мелкую крошку.
[. . .]
Троечники, серые безнадежные троечники правят страной...

ЗХ>Мммм... Вот это интересный вопрос. Если продолжать аналогию с принтерами — на матричном можно было ткнуть пальцем и сказать "вот смотри, все в точках, текст читается плохо, фотографии вообще не различить; с этим надо бороться". А вот чем "огромные разрешения" будут лучше современных — не так очевидно.

ЗХ>К слову, у меня в этой дискуссии своя цель — я-то тоже хочу изобрести источник ЩАСТЯ, ага. И мой путь — изменение интерфейса, его логических элементов. Таким образом, я сейчас пытаюсь не "обломать тебя", а наоборот, понять, куда мне приложить усилия, чтобы твое ЩАСТЯ и мое ЩАСТЯ стали всеобщим. Вот так где-то. Так что давай думать, что мы можем выиграть от "крутых разрешений".

Конечно, это не столь очевидно. Приведу цитату из книжки про теорему Ферма.

Подобно многим своим коллегам, Кен Рибет считал, что доказательство гипотезы Таниямы–Шимуры совершило переворот в математике: «Важным психологическим отзвуком доказательства гипотезы Таниямы–Шимуры явилось то, что теперь математики стали смело браться за решение проблем, которые прежде казались им неприступными. Ныне картина полностью изменилась. Теперь известно, что все эллиптические кривые модулярны, и, когда вы доказываете какую-нибудь теорему для эллиптических кривых, вы тем самым доказываете теорему относительно модулярных форм, и наоборот. У вас появляется иное видение происходящего в математике, и мысль о том, что вам придется работать с модулярными формами пугает вас меньше, поскольку вы, по существу, работаете с эллиптическими кривыми. Когда прежде приходилось писать статью об эллиптических кривых, мы вместо того, чтобы открыто признать, что нам ничего не известно, делали предположение: "Пусть гипотеза Таниямы—Шимуры доказана", — и смотрели, какие следствия проистекают из этого. Теперь нам достоверно известно, что гипотеза Таниямы–Шимуры верна, и мы смело можем утверждать, что из этого следует.

С высокими разрешениями — аналогичная ситуация. Казалось бы, "ну и что это дает?" и "нафига нам нужен текст в 1мм высотой?" А дает это вот что. Когда нет необходимости рисовать линии ровно в 1 пиксел шириной (ну потому что почти не видно), можно рисовать кегли любого размера с сохранением визуальной четкости. Но самое главное — мы уже не привязаны к пикселам. Anti-aliasing — это конечно же хорошо, но в то же время, это плохо — для вертикальных и горизонтальных линий (которых много!). При свободном масштабировании в сегодняшних экранных разрешениях, линии либо скачут, либо размываются. Третьего не дано. Для текста это имеет очень серьезные последствия, поскольку координатная ошибка в строке накапливается и длина строки скачет очень сильно. А теперь представим, что нам не нужны хинты и текст любого размера выглядит четко, как на лазернике. И не только текст, но и все линии — и горизонтальные и вертикальные. Что это означает? А то, что мы можем себе позволить масштабировать окна как нам угодно со всем их содержимым! И при этом, при разработке этого окна/диалога/etc нам не требуется закладываться на то, что строка может "скакнуть". С точки зрения дизайнера это имеет огромные последствия — можно просто дизайнить, не заморачиваясь дурацкими вопросами, типа "а как это будет работать на 120dpi?".
Самые серьезные изменения произойдут в веб-дизайне. Как только страницу со всем ее содержимым можно будет произвольно масштабировать с точным сохранением вида и четким текстом, такая профессия, как веб-дизайнер отпадет как ненужный "атрофизм". Останутся просто профессии дизайнеров и верстальщиков. Не надо будет заморачиваться на тему автопереносов текста (text flow) — как было задумано, так и увидит любой человек на любом компе или даже PDA. Так что рубеж в 300 dpi — это очень важная веха в истории и надо к ней стремиться вместо того, чтобы тормозить всякими "трутайпами". А самое главное — HTML можно будет выкинуть на свалку. Вместо него будут простые графические инструкции, отображающиеся идентично на любом мониторе и любом принтере.

"Во какой бред! Во куда заносит!" (Убить Дракона)...

Удивительным образом тема выступления совпала со вчерашней статьей Typography and the User Interface, в Cooper Newsletter :]
http://www.cooper.com/content/insights/newsletters/2005_issue01/Typography_and_the_user_interface.asp

Здравствуйте, McSeem2, Вы писали:

MS>Ставьте минусы — я буду ими по-мазохистски гордиться

Поставил. Несогласен.

Уважаемый, McSeem2.
Насчет шрифтов. Я возмущенный пользователь Adobe Acrobat Viewer. И проблема отнюдь не в стандартном PC. Проблема в КПК, в которых экран маленький по определению. Ну очень трудно там читать pdf'ы. И увеличишь шрифты — текста мало, и уменьшишь — не видно ни фига, размывает. Это наиболее кардинальный способ показать ублюдочность этой идеи со шрифтами. Маленькие экраны не просто не пропали, их количество только увеличивается. И четкость для них — важный показатель качества. Это насчет авторесайза шрифтов.
To вам и To Sinclair
Насчет DPI и скорости. Все о себе думаете. А о производителях подумайте. Когда вы пишете в памяти цикл на милион степов вы начинаете думать, а как бы это оптимизировать. Потому как память менее оптимизированная вещь чем мысли программиста. Подобное будет тормозить. Но почему вы в уверенности, что в видеокарте все значительно лучше? 6000x6000 dpi-круто. Над каким объемом памяти надо поработать видеокарте при смене картинки?
Насчет векторной графики. В принципе, векторная графика появилась еще в незапамятные времена. Еще с первыми SVGA картами появились ускорители 2D. Хотя бы line операция поддерживалась. А сейчас поддерживаются и True type шрифты и много чего. И практически во всех картах. Так что здесь вы опоздали. Но возьмем к примеру иконку. Она пиксельная. Это набор пикселей который нельзя scaleить. Иначе ты получишь совершенно другую картинку. Как векторная — она неинтересна, потому как объем команд в большинстве случаев, значительно больше количество пикселей.
Относительное позиционирование.
Чудная вещь. Но только как дополнительная. Возьмем к примеру ту же иконку, которую в принципе нельзя
ресазить. То есть все можно резайзить, а вот иконку нельзя. Можно даже говорить и не о иконка, а просто о маленьких картинках. Ну хоть убей — нельзя, а все можно. В результате получается что на ресайзе диалога получается бардак. В принципе подобное уже есть в WWW. Сейчас все больше сайтов появляется которые вообще не поддерживают ресайз. Если поискать по сети, то у юзабелистов отношение к этому ох какое неоднозначное. И поскольку и я делал дизайн сайтов и ресайз диалогов, я их понимаю. Бардак делается легко. Но лечится трудно. Поэтому абсолютное позиционирование, и голова чтобы контролы не вылезали за пределы предназначенной для них области и не превышали число 7 — для меня важнее.

Я не защищаю Microsoft. Я защищаю себя. Мои программы должны быть не сильно красивы, они должны быть функциональны, удобны и полезны. А красоту оставим художникам. Ради нее я биться не намерен.

С уважением, GLeb.

M>>Вот, например: http://antigrain.com/stuff/page_demo.exe — поменяйте размер окна, подвигайте скролл-бар справа (за красные "блямбы" тоже можно таскать), посмотрите, как ведут себя контролы — все остается полностью работоспособным.

K>Балдею от expanding scrollbars в page_demo.exe !

Вообще балдею от демок, которыми McSeem2 нас изредка балует.

*Текут слюнки*

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

Здравствуйте, GlebZ, Вы писали:

GZ>Насчет шрифтов. Я возмущенный пользователь Adobe Acrobat Viewer. И проблема отнюдь не в стандартном PC. GZ>Насчет DPI и скорости. Все о себе думаете. А о производителях подумайте. Когда вы пишете в памяти цикл на GZ>Насчет векторной графики. В принципе, векторная графика появилась еще в незапамятные времена. Еще с первыми
GZ>Я не защищаю Microsoft. Я защищаю себя. Мои программы должны быть не сильно красивы, они должны быть функциональны, удобны и полезны. А красоту оставим художникам. Ради нее я биться не намерен.

КПК и мобилы — это замечательно. Там самое место пиксельной графики. Но на десктопах ей делать больше нечего. Те же иконки будут делать в векторе — только и всего. Давно пора забыть при пикселы и мерять все в миллиметрах. И рисовать в веекторе. Да, я серьезно.

Хотя это не отменяет необходимость дизайнеров и верстальщиков — в полиграфии, скажем, где пикселов не было никогда, они вполне востребованиы

Здравствуйте, WinterMute, Вы писали:

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

HTML под с таким подходом вполне сочетается. Просто надо забыть, что размеры задаются как-то еще, кроме как в дюймах/миллиметрах.

Кстати, Flash давно именно так и живет.

Здравствуйте, mihoshi, Вы писали:

M>КПК и мобилы — это замечательно. Там самое место пиксельной графики. Но на десктопах ей делать больше нечего. Те же иконки будут делать в векторе — только и всего. Давно пора забыть при пикселы и мерять все в миллиметрах. И рисовать в веекторе. Да, я серьезно.
Ты сначало попробуй нарисовать в векторе иконку, можешь даже 32x32 а потом растяни на 64x64. Тогда и посмотрим.

С уважением, Gleb.

Здравствуйте, GlebZ, Вы писали:

M>>КПК и мобилы — это замечательно. Там самое место пиксельной графики. Но на десктопах ей делать больше нечего. Те же иконки будут делать в векторе — только и всего. Давно пора забыть при пикселы и мерять все в миллиметрах. И рисовать в веекторе. Да, я серьезно.
GZ>Ты сначало попробуй нарисовать в векторе иконку, можешь даже 32x32 а потом растяни на 64x64. Тогда и посмотрим.

Не совсем понял, что значит "нарисовать в векторе в 32x32"? Какое отношение имеет разрешение к векторным изображениям?

Здравствуйте, mihoshi, Вы писали:

M>Здравствуйте, WinterMute, Вы писали:

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

M>HTML под с таким подходом вполне сочетается. Просто надо забыть, что размеры задаются как-то еще, кроме как в дюймах/миллиметрах.

M>Кстати, Flash давно именно так и живет.

Понятно что сочетается, но точное позиционирование текста для HTML не обязательно.

Здравствуйте, Зверёк Харьковский, Вы писали:

ЗХ>2 (по существу). Попробуй объяснить мне (не мне — Зверьку, а "мне" — некоторому среднестатистическому пользователю), зачем мне разрешение 6000х9000 (в условиях обычного монитора)? На графическом устройстве вывода (aka монитор) возможно вывести всего 2 типа информации — текст и графику. Размер выводимого текста ограничен снизу физическими (а не логическими) размерами монитора: даже если монитор способен отобразить текст высотой 1мм — кто станет его читать? А пользователи, много работающие с графикой (и которым реально нужны большие разрешения) — это уже отнюдь не "все пользователи", а достаточно ограниченное их количество.

b]зачем[/b] мне разрешение 6000х9000: все примитивы будут отображаться из большего количества пикселей, а значит будут более чёткими, и следовательно более читаемыми.
Оно может я чего не понимаю, но после работы в Worde на своих 2-х мониторах с разрешением 1600x1200 на каждом (Large fonts) я так начинаю плеваться работая на ноутбуке в коммандировке, что соседи по гостинице бегут в администрацию.
ЗХ>даже если монитор способен отобразить текст высотой 1мм — кто станет его читать?
Никто, но текст размером 3мм станет значительно более читабелен.

Сделаю предсказание: через 7 лет в компьютерах перестанут использовать такое понятие как pixel при указании позиции на экране и размера элементов выводимых на дисплей! Будут использоваться мм и inch.
Вот только непонятно, что такое обычный монитор?

Здравствуйте, mihoshi, Вы писали:

M>Не совсем понял, что значит "нарисовать в векторе в 32x32"? Какое отношение имеет разрешение к векторным изображениям?
Именно. Попробуйте нарисовать картинку в векторе, которое будет нормально выглядеть на экране в области 32x32 пикселя.(если хочешь можешь персчитать экран 1280x1024 на милиметры для 19 дюймового экрана, смысл от этого не изменится). При скэйлинге будет выглядеть ну очень хреново. Поскольку каждый пиксель важен.

С уважением. Gleb.

Здравствуйте, GlebZ, Вы писали:

GZ>Именно. Попробуйте нарисовать картинку в векторе, которое будет нормально выглядеть на экране в области 32x32 пикселя.(если хочешь можешь персчитать экран 1280x1024 на милиметры для 19 дюймового экрана, смысл от этого не изменится). При скэйлинге будет выглядеть ну очень хреново. Поскольку каждый пиксель важен.

Что такое скейлинг? Почему скажем, звездочка (10 линий и градиентная заливка) должна в разрешении 64x64 выглядеть хуже, чем в 32x32 или 16x16? Или ты хотел предложить переводить векторное изображение в пиксельное, а потом его как-то растягивать? Так о том и речь, что это плохо и от этого надо уходить.

Здравствуйте, mihoshi, Вы писали:

M>Что такое скейлинг? Почему скажем, звездочка (10 линий и градиентная заливка) должна в разрешении 64x64 выглядеть хуже, чем в 32x32 или 16x16? Или ты хотел предложить переводить векторное изображение в пиксельное, а потом его как-то растягивать? Так о том и речь, что это плохо и от этого надо уходить.
Нет. Я хотел сказать что есть изображения, которые изначально растровые. Для которых не подходит векторное построение поскольку каждый пиксель является важной частью изображения. И поэтому они являются немасштабируемыми.

С уважением, Gleb.

Здравствуйте, softland, Вы писали:

S>но после работы в Worde на своих 2-х мониторах с разрешением 1600x1200 на каждом (Large fonts) я так начинаю плеваться работая на ноутбуке в коммандировке, что соседи по гостинице бегут в администрацию.

наконец-то понял, для чего нужны системы с двумя мониторами.
для работе в Word'е.

кстати, некоторые ноуты тоже имеют матрица на 1600х1200...

... << RSDN@Home 1.1.4 stable rev. 510>>

Здравствуйте, GlebZ, Вы писали:

GZ>Нет. Я хотел сказать что есть изображения, которые изначально растровые. Для которых не подходит векторное построение поскольку каждый пиксель является важной частью изображения. И поэтому они являются немасштабируемыми.

А почему "каждый пиксель является важной частью изображения"? Потому что разрешение мало. А почему разрешение не растет? Потому что "есть изображения, которые изначально растровые". Доколе мы будем ходить по кругу, как та ослепшая цирковая лошадь?

Да даже если "важен кажый пиксель", что с того? Есть даже такое искусство — пробегало как-то у Темы Лебедева. Это будет всего-навсего означать, что каждый пиксел может быть представлен прямоугольником 5x5, 7x7 и тэдэ.

Здравствуйте, McSeem2, Вы писали:

MS>А почему "каждый пиксель является важной частью изображения"? Потому что разрешение мало. А почему разрешение не растет? Потому что "есть изображения, которые изначально растровые". Доколе мы будем ходить по кругу, как та ослепшая цирковая лошадь?

Хорошо, может пересчитаем сколько будет на 19(ну допустим все крутые стали) мониторе памяти нужно для видео карты при режиме 300dpi?
Вас ребята не поймешь. Один говорит что хочу миллион символов, другой не возражает и говорит что хочу как минимум 300dpi на экране. Вы решите наконец, что вы хотите.

И письмо Путину(Бушу в зависимости от местопребывания).

MS>Да даже если "важен кажый пиксель", что с того? Есть даже такое искусство — пробегало как-то у Темы Лебедева. Это будет всего-навсего означать, что каждый пиксел может быть представлен прямоугольником 5x5, 7x7 и тэдэ.
1. Не отрывай от контекста вопрос. Я доказал что есть немасштабируемые изображения, и сказал что в таких условиях все эти относительные позиционирования летят к черту. И web это достаточно точно и наглядно показывает.
2. При разности мониторов, и следовательно разности dpi — такой рассчет не пойдет(он и не проходит на принтере, его всегда пересчитывать приходится).

С уважением, Gleb.

Здравствуйте, GlebZ, Вы писали:

GZ>Уважаемый, McSeem2.
GZ>Насчет шрифтов. Я возмущенный пользователь Adobe Acrobat Viewer. И проблема отнюдь не в стандартном PC. Проблема в КПК, в которых экран маленький по определению. Ну очень трудно там читать pdf'ы. И увеличишь шрифты — текста мало, и уменьшишь — не видно ни фига, размывает. Это наиболее кардинальный способ показать ублюдочность этой идеи со шрифтами. Маленькие экраны не просто не пропали, их количество только увеличивается. И четкость для них — важный показатель качества. Это насчет авторесайза шрифтов.

Я хотел лишь донести спорную мысль (даже для меня самого спорную), что наличие этой "гламурной четкости" само по себе тормозит развитие. Но не прямо, а косвенно — через невозможность свободно масштабировать текст.

GZ>To вам и To Sinclair
GZ>Насчет DPI и скорости. Все о себе думаете. А о производителях подумайте. Когда вы пишете в памяти цикл на милион степов вы начинаете думать, а как бы это оптимизировать. Потому как память менее оптимизированная вещь чем мысли программиста. Подобное будет тормозить. Но почему вы в уверенности, что в видеокарте все значительно лучше? 6000x6000 dpi-круто. Над каким объемом памяти надо поработать видеокарте при смене картинки?

Можно представить себе следующую схему (я, кстати говоря, еще лет 15 назад о такой мечтал). У нас есть светодиодная матрица 8000x6000. Под каждым пикселом находится маленький процессор и сотня байт памяти. Этот процессор умеет выполнять операцию AlphaBlend. В продвинутых случаях — остальные color compositing операции. Управляются эти процессоры строчно-столбцовым способом. Типа "открыть порт для передачи данных по всей строке номер 1343 — передать данные в колонку 2345". Таким образом мы засветили один пиксел. Закраска прямоугольника 1000x1000 при этом требует не миллион итераций, а всего-навсего 1000+1000. Anti-aliasing при таком разрешении нам не нужен и это сильно упрощает дело. Кроме того, каждый пиксел может сам себе быть альфа-маской и/или z-буфером.

GZ>Насчет векторной графики. В принципе, векторная графика появилась еще в незапамятные времена.

Где? Кроме Flash и SVG/XAML (которые появились в очень даже "запамятные" времена), какие векторные форматы и стандарты мы знаем? Есть OpenGL — но это API, а не формат данных.

GZ>Еще с первыми SVGA картами появились ускорители 2D. Хотя бы line операция поддерживалась. А сейчас поддерживаются и True type шрифты и много чего. И практически во всех картах. Так что здесь вы опоздали.

Об этом можно поподробнее? Про рисование линий банальным Брезенхемом я знаю. А вот про аппаратно ускоренный TrueType? Со сглаживанием? Честно сказать, я в этом плане человек дремучий и много чего не знаю. Но "аппаратно ускоренный TrueType" представляется мне чем-то из области легенд. Не верю! Не бывает такого. Ответь только на один простой вопрос — а в MemDC TrueType тоже рисуется аппаратно-ускоренно? А ведь это работает нисколько не медленнее! Но давай вынесем эту тему в мультимедию (или asm), я не исключаю, что здесь я могу облажаться в полный рост и был бы рад просвящению.

GZ>Но возьмем к примеру иконку. Она пиксельная. Это набор пикселей который нельзя scaleить. Иначе ты получишь совершенно другую картинку. Как векторная — она неинтересна, потому как объем команд в большинстве случаев, значительно больше количество пикселей.

Это категории их разных областей. Объем команд в растровом представлении пропорционален количеству пикселов. Объем команд в векторном представлении пропорционален сложности рисунка. В определенных условиях растровое представление выгоднее. Но, грубо говоря, с увеличением размеров объем растровой картинки растет как O(N^2), в то время как объем векторной остается O(1). Весь вопрос заключается в том, когда реально этот O(N^2) превысит O(1).

GZ>Я не защищаю Microsoft. Я защищаю себя. Мои программы должны быть не сильно красивы, они должны быть функциональны, удобны и полезны. А красоту оставим художникам. Ради нее я биться не намерен.

Глеб, я безусловно отношусь с уважением к твоей точке зрения. И очень ценю то время, что ты потратил на написание этого ответа. Моя цель в споре — не задавить кого-то своим "авторитетом", а самому понять что-то важное. Спасибо!

Здравствуйте, McSeem2, Вы писали:

MS>Вот скажи, много ли сейчас осталось матричных иголочных принтеров?
на самом деле у них тоже есть своя ниша, различные кассовые аппараты например...

silent RSDN@Home 1.2.0 alpha [618] Windows XP 5.1.2600.65536

GZ>Хорошо, может пересчитаем сколько будет на 19(ну допустим все крутые стали) мониторе памяти нужно для видео карты при режиме 300dpi?

Много будет. Как на цветном лазернике, даже еще больше.

GZ>Вас ребята не поймешь.

Не поймешь. Я сам себя иногда не понимаю. И даже вах-боюс-боюс...

Ну что же, помечтать-то можно!

GZ>Один говорит что хочу миллион символов, другой не возражает и говорит что хочу как минимум 300dpi на экране. Вы решите наконец, что вы хотите.

И письмо Путину(Бушу в зависимости от местопребывания).

Не надо воспринимать все настолько буквально. "миллион символов в секунду" — это лишь гипербола — такой литературный прием. Миллион символов в секунду если даже и реален, то не нужен!
К слову сказать, AGG рисует около 200000 символов в секунду при использовании растрового кэша на моем дремучем P4-1.9. Без какой либо HW-акселерации и без MMX/SSE. Чистый C++, скомпилированный на древнем MSVC 6.0. Этого вполне достаточно на практике. Векторный кэш (свободно масштабируемый!) дает около 35000 символов в секунду. Вот этого действительно маловато. На практике, необходимым и достаточным является полмиллиона символов в секунду.

MS>>Да даже если "важен кажый пиксель", что с того? Есть даже такое искусство — пробегало как-то у Темы Лебедева. Это будет всего-навсего означать, что каждый пиксел может быть представлен прямоугольником 5x5, 7x7 и тэдэ.
GZ>1. Не отрывай от контекста вопрос. Я доказал что есть немасштабируемые изображения, и сказал что в таких условиях все эти относительные позиционирования летят к черту. И web это достаточно точно и наглядно показывает.

А я доказываю, что немасштабируемых изображений не бывает. Если нам важна идея грубого пиксельного представления (в качестве некого арт-китча), пожалуйста — рисуй пикселы большими квадратами. При печати это именно так и происходит.

Здравствуйте, McSeem2, Вы писали:

GZ>>Насчет векторной графики. В принципе, векторная графика появилась еще в незапамятные времена.

MS>Где? Кроме Flash и SVG/XAML (которые появились в очень даже "запамятные" времена), какие векторные форматы и стандарты мы знаем? Есть OpenGL — но это API, а не формат данных.

PostScript, PDF

Здравствуйте, uw, Вы писали:

uw>PostScript, PDF

Кстати, да. В лазерниках — PS весьма популярен. Почему? Имеенно из за высокого разрешения. Гнать гигансткий битмап через всю сеть — это очень дорого, в то время, как несколько векторных команд решают все тоже самое. Но в экранной графике пока что далеко до PostScript. Не используется он. Flash — реально используется, PostScript — нет. Надо что-то простое, отображаемое везде и всюду. Как GIF, как PNG, только векторное. И чтоб можно было генерировать на лету, как HTML (с Flash-SWF такой номер не пройдет).

GZ>Иначе ты получишь совершенно другую картинку. Как векторная — она неинтересна, потому как объем команд в большинстве случаев, значительно больше количество пикселей.
Гм. Во-первых, в иконку входит много-много вариантов для глубины цвета и размера картинки. Во-вторых, поддержка дополнительных размеров (типа 48*48 для XP) начинает катастрофически отъедать дополнительный объем. Таким образом, я не ожидаю существенного превышения объема векторных иконок над пиксельными.
GZ>Относительное позиционирование.
GZ>Чудная вещь. Но только как дополнительная. Возьмем к примеру ту же иконку, которую в принципе нельзя
GZ>ресазить.
Как я уже сказал, unscalable — на свалку истории. Пойми, что у иконок нет своих интересов. Интересы есть только у нас. И в наших интересах перейти на векторные иконки.
GZ>То есть все можно резайзить, а вот иконку нельзя. Можно даже говорить и не о иконка, а просто о маленьких картинках. Ну хоть убей — нельзя, а все можно. В результате получается что на ресайзе диалога получается бардак.

GZ>В принципе подобное уже есть в WWW. Сейчас все больше сайтов появляется которые вообще не поддерживают ресайз. Если поискать по сети, то у юзабелистов отношение к этому ох какое неоднозначное. И поскольку и я делал дизайн сайтов и ресайз диалогов, я их понимаю. Бардак делается легко. Но лечится трудно. Поэтому абсолютное позиционирование, и голова чтобы контролы не вылезали за пределы предназначенной для них области и не превышали число 7 — для меня важнее.
Именно против бардака я и протестую. Но решение проблемы я вижу исключительно в векторной графике с высокой производительностью. Потому что тщательное затачивание сайта под 800px — это чистой воды маразм. Непроизводительный расход умственной энергии. Равно как и ручной кернинг шрифтов на кнопочках меню.

GZ>Я не защищаю Microsoft. Я защищаю себя. Мои программы должны быть не сильно красивы, они должны быть функциональны, удобны и полезны. А красоту оставим художникам. Ради нее я биться не намерен.

Функциональность, удобство и полезность скрыты в барьере в 96 DPI, и чудовищных усилиях, которые необходимы для прорисовки приличного GUI.
Кстати, об усилиях: обрати внимание, как мало прилично выглядящих десктоп-приложений, и как много веб-сайтов. Это наглядно демонстрирует превосходство HTML-модели (несмотря на все проблемы кроссбраузерной совместимости и прочие детали) над моделью GDI.

... << RSDN@Home 1.1.4 stable rev. 510>>

Здравствуйте, WinterMute, Вы писали:
WM>Понятно что сочетается, но точное позиционирование текста для HTML не обязательно.
Это заблуждение. При верстке документа — да. Но при дизайне сайта приходится даже кернинг вручную подправлять.
Вообще, очень рекомендую на сию тему к прочтению Лебедева и Кирсанова. Очень доходчиво объясняют, что можно забывать, а что не стоит.

... << RSDN@Home 1.1.4 stable rev. 510>>

Здравствуйте, McSeem2, Вы писали:
MS>Да даже если "важен кажый пиксель", что с того? Есть даже такое искусство — пробегало как-то у Темы Лебедева. Это будет всего-навсего означать, что каждый пиксел может быть представлен прямоугольником 5x5, 7x7 и тэдэ.
У тебя же врод где-то был сэмпл приложения, где иконки — векторные. Если я ничего не путаю — кинь ссылкой в скептиков.

... << RSDN@Home 1.1.4 stable rev. 510>>

Здравствуйте, Sinclair, Вы писали:

S>У тебя же врод где-то был сэмпл приложения, где иконки — векторные. Если я ничего не путаю — кинь ссылкой в скептиков.

А, ну да:
http://antigrain.com/stuff/sketcher.zip
Вот "издевательский" вариант:
http://antigrain.com/stuff/sketcher2.zip
Его можно включать, например, по окончании trial period.

Здравствуйте, McSeem2, Вы писали:

S>>У тебя же врод где-то был сэмпл приложения, где иконки — векторные. Если я ничего не путаю — кинь ссылкой в скептиков.

MS>А, ну да:
MS>http://antigrain.com/stuff/sketcher.zip
MS>Вот "издевательский" вариант:
MS>http://antigrain.com/stuff/sketcher2.zip
MS>Его можно включать, например, по окончании trial period.

А в каком, кстати, формате там графика хранится? Что-то свое?

Здравствуйте, Sinclair, Вы писали:

S>Сейчас это крохотный PDA.... 640*480. Я совершенно не удивлюсь, если еще через пять лет мы увидим 300 DPI и на КПК.

Скорее телефон 128*128. Чего, кстати, достаточно почти для всего

Графопострители и векторные мониторы появились, насколько я помню, раньше, чем растровые. Не говоря уж о банальных осциллографах, которые тож, в некотором роде, используют векторную графику

Здравствуйте, Sinclair, Вы писали:
GZ>>А сейчас поддерживаются и True type шрифты и много чего. И практически во всех картах. Так что здесь вы опоздали.
S>Я позволю себе усомниться. Хотя буду только рад, если ошибусь.

Меня тоже грызут сомнения. Если видеокарта способна рисовать произвольные TT шрифты, то это собственно все, что нам необходимо для векторной графики хорошего качества. Самое главное — там есть кривые Безье, пусть даже только квадратические. Следовательно, мы можем много чего нарисовать этими кривыми. И объем передаваемых данных сокращается в десятки раз.
Но люди зачем-то изобретают свои хитрые способы рисования символов:
http://research.microsoft.com/~cloop/LoopBlinn05.pdf
Зачем? Чудаки!

Далее. Байт-код хинтов в TrueType защищен патентом. Что это означает? Много чего. Без покупки лицензии мы не имеем права интерпретировать эти хинты. Например, вызывать GetGlyphOutline() — можно (с хинтами!), читать TT-файлы и извлекать из них начертания символов — тоже можно, а вот самим выполнять код хинтов — нельзя. Но если видеокарта умеет рисовать TrueType, значит они купили лицензию. Следовательно, способ рисования текста посредством видеокарты становится лицензионно чистым. Так почему же тогда линуксоиды им не пользуются, а продолжают упираться в свой FreeType с его авто-хинтером (довольно посредственным, кстати)?

И вообще, дайте мне быстрый растеризатор в видеокарте (с Безье-кривыми!) — я бы уххх!

Здравствуйте, Зверёк Харьковский, Вы писали:

ЗХ>А в каком, кстати, формате там графика хранится? Что-то свое?

Для тулбара я взял формат SVG path, то есть, типа:
"M19 0 c-1.532 2.637 -6.468 2.637 -8 0 l8 0 z"

А остальная графика — это собственно молекула. Внутри она представляет собой граф. Нижний тулбар — это те же самые маленькие молекулки

Здравствуйте, McSeem2, Вы писали:

MS> такая профессия, как веб-дизайнер отпадет как ненужный "атрофизм". Останутся просто профессии дизайнеров и верстальщиков. Не надо будет заморачиваться на тему автопереносов текста (text flow) — как было задумано, так и увидит любой человек на любом компе или даже PDA. [покусано...] А самое главное — HTML можно будет выкинуть на свалку. Вместо него будут простые графические инструкции, отображающиеся идентично на любом мониторе и любом принтере.

MS>"Во какой бред! Во куда заносит!" (Убить Дракона)...

Эт точно!

Как минимум, насчёт PDA не согласен — даже у пресловутого адоборидера для КПК есть Reflow plugin (кстати, не всегда срабатывает), который создан именно для убийства трудов верстальщиков, чтобы на масеньком экранчике PDA смотреть ебуки с нормальным размером шрифта. А HTML — он тем и хорош,что приемлемо отображается на куче устройств с различными размерами и пропорциями экранов.
Не надо ставить приятный внешний вид превыше удобства просмотра.
А за AGG — адназначна респект!

Здравствуйте, DEMON HOOD, Вы писали:

DH>на самом деле у них тоже есть своя ниша, различные кассовые аппараты например...

Кассовые аппараты потихоньку переходят на термопечать, особенно портативные. А вот принтеры, которыми печатаются многослойные документы, у которых на нижних слоях получается копия "под копирку" (вроде авиабилетов) — эта ниша именно для матричных принтеров.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Здравствуйте, McSeem2, Вы писали:

MS>Я хотел лишь донести спорную мысль (даже для меня самого спорную), что наличие этой "гламурной четкости" само по себе тормозит развитие. Но не прямо, а косвенно — через невозможность свободно масштабировать текст.
Идея кстати стара. Если забыть о шрифтах, то идею того, что нужно рисовать именно в логических device-independ координатах Microsoft продвигала еще со времен Windows 2.0. У них и размер стандартного диалога тогда рассчитывался по размеру экрана(но который рассчитывался по DPI что было (и осталось но тогда она была меньше, сколько сейчас не помню) константой. Потом все эти системы, что вижу то и печатаю. Она полностью держится на логических координатах. Но все равно не пошла. Как-то пришлось созданием интерфейса по типу ActiveX — приходится в то или иное место закрашивать пикселями. А тут не до алайзинга.(согласен что данный вопрос прямо связан с DPI)

MS>Можно представить себе следующую схему (я, кстати говоря, еще лет 15 назад о такой мечтал). У нас есть светодиодная матрица 8000x6000. Под каждым пикселом находится маленький процессор и сотня байт памяти. Этот процессор умеет выполнять операцию AlphaBlend. В продвинутых случаях — остальные color compositing операции. Управляются эти процессоры строчно-столбцовым способом. Типа "открыть порт для передачи данных по всей строке номер 1343 — передать данные в колонку 2345". Таким образом мы засветили один пиксел. Закраска прямоугольника 1000x1000 при этом требует не миллион итераций, а всего-навсего 1000+1000. Anti-aliasing при таком разрешении нам не нужен и это сильно упрощает дело. Кроме того, каждый пиксел может сам себе быть альфа-маской и/или z-буфером.
Чудная мысль, но сколько это будет стоить? И основная проблема современных систем (а это системы Фон Неймана) это не быстродействие процессора, а быстрота шины. Именно она ограничивает. Поэтому стоит говорить именно о шине.

GZ>>Насчет векторной графики. В принципе, векторная графика появилась еще в незапамятные времена.

MS>Где? Кроме Flash и SVG/XAML (которые появились в очень даже "запамятные" времена), какие векторные форматы и стандарты мы знаем? Есть OpenGL — но это API, а не формат данных.
Ребята, вы что? WMF(EMF) — стандарты еще со времен Windows 3.1. Не будем говорить на сколько хороши эти форматы(сам их уже не помню, разбирал очень давно), но в принципе была идея ActiveX контролы передавать на устройство вывода(в том числе через сеть) именно в формате WMF(EMF). Не знаю было ли это в стандарте ActiveX, но кто-то(а может даже ATL) это умел. Сам такое не юзал. Но как стандарт векторной графики в windows, де факто, он был.

MS>Об этом можно поподробнее? Про рисование линий банальным Брезенхемом я знаю. А вот про аппаратно ускоренный TrueType? Со сглаживанием? Честно сказать, я в этом плане человек дремучий и много чего не знаю. Но "аппаратно ускоренный TrueType" представляется мне чем-то из области легенд. Не верю! Не бывает такого. Ответь только на один простой вопрос — а в MemDC TrueType тоже рисуется аппаратно-ускоренно? А ведь это работает нисколько не медленнее! Но давай вынесем эту тему в мультимедию (или asm), я не исключаю, что здесь я могу облажаться в полный рост и был бы рад просвящению.
Насчет Безье

GDI offers improved definitions of lines and curves. Lines are not required to have integer endpoints in DEVICE coordinates, as was true for Microsoft Windows 3.x. This allows the driver to transform graphics objects without gross rounding. The fundamental curve in GDI is a Bezier curve (cubic spline) rather than an ellipse. All GDI internal operations are handled with Bezier curves, which are supported by most high-end devices. For devices that do not handle Bezier curves, GDI breaks curves down into line segments before calling the driver to draw them.

DrvLoadFontFile
И вообще, список функций видео(printer) драйвера.
здесь
То есть, Microsoft умыла руки. Это проблема производителя что использовать, использовать стандартную возможность реализованную Microsoft, реализовать самому софтварно, реализовать самому аппаратно. Или в смешанном режиме. Тут под Microsoft не подкапаешься. Они все мудро делали еще со времен Windows 3.1(когда я еще занимался драйверами, поэтому если где ошибся можно поправить).
А насчет всех карт — это я выпендрился.

В действительности не знаю.

GZ>>Но возьмем к примеру иконку. Она пиксельная. Это набор пикселей который нельзя scaleить. Иначе ты получишь совершенно другую картинку. Как векторная — она неинтересна, потому как объем команд в большинстве случаев, значительно больше количество пикселей.

MS>Это категории их разных областей. Объем команд в растровом представлении пропорционален количеству пикселов. Объем команд в векторном представлении пропорционален сложности рисунка. В определенных условиях растровое представление выгоднее. Но, грубо говоря, с увеличением размеров объем растровой картинки растет как O(N^2), в то время как объем векторной остается O(1). Весь вопрос заключается в том, когда реально этот O(N^2) превысит O(1).
Для фотографий это убийственные формулы. Что касается именно интерфейса программ, возразить нечего.

MS>Глеб, я безусловно отношусь с уважением к твоей точке зрения. И очень ценю то время, что ты потратил на написание этого ответа. Моя цель в споре — не задавить кого-то своим "авторитетом", а самому понять что-то важное. Спасибо!

Самому понравилась ваша точка зрения.

Просто не считаю ее верной

С уважением, Gleb.

Здравствуйте, Sinclair, Вы писали:

S>Вопрос, конечно, интересный. Но что такое "маленькие экраны"? Пять лет назад это был двухстрочный пейджер. Ну там типа 16*64 пиксела.
S>Сейчас это крохотный PDA.... 640*480. Я совершенно не удивлюсь, если еще через пять лет мы увидим 300 DPI и на КПК.
У тебя может и да. У меня еще меньше(а у смартфонов и вслух говорить не хочется). И главное они появляются и появляются. И размер экрана увеличен быть не может. А значит нужно привыкать именно к мелким шрифтам. А мелкие шрифты должны быть четкими, независимо от того чем обеспечиваются, повышенным DPI, или выверенными пикселями. Но тут уже принцип достаточности. Зачем платить за то, что не нужно. Мне не нужен КПК как кластер SQL Server или Oracle. Он нужен как органайзер, и для некоторых спец. бизнес-приложений. А эти бизнес-приложения специализированы под экран КПК. Так зачем платить и развивать то чего никому не нужно.

S>Так, вот тут я чего-то не понимаю. Во-первых, кто заставляет видеокарту полностью перерисовывать картинку на каждый кадр? Во-вторых, именно векторность — единственный способ борьбы с высоким разрешением. Как раз потому, что число пикселов для бит-блиттинга растет слишком быстро.
На данный момент мониторы в основном — кинескопы. А видеопамять — программа управления электронным лучем. Все осталось на своих местах(эх, где времена CGI/EGA, когда нужно было учитывать обратный ход луча). Вот когда кинескопы уйдут в леса богатые дичью(а это произойдет через N лет, но верю что обязательно), вот тогда о видеопамяти как программе можно забыть. Но до этого еще дожить нужно.

S>Кстати, еще пару лет назад я встречал упоминание про прототип 3d монитора. Все прекрасно, кроме отсутствия шнуров для передачи такого количества данных. Объем "картинки" — около миллиарда вокселов. при 30 fps мы получаем 100 Гб/c через кабель. Разработчики считают, что ответом станет передача через кабель OpenGL и прямой рендеринг на стороне монитора.
Это в принципе впихнуть видеокарту в монитор. Должен с ними согласиться, правильный путь. Тогда действительно вопрос только в оптимизации команд с помощью векторной графики. Фотографию или кинофильм с помощью векторов посылать нельзя. Так что растр отменить как класс нельзя(но можно его оптимизировать, что сейчас и делается).

GZ>>Насчет векторной графики. В принципе, векторная графика появилась еще в незапамятные времена. Еще с первыми SVGA картами появились ускорители 2D. Хотя бы line операция поддерживалась.
S>Очень интересно. Я не специалист по данному вопросу, но VESA я в свое время занимался. Не припомню там ничего насчет команды line.
По моему в Vesa была все таки Line. Сам давно занимался. Но в Diamond 3D, что у меня было в 1997 году, она точно аппаратная была. Насчет Trident(ох и великая штука) не уверен.

GZ>>А сейчас поддерживаются и True type шрифты и много чего. И практически во всех картах. Так что здесь вы опоздали.
S>Я позволю себе усомниться. Хотя буду только рад, если ошибусь.
здесь
GZ>>Но возьмем к примеру иконку. Она пиксельная. Это набор пикселей который нельзя scaleить.
S>Иконки в современном виде — вообще ошибка природы. Их не должно быть

Согласен но они есть. Можно взять в рассчет маленькую картинку.

S>Именно против бардака я и протестую. Но решение проблемы я вижу исключительно в векторной графике с высокой производительностью. Потому что тщательное затачивание сайта под 800px — это чистой воды маразм. Непроизводительный расход умственной энергии. Равно как и ручной кернинг шрифтов на кнопочках меню.
Не буду повторяться, идея не нова.там же

S>Кстати, об усилиях: обрати внимание, как мало прилично выглядящих десктоп-приложений, и как много веб-сайтов. Это наглядно демонстрирует превосходство HTML-модели (несмотря на все проблемы кроссбраузерной совместимости и прочие детали) над моделью GDI.
К сожалению, всякое бывает. Вообще под сайты значительно чаще нанимают дизайнера(или фирму), чем под десктопы. А вот если не наняли, то чудеса еще те(у десктопа все-таки строже правила). Я бы не связывал это именно с превосходством HTML модели. Это просто отсутствие стандартов и более высокий класс дизайнеров.

С уважением, Gleb.

Здравствуйте, McSeem2, Вы писали:

MS>И вообще, дайте мне быстрый растеризатор в видеокарте (с Безье-кривыми!) — я бы уххх!
здесь

— Ты суслика видишь?
— Нет.
— А он есть.
с)ДМБ

С уважением, Gleb.

S>Эт точно!

Как минимум, насчёт PDA не согласен — даже у пресловутого адоборидера для КПК есть Reflow plugin (кстати, не всегда срабатывает), который создан именно для убийства трудов верстальщиков, чтобы на масеньком экранчике PDA смотреть ебуки с нормальным размером шрифта. А HTML — он тем и хорош,что приемлемо отображается на куче устройств с различными размерами и пропорциями экранов.

Кстати, W3C надо бы разогнать к черту за их CSS, который дает простор фантазии для попиксельного размещения объектов и очень сильно ограничивает процентное размещение.

GZ>ресазить. То есть все можно резайзить, а вот иконку нельзя. Можно даже говорить и не о иконка, а просто о маленьких картинках. Ну хоть убей — нельзя, а все можно. В результате получается что на ресайзе диалога получается бардак. В принципе подобное уже есть в WWW. Сейчас все больше сайтов появляется которые вообще не поддерживают ресайз. Если поискать по сети, то у юзабелистов отношение к этому ох какое неоднозначное.

Потому что ни один из браузеров не делает при ресайзе то же, что и Опера, которая именно увеличивает _всю_ страницу, а не отдельные ее элементы.

Такой же подход решил бы проблемы многих других ресайзов

Здравствуйте, ZayatsZ, Вы писали:

DH>>на самом деле у них тоже есть своя ниша, различные кассовые аппараты например...

ZZ>А вот принтеры, которыми печатаются многослойные документы, у которых на нижних слоях получается копия "под копирку" (вроде авиабилетов) — эта ниша именно для матричных принтеров.
я их и имел в виду, не так выразился просто.

silent RSDN@Home 1.2.0 alpha [618] Windows XP 5.1.2600.65536

Здравствуйте, McSeem2, Вы писали:

MS>Здравствуйте, uw, Вы писали:

uw>>PostScript, PDF

MS>... Но в экранной графике пока что далеко до PostScript.

Postscript на экране был у NEXT в 1987 году. Жалко умер

http://lowendmac.com/orchard/05/0705.html
http://en.wikipedia.org/wiki/Display_PostScript

MS>>Я хотел лишь донести спорную мысль (даже для меня самого спорную), что наличие этой "гламурной четкости" само по себе тормозит развитие. Но не прямо, а косвенно — через невозможность свободно масштабировать текст.
GZ>Идея кстати стара. Если забыть о шрифтах, то идею того, что нужно рисовать именно в логических device-independ координатах Microsoft продвигала еще со времен Windows 2.0. У них и размер стандартного диалога тогда рассчитывался по размеру экрана(но который рассчитывался по DPI что было (и осталось но тогда она была меньше, сколько сейчас не помню) константой. Потом все эти системы, что вижу то и печатаю. Она полностью держится на логических координатах. Но все равно не пошла. Как-то пришлось созданием интерфейса по типу ActiveX — приходится в то или иное место закрашивать пикселями. А тут не до
алайзинга.(согласен что данный вопрос прямо связан с DPI)

Преобразование координат — операция тривиальная. Нетривиальным же является использование нецелых пиксельных координат. Я приводил пример, почему это важно:
http://www.rsdn.ru/Forum/Message.aspx?mid=545188&only=1
Но с одной стороны, ты прав. Некие логические единицы не должны зависеть от разрешения устройства. Другое дело — нужны ли реально миллиметры и дюймы? Я считаю, что не нужны. И даже более того — их использование противоречит тому, что мы наблюдаем на мониторах! (догадайтесь с одного раза, почему).
Должны быть некие абстрактные единицы, типа MM_ISOTROPIC или MM_ANISOTROPIC. Все, большего и не требуется. Миллиметры и дюймы на современных мониторах — это вообще нонсенс! Хотя, возможно, это некий задел на будущее. Когда монитор в реальности будет гарантировать NNN DPI, тогда можно будет говорить и о дюймах. А пока что — это лишь некая условность сбивающая с толку.

GZ>Чудная мысль, но сколько это будет стоить? И основная проблема современных систем (а это системы Фон Неймана) это не быстродействие процессора, а быстрота шины. Именно она ограничивает. Поэтому стоит говорить именно о шине.

Сейчас даже просто матрица на светодиодах будет стоить очень дорого (особенно синие светодиоды). Это сейчас. 10 лет назад синих светодиодов вообще не существовало (в некоторых лабораториях наверное были). А сколько 10 лет назад стоил гиг оперативной памяти? Это я к тому, что сегодняшняя стоимость не является принципиальным ограничителем.
А вообще-то, надо начинать даже не с этого. RGB — это тоже тормоз. Нужен еще фиолет и малиновый цвет, которые в RGB в принципе не отображаются.

MS>>Где? Кроме Flash и SVG/XAML (которые появились в очень даже "запамятные" времена), какие векторные форматы и стандарты мы знаем? Есть OpenGL — но это API, а не формат данных.
GZ>Ребята, вы что? WMF(EMF) — стандарты еще со времен Windows 3.1. Не будем говорить на сколько хороши эти форматы(сам их уже не помню, разбирал очень давно), но в принципе была идея ActiveX контролы передавать на устройство вывода(в том числе через сеть) именно в формате WMF(EMF). Не знаю было ли это в стандарте ActiveX, но кто-то(а может даже ATL) это умел. Сам такое не юзал. Но как стандарт векторной графики в windows, де факто, он был.

О-хо-хо. Я говорю о неком формате, типа GIF, который бы реально использовался людьми для обмена. Где в Интернете хоть одна страница с EMF? Ладно, фиг с ним, с Интернетом — где хоть одна пиктограмма на десктопе в формате EMF? Реально используется Flash. Ну еще SVG и XAML в стадии эмбрионов. EMF/EMF+ являются чисто внутренними форматами, которые никого не э... затрагивают особо.
Чего я больше всего хочу в векторной 2D графике:
1. Формат данных, отображаемый везде и всюду.
2. Формат данных, легко генерируемый скриптами (как HTML, хоть я и не люблю HTML).
3. Он должен быть и текстовым и бинарным — два представления одного и того же.
4. Легким и быстрым в отображении (мгновенным как GIF, и резким как понос, но ни в коем случае не тормозом, как Adobe Acrobat или GhostScript!)
5. Платформонезависимым.

Пока что такого формата нету. Flash рисуется всезде и всюду и очень быстро, но мы зависим от Flash MX при разработке сайта. Программно сгенерировать SWF — это нетривиальная задача. SVG — генерируется элементарно, но почти ничем не отображается (Adobe SVG не в счет — это такая дырища в security, что лучше не ставить).

Я хочу, чтоб было нечто простое, но стандартизованное. Гораздо проще чем SVG и Flash, но гарантированно работающее везде и всюду.

Здравствуйте, korzhik, Вы писали:

K>Балдею от expanding scrollbars в page_demo.exe !

Поддерживаю +3

Здравствуйте, McSeem2, Вы писали:

1) "Если бы MS не было его стоило бы выдумать". "Майккрософту — от Вольтера" и пр.

2) Концепт "растеризации вектора" порочен сам по себе. Вектор нужно рисовать вектором.
Сколько бы ты не делал DPI все равно проблемы остаются.
На 600 DPI например делают REt I, II, III и конца тому не видно.

Здравствуйте, McSeem2, Вы писали:

MS>http://antigrain.com/stuff/sketcher.zip

А кстати слышал ли ты про некий комп с названием NEXT и его графический интерфейс ?

Здравствуйте, minorlogic, Вы писали:

M>А кстати слышал ли ты про некий комп с названием NEXT и его графический интерфейс ?
Сорри , не всю ветку прочел. Но это то что сразу пришло на ум.

Ну вот , дочитал тему до конца , теперь выскажусь.

Не смог найти место кому высказать конкретно , поэтому сразу в главную ветку.
Тут звучало мнение что векторные иконки будут выглядеть намного хуже чем пиксельные уже адаптированные под конкретное разрешение.

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

Плюс .

Есть один замечательный дедовский способ ( кстати не видел в AGG ,надо бы исправить !!! ) .
Векторное изображение рендрится в пиксельное представление , но не статически , а изображение как бы анимируется . Изображение как бы медленно плавает в пределах ПОЛОВИНЫ пиксела ( по кругу например или восьмеркой ).

Если анимация достаточно быстра , то Субъективное разрашение такого изображения увеличивается НА ПОРЯДОК , больше чем в 4 раза !!!.

Здравствуйте, minorlogic, Вы писали:

M>Есть один замечательный дедовский способ ( кстати не видел в AGG ,надо бы исправить !!! ) .
M>Векторное изображение рендрится в пиксельное представление , но не статически , а изображение как бы анимируется . Изображение как бы медленно плавает в пределах ПОЛОВИНЫ пиксела ( по кругу например или восьмеркой ).

M>Если анимация достаточно быстра , то Субъективное разрашение такого изображения увеличивается НА ПОРЯДОК , больше чем в 4 раза !!!.

Вот это интересно. Можно пример? Хотя бы анимированный GIF?
Впрочем есть сомнения по причине инерционности и/или ограниченного refresh rate.

Здравствуйте, c-smile, Вы писали:

CS>2) Концепт "растеризации вектора" порочен сам по себе. Вектор нужно рисовать вектором.

То есть плоттером на бумаге? А на экране — чем? Лучем с регенерацией, как в древних векторных дисплеях? Рискну утверждать, что это не так. Плоттеры хоть и применяются, но все более и более ограниченно.

CS>Сколько бы ты не делал DPI все равно проблемы остаются.
CS>На 600 DPI например делают REt I, II, III и конца тому не видно.

Это проблемы из другой области. И как раз из области печати фотографий. Для ровных контрастных линий вполне достаточно 600 dpi безо всяких сглаживаний. А вот для печати голубого неба — и 2400 маловато.

Здравствуйте, McSeem2, Вы писали:

MS>Вот это интересно. Можно пример? Хотя бы анимированный GIF?
MS>Впрочем есть сомнения по причине инерционности и/или ограниченного refresh rate.

Чес говоря во так пример сразу не найду , но кажется мне что AGG с антиальязингом и сам такой пример сделает. Собственно пару строк кода сгенерировать . Знаменитого тигренка кадров 16 сгенерировать в маленького размера с плавным сдвигом ( амплитуда пол пиксела ).
Я попробую что то дома сделать.

Насчет инерционности это да , это продлема, но новые ЖК панельки все быстрее и быстрее , так что и на PDA такой трюк думаю сработает .

Недавно читал что некоторые ЖК мониторы похожую технику применяют , для повышения цветового разрешения.

Здравствуйте, McSeem2, Вы писали:

MS>О-хо-хо. Я говорю о неком формате, типа GIF, который бы реально использовался людьми для обмена. Где в Интернете хоть одна страница с EMF? Ладно, фиг с ним, с Интернетом — где хоть одна пиктограмма на десктопе в формате EMF? Реально используется Flash. Ну еще SVG и XAML в стадии эмбрионов. EMF/EMF+ являются чисто внутренними форматами, которые никого не э... затрагивают особо.
MS>Чего я больше всего хочу в векторной 2D графике:
MS>1. Формат данных, отображаемый везде и всюду.
MS>2. Формат данных, легко генерируемый скриптами (как HTML, хоть я и не люблю HTML).
MS>3. Он должен быть и текстовым и бинарным — два представления одного и того же.
MS>4. Легким и быстрым в отображении (мгновенным как GIF, и резким как понос, но ни в коем случае не тормозом, как Adobe Acrobat или GhostScript!)
MS>5. Платформонезависимым.

MS>Пока что такого формата нету.

DXF

Здравствуйте, minorlogic, Вы писали:

M>Насчет инерционности это да , это продлема, но новые ЖК панельки все быстрее и быстрее , так что и на PDA такой трюк думаю сработает .

Даже дело не в инерционности. Refresh rate все равно ограничен.

M>Недавно читал что некоторые ЖК мониторы похожую технику применяют , для повышения цветового разрешения.

Как для цветового — это понятно. Есть такой способ для GIF (с разными палитрами). А вот как это должно работать для увеличения пространственного разрешения — что-то не соображу.

Колись давай.

Здравствуйте, McSeem2, Вы писали:

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

То есть чтобы текст совершал легкие плавные движения. Текст который движется должен быть намного лучше различим.

Здравствуйте, minorlogic, Вы писали:

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

M>То есть чтобы текст совершал легкие плавные движения. Текст который движется должен быть намного лучше различим.

Ага, я теперь понял, откуда эти легенды про "многократное" увеличение разрешения. ТоварищЪ c-smile навел меня на эту мысль. Дело в том, что цветовое разрешение связано с пространственным, но до определенного предела. Возьмем черно-белый лазерник. У него точка может либо быть, либо не быть — никаких полутонов. Градации серого обеспечиваются, например, методом упорядоченного возбуждения. Иначе говоря (утрируя!) один серый пиксел — это квадрат 16x16 черных и белых пикселов. Мы увеличиваем цветовое разрешение в 256 раз, во столько же раз уменьшая пространственное. Но есть способ улучшить цветовое разрешение, не ухудшая пространственного. Для этого каждый пиксел должен часто-часто мигать. Его визуальная яркость будет определяться скважностью "мигания" и мы будем воспринимать это как полутон, несмотря на то, что физически пиксел монохромный. Получается так, что имея скважность 0, 0.5 и 1, мы уже имеем три градации яркости, вместо двух. И соотвественно, можем увеличить пространственное разрешение без ухудшения цветового. Но дело-то в том, что на мониторе у нас нет острой необходимости увеличивать цветовое разрешение — оно и так уже достаточно. Или, можно перефразировать, у нас нет ресурса для игры с пространственным разрешением за счет цветового. Вот если бы у нас был монитор 600dpi, но с чисто "бинарными" пикселами — тогда да, управляя скважностью, можно сэмулировать очень тонкие и четкие линии любого цвета, вместо того, чтобы "лепить" их квадратами 16x16 (опять же, утрируя).

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

Здравствуйте, McSeem2, Вы писали:

MS>Преобразование координат — операция тривиальная. Нетривиальным же является использование нецелых пиксельных координат. Я приводил пример, почему это важно:
MS>http://www.rsdn.ru/Forum/Message.aspx?mid=545188&only=1
MS>Но с одной стороны, ты прав. Некие логические единицы не должны зависеть от разрешения устройства. Другое дело — нужны ли реально миллиметры и дюймы? Я считаю, что не нужны. И даже более того — их использование противоречит тому, что мы наблюдаем на мониторах! (догадайтесь с одного раза, почему).
MS>Должны быть некие абстрактные единицы, типа MM_ISOTROPIC или MM_ANISOTROPIC. Все, большего и не требуется. Миллиметры и дюймы на современных мониторах — это вообще нонсенс! Хотя, возможно, это некий задел на будущее. Когда монитор в реальности будет гарантировать NNN DPI, тогда можно будет говорить и о дюймах. А пока что — это лишь некая условность сбивающая с толку.
Я бы сказал так. Если человеческий глаз не будет отличать линию нарисованную одним пикселем, и двумя пикселями, то это начало новой эпохи.

MS>Сейчас даже просто матрица на светодиодах будет стоить очень дорого (особенно синие светодиоды). Это сейчас. 10 лет назад синих светодиодов вообще не существовало (в некоторых лабораториях наверное были). А сколько 10 лет назад стоил гиг оперативной памяти? Это я к тому, что сегодняшняя стоимость не является принципиальным ограничителем.
MS>А вообще-то, надо начинать даже не с этого. RGB — это тоже тормоз. Нужен еще фиолет и малиновый цвет, которые в RGB в принципе не отображаются.
А я бы сказал больше. Даже отослал в философию.здесь

MS>О-хо-хо. Я говорю о неком формате, типа GIF, который бы реально использовался людьми для обмена. Где в Интернете хоть одна страница с EMF? Ладно, фиг с ним, с Интернетом — где хоть одна пиктограмма на десктопе в формате EMF? Реально используется Flash. Ну еще SVG и XAML в стадии эмбрионов. EMF/EMF+ являются чисто внутренними форматами, которые никого не э... затрагивают особо.
MS>Чего я больше всего хочу в векторной 2D графике:
MS>1. Формат данных, отображаемый везде и всюду.
MS>2. Формат данных, легко генерируемый скриптами (как HTML, хоть я и не люблю HTML).
MS>3. Он должен быть и текстовым и бинарным — два представления одного и того же.
MS>4. Легким и быстрым в отображении (мгновенным как GIF, и резким как понос, но ни в коем случае не тормозом, как Adobe Acrobat или GhostScript!)
MS>5. Платформонезависимым.
Подпишусь, два раза.

Единственное что, на примере принтеров мы имеем то, что все отображается по разному на разных принтерах. Проблема что принтеры выдерживают точно 300x300 dpi, или 600x600. Так где-то 295 dpi, и уже картинка(страница) перестает вмещаться в лист. Мелочь, но геморой еще тот.
MS>Пока что такого формата нету. Flash рисуется всезде и всюду и очень быстро, но мы зависим от Flash MX при разработке сайта. Программно сгенерировать SWF — это нетривиальная задача. SVG — генерируется элементарно, но почти ничем не отображается (Adobe SVG не в счет — это такая дырища в security, что лучше не ставить).
MS>Я хочу, чтоб было нечто простое, но стандартизованное. Гораздо проще чем SVG и Flash, но гарантированно работающее везде и всюду.
Я думаю, что это все-таки надо требовать от w3c. Возможно мы бы так и умерли без GIF и JPG в виндах(а жили бы на bmp и dip) если бы не интернет. С векторным форматом должно произойти то же самое. Тогда он будет стандартом для всех(и для виндов тоже). А EMF между прочим до сих пор поддерживается Windows. Только, как ты правильно заметил, без всеобщего одобрения — он стандартом, де факто, не стал.

С уважением, Gleb.

Здравствуйте, z00n, Вы писали:

uw>>>PostScript, PDF

MS>>... Но в экранной графике пока что далеко до PostScript.

Z>Postscript на экране был у NEXT в 1987 году. Жалко умер

Z>http://lowendmac.com/orchard/05/0705.html
Z>http://en.wikipedia.org/wiki/Display_PostScript

А современные "яблоки" вроде как на PDF основаны.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Здравствуйте, Andrei N.Sobchuck, Вы писали:

Z>>http://lowendmac.com/orchard/05/0705.html
Z>>http://en.wikipedia.org/wiki/Display_PostScript

ANS>А современные "яблоки" вроде как на PDF основаны.

И на старуху бывает проруха. К сожалению, PDF с точки зрения графических примитивов — еще худший монстр, чем SVG. К тому же, основательно устаревший. Взять хотя бы радиальные градиенты — их спецификацию крайне тяжело имплементировать, а имплементировать эффективно — просто невозможно. В то же время, я ни в одном документе не видел (кроме демо-примеров), чтобы кому-то понабодилось нарисовать эту градиентную "трубу". Вообще говоря, даже центр фокуса является излишеством. А уж чтобы можно было определять этот центр фокуса вне окружности — это вообще перебор. Никому на практике не нужный.

Здравствуйте, McSeem2, Вы писали:

MS>О-хо-хо. Я говорю о неком формате, типа GIF, который бы реально использовался людьми для обмена. Где в Интернете хоть одна страница с EMF? Ладно, фиг с ним, с Интернетом — где хоть одна пиктограмма на десктопе в формате EMF? Реально используется Flash. Ну еще SVG и XAML в стадии эмбрионов. EMF/EMF+ являются чисто внутренними форматами, которые никого не э... затрагивают особо.
MS>Чего я больше всего хочу в векторной 2D графике:
MS>1. Формат данных, отображаемый везде и всюду.
MS>2. Формат данных, легко генерируемый скриптами (как HTML, хоть я и не люблю HTML).
MS>3. Он должен быть и текстовым и бинарным — два представления одного и того же.
MS>4. Легким и быстрым в отображении (мгновенным как GIF, и резким как понос, но ни в коем случае не тормозом, как Adobe Acrobat или GhostScript!)
MS>5. Платформонезависимым.

Для штрихов есть HPGL. Я в свое время (лет 10 назад) использовал его в самых разных целях. Оказалось, что его нормально импортирут многие CAD системы, а генерить его — проще простого. Конечно, сам по себе он совершенно неудовлетворителен. Даже язык управления плоттерами Бердского радиозавода включает более интересные примитивы, такие как вывод текста и рисование дуг эллипсов.

... << RSDN@Home 1.1.4 stable rev. 510>>

Здравствуйте, Sinclair, Вы писали:

S>Для штрихов есть HPGL. Я в свое время (лет 10 назад) использовал его в самых разных целях. Оказалось, что его нормально импортирут многие CAD системы, а генерить его — проще простого. Конечно, сам по себе он совершенно неудовлетворителен. Даже язык управления плоттерами Бердского радиозавода включает более интересные примитивы, такие как вывод текста и рисование дуг эллипсов.

Есть еще протокол GKS (Graphics Kernel System). Но он еще более еще более устаревший и к тому же, закрытый.
Счастье заключалось бы еще вот в чем:
1. Некая разумная комбинация из SVG и Flash. Чем плох SVG — тем, что анимация в нем делается туго. В простейшем случае надо перерисовать всю сцену. Сцена Flash состоит из нескольких compound shapes (как слои), определенных явным образом с последующим alpha-blend. Таким образом, во Flash нам чаще всего достаточно перерисовать только одну compound shape. В SVG в общем случае, нет явных указаний на то, как нам разбивать рисунок на слои. Предполагается, что это должен оптимизировать user agent. Но задача этой оптимизации является весьма нетривиальной и ничего в общем случае не гарантирует.

2. Независимость от "носителя" — это может быть XML, может быть некий бинарный поток или даже текстовый, но отличный от XML. Вот, например, XML:

<?xml version="1.0" standalone="no"?>
<svg width="12cm" height="5.25cm" viewBox="0 0 1200 400">
  <rect x="1" y="1" width="1198" height="398"
        fill="none" stroke="blue" stroke-width="1" />
  <g stroke-dasharray="30 8 10" stroke-dashoffset="-9">
    <path d="M300,200 h-150 a150,150 0 1,0 150,-150 z"
          fill="red" stroke="blue" stroke-width="5"/>
    <path d="M275,175 v-150 a150,150 0 0,0 -150,150 z"
          fill="yellow" stroke="blue" stroke-width="5" />
    <path d="M600,350 l 50,-25 
             a25,25 -30 0,1 50,-25 l 50,-25 
             a25,50 -30 0,1 50,-25 l 50,-25 
             a25,75 -30 0,1 50,-25 l 50,-25 
             a25,100 -30 0,1 50,-25 l 50,-25"
          fill="none" stroke="red" stroke-width="5"  />
  </g>
</svg>

Вот почти то же самое на неком "другом" носителе:

{svg width=12cm height=5.25cm viewBox="0 0 1200 400"
  {rect x=1 y=1 width=1198 height=398
        fill=none stroke=blue stroke-width=1}
  {g stroke-dasharray="30 8 10" stroke-dashoffset=-9
    {path d="M300,200 h-150 a150,150 0 1,0 150,-150 z"
          fill=red stroke=blue stroke-width=5}
    {path d="M275,175 v-150 a150,150 0 0,0 -150,150 z"
          fill=yellow stroke=blue stroke-width=5}
    {path d="M600,350 l 50,-25 
             a25,25 -30 0,1 50,-25 l 50,-25 
             a25,50 -30 0,1 50,-25 l 50,-25 
             a25,75 -30 0,1 50,-25 l 50,-25 
             a25,100 -30 0,1 50,-25 l 50,-25"
          fill=none stroke=red stroke-width=5 }
  }
}

Это я к тому, что сам формат SVG замечательно ложится на любой носитель, поддерживающий иерархические структуры. Ну, конечно же, основное — это в бинарном виде.

В таком виде формат можно было бы использовать еще и в качестве протокола, например, вместо X11. Или вместо морально устаревшего и толстого PostScript.
А самое главное — тщательно вычистить все противоречия, присущие SVG и упростить имплементацию. SVG сейчас — это очень глючный формат и очень тяжело имплементируемый. И, кстати, большая дыра в защите если его интегрировать в IE. Вот, например — Adobe SVG банально валится на переполнении стэка (паттерн с бесконечной рекурсией):

<?xml version="1.0" standalone="no"?>
<svg width="4cm" height="4cm" viewBox="0 0 400 400">
  <defs>
    <pattern id="CirclePattern" patternUnits="objectBoundingBox"
             x="0" y="0" width="0.5" height="0.5"
             viewBox="0 0 100 100"
             >
      <circle cx="50" cy="50" r="50" stroke-width="5" 
              fill="url(#CirclePattern)" stroke="blue" />
    </pattern> 
  </defs>

  <rect fill="none" stroke="blue" 
        x="1" y="1" width="398" height="398"/>

  <circle fill="url(#CirclePattern)" stroke="black" stroke-width="5"  
           cx="200" cy="200" r="100"/>
</svg>

Здравствуйте, Зверёк Харьковский, Вы писали:

ЗХ>Здравствуйте, McSeem2, Вы писали:

ЗХ>2 (по существу). Попробуй объяснить мне (не мне — Зверьку, а "мне" — некоторому среднестатистическому пользователю), зачем мне разрешение 6000х9000 (в условиях обычного монитора)?

А я вот сплю и вижу монитор с 600 dpi. Знаешь почему? Текст на таком мониторе будет пропечатан гораздо качественнее. И глазки будут меньше болеть. И читать текст они будут тоже лучше. Медицинский факт -- распечатанный текст читается гораздо лучше, чем на мониторе. Из-за того, что буквы не из пикселов состоят, а из линий.

Здравствуйте, McSeem2, Вы писали:

MS>Здравствуйте, minorlogic, Вы писали:

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

M>>То есть чтобы текст совершал легкие плавные движения. Текст который движется должен быть намного лучше различим.

MS>Ага, я теперь понял, откуда эти легенды про "многократное" увеличение разрешения. ТоварищЪ c-smile навел меня на эту мысль. Дело в том, что цветовое разрешение связано с пространственным, но до определенного предела. Возьмем черно-белый лазерник. У него точка может либо быть, либо не быть — никаких полутонов. Градации серого обеспечиваются, например, методом упорядоченного возбуждения. Иначе говоря (утрируя!) один серый пиксел — это квадрат 16x16 черных и белых пикселов. Мы увеличиваем цветовое разрешение в 256 раз, во столько же раз уменьшая пространственное. Но есть способ улучшить цветовое разрешение, не ухудшая пространственного. Для этого каждый пиксел должен часто-часто мигать.

DLP?

Сообщение откорректировано. Убрана падонковская лексика. А если не хочется общаться — лучше помолчать. ХД

А если серьезно,... полный бред, совмещенный со словесным поносом... плюс ко всему, начиная с Windows 2000 система сидит на шрифтах OpenType...

P.S. Сломай компакт-диск с дистрибутивом винды, иди убей дядю Била, купи футболочку а-ля M$-SUCKS, поставь линукс с гномом... не знаю че тебе еще сделать можно такого,... может тогда твоя душа успокоится?

Здравствуйте, Whistler, Вы писали:

W>А если серьезно,... полный бред, совмещенный со словесным поносом... плюс ко всему, начиная с Windows 2000 система сидит на шрифтах OpenType...

Я ценю Ваше мнение, но все-таки посоветовал бы подучить матчасть. Так называемый "OpenType" — это на практике — тот же TrueType с некими чисто техническими дополнениями и средствами разрешения юридических конфликтов:
http://en.wikipedia.org/wiki/OpenType

History

OpenType was intended by Microsoft to be the successor to the TrueType font format developed by Apple Computer and licensed by Microsoft. Microsoft tried to license Apple's advanced typography technology, "GX Typography," and upon being refused turned to develop its own technology dubbed "TrueType Open" in 1994. Adobe Systems joined Microsoft in 1996, adding support for its PostScript Type 1 fonts, and the name OpenType was then used for the combined technologies.
[edit]

Description

OpenType uses the general structure of a TrueType font, but adds several unique options which enhance the font's typographical abilities. An OpenType font can include either TrueType outlines or PostScript-style outlines (though stored in the CFF/Type 2 format).

OpenType has several distinctive features:

* the font encoding is based on Unicode and can support any language (or multiple languages at once)
* OpenType fonts can have up to 65,536 glyphs
* fonts can have advanced typographic features, which allow proper typographic treatment of complex languages, and advanced typographic effects for simpler languages, such as English.

В Windows не используются (повторяю — не используются) никакие хинты кроме байт-кода TrueType. А речь была именно об этом. Все остальное — ортогонально, а формат аутлайнов — штука вообще тривиальная и не заслуживающая внимания.

W>P.S. Сломай компакт-диск с дистрибутивом винды, иди убей дядю Била, купи футболочку а-ля M$-SUCKS, поставь линукс с гномом... не знаю че тебе еще сделать можно такого,... может тогда твоя душа успокоится?

Спасибо за совет. Так и сделаю. Вот прямо ЩАС...

Здравствуйте, McSeem2, Вы писали:

W>>P.S. Сломай компакт-диск с дистрибутивом винды, иди убей дядю Била, купи футболочку а-ля M$-SUCKS, поставь линукс с гномом... не знаю че тебе еще сделать можно такого,... может тогда твоя душа успокоится?

MS>Спасибо за совет. Так и сделаю. Вот прямо ЩАС...

Я не хотел показаться грубым...

Прошу не считать меня хамом, просто я не люблю революционерских высказываний...

Конечно у TrueType есть свои недостатки, но умоляю, его в 80-х годах разрабатывали, на нем ОС держится с 1990 года (в Windows 3.0 его впервые ввели, если не ошибаюсь)... Да — есть камень в огород Microsoft за то, что они до сих пор не придумали ему более современную альтернативу.

Ей богу, я прочитав твою статью подумал, что в этом кто-то виноват, и ты его хочешь порвать на части.
Я не пропогандист Microsoft, Apple, IBM, Red-Hat и т.д. но такое впечатление, что из-за всех перечисленных тобою песчастий виновата именно Майкрософт. Он не сделали, они не уследили, мочи в сортире их...

Я не теоретик в области юзер-экспериенса, но знаю что большинству разработчиков эта проблема не мешает,... обычно просто формы (диалоги) делают с плавающими размерами, — Просто размеры (ширину и высоту) всех контролов на форме при инициализации перемножают на коэффициент, который собой представляет собой масштабность шрифта (96 точек на дюйм, 120 точек на дюйм и т.д...).

... << RSDN@Home 1.1.4 stable rev. 510>>

Здравствуйте, McSeem2, Вы писали:

MS>Как для цветового — это понятно. Есть такой способ для GIF (с разными палитрами). А вот как это должно работать для увеличения пространственного разрешения — что-то не соображу.

Колись давай.

Да все просто , эбычная математика . Глаз достоточно сложное устройство и старается выудить максимум информации .

А одно и то же изображени с сабпиксельными сдвигами математическими методами превращается в тоже с увеличенным разрешением . То есть набор изображений с сабпиксельным сдвигом дает больше информации чем одно изображение.

Здравствуйте, Whistler, Вы писали:

W>Я не теоретик в области юзер-экспериенса, но знаю что большинству разработчиков эта проблема не мешает
Разработчикам вообще ничего не мешает. Мешает это пользователям, которые получают г. вместо конфетки.
W>,... обычно просто формы (диалоги) делают с плавающими размерами, — Просто размеры (ширину и высоту) всех контролов на форме при инициализации перемножают на коэффициент, который собой представляет собой масштабность шрифта (96 точек на дюйм, 120 точек на дюйм и т.д...).
Я тебе рекомендую перечитать всю тему. Твои представления о смысле и проблемах рендеринга UI, мягко говоря, не соответствуют действительности. Особенно про масштабность шрифта (ты, похоже, вообще не представляешь себе что это такое).

... << RSDN@Home 1.1.4 stable rev. 510>>

Здравствуйте, Whistler, Вы писали:

W>>>P.S. Сломай компакт-диск с дистрибутивом винды, иди убей дядю Била, купи футболочку а-ля M$-SUCKS, поставь линукс с гномом... не знаю че тебе еще сделать можно такого,... может тогда твоя душа успокоится?

MS>>Спасибо за совет. Так и сделаю. Вот прямо ЩАС...

W>Я не хотел показаться грубым...

Есть мнение, что попав в новое место, не стоит сразу же демонстрировать понты. Можно оказаться в глупом положении (например, начать учить жизни эксперта в обсуждаемой теме, что и произошло в данном случае).
Есть также мнение, что лексические конструкции типа "полный бред, совмещенный со словесным поносом" не способствуют продуктивной дискуссии.
Кроме того, существует мнение, что если нет желания слушать — лучше воздержаться от высказывания собственных мыслей.

Я понятно выражаюсь?

Здравствуйте, McSeem2, Вы писали:

MS>

MS>Это они называют Times New Roman?! Да любого типографского дизайнера стошнит от такой пошлятины. Нет в шрифте "Times New Roman" таких зверских засечек. Ну нету! Это выглядит очень вульгарно и пошло. Вот нормальный Times New Roman:
MS>

Максим, а можно следать те же картинки, но с чуть большим размером шрифта? А то я вот, например, кроме некоторой размытости второй картинки разницы как-то не замечаю. Если не трудно, конечно...

(Whistler)

Я извиняюсь еще раз. Перегнул палку, обещаю впредь больше не беспредельничать.

ЗХ>Есть мнение, что попав в новое место, не стоит сразу же демонстрировать понты. Можно оказаться в глупом положении (например, начать учить жизни эксперта в обсуждаемой теме, что и произошло в данном случае).

Ваше мнение ошибочно, я на форуме с 2002 года. И не озадачен целью кидать понты, так как не считаю себя самым умным — иначе меня бы сдесь небыло.

ЗХ>Есть также мнение, что лексические конструкции типа "полный бред, совмещенный со словесным поносом" не способствуют продуктивной дискуссии.
ЗХ>Кроме того, существует мнение, что если нет желания слушать — лучше воздержаться от высказывания собственных мыслей.

ЗХ>Я понятно выражаюсь?

Посностью с вами согласен. Понял вину, прошу восстановить меня из бана.

Здравствуйте, Пацак, Вы писали:

П>Максим, а можно следать те же картинки, но с чуть большим размером шрифта? А то я вот, например, кроме некоторой размытости второй картинки разницы как-то не замечаю. Если не трудно, конечно...

Это элементарно. Берем MS Word и Adobe Acrobat. На самом деле, "мутная строка" — это тот же текст, но с отключенными хинтами. Фишка здесь в том, что он гораздо больше похож на Times New Roman при любых масштабах. Это именно то, что ценят профессиональные дизайнеры и верстальщики (не веб-дизайнеры!). С хинтами меняется само начертание символов в зависимости от размера. Вот фрагмент переписки с c-smile (надеюсь, он не обидится, тем более, что письмо — мое).

С фонтами все очень непросто и скалирование — это лишь малая часть айсберга.
Все дело в волшебных хинтах, будь они неладны.
То есть, неизбежно приходится чем-то жертвовать при отображении. Адоба
жертвует визуальной четкостью, MS-Word жертвует кернингом. Но и те и другие
обеспечивают строгое соответствие экран-принтер. Сейчас проведем визуальный
экспресс-анализ.
http://antigrain.com/stuff/adobe_text_rendering.png
http://antigrain.com/stuff/msword_text_rendering.png

Фрагмент в увеличенном виде:
http://antigrain.com/stuff/adobe_text_zoomed.png
http://antigrain.com/stuff/msword_text_zoomed.png
Нетрудно заметить, что у Адобы одни и те же буквы выглядят по-разному, за
счет субпиксельного позиционирования (i, t, n, s). В ворде же они всегда
одинаковые, но зато "плавают" по горизонтали. За счет этого обеспечивается
лучшая четкость, но кернинг — ни борщь, ни в красну армию. Текст выглядит
четко, но как-то очень неряшливо из за "гуляния" букв. В общем, Adobe
претендует на некий профессионализм, в то время, как MS занимается
профанацией населения. Кстати, профанация практически всегда выгоднее с
точки зрения конечных прибылей.

Далее суть проблемы. На высоком разрешении хинты не нужны вообще и они не
используются. В экранном разрешении — хинты обеспечивают хорошую четкость,
но при прямом рисовании ломают соответствие экран-принтер. Чтобы добиться
приемлемого качества при сохранении хинтов, приходится рисовать по одной
букве, вычисляя ее позицию при отключенных хинтах. Так делает Word (скорее
всего использует какие-то недокументированные функции). Но здесь нас тоже
ждет засада. Даже если мы используем WinAPI GetGlyphOutline, то нам не
так-то просто определить позицию. Там возвращаются gmCellIncX, gmCellIncY,
но они — в целых числах, то есть, в целых пикселах. Этой точности явно
недостаточно, поэтому надо вызывать GetGlyphOutline с GGO_UNHINTED, причем
для шрифта большого размера, скажем, 200 пикселов. Вот тогда можно
более-менее точно вычислить позицию буквы на экране, так, чтобы она
соответствовала позиции на принтере. Ну или делать наоборот — корректировать
позиции на принтере с учетом хинтов на экране — но это будет полный маздай.
То есть, вывод такой. Функции рисования текста WinAPI учитывают и кернинг и
хинты, и текст выглядит прельстиво. Но именно из за этого они совершенно
непригодны для WISIWIG.

Я уже давал ссылку: http://antigrain.com/stuff/RefxAgg.zip
Если менять размер окна, то видно, что строка внизу "прыгает". Она ведет
себя примерно так же, как DrawText:
http://antigrain.com/stuff/andrew_text_zoomed.png
Слово выглядит гораздо более (как это по-русски?) consistent — учитываются и
хинты и кернинг и все очень четко. Но явно видно накопление ошибки даже на
одном слове — сравни с Word или Adobe. Вот из за этой вот "маленькой
разницы" и получается полная ж... с печатью.

Здравствуйте, Пацак, Вы писали:
П>Максим, а можно следать те же картинки, но с чуть большим размером шрифта? А то я вот, например, кроме некоторой размытости второй картинки разницы как-то не замечаю. Если не трудно, конечно...

Я боюсь, что тогда пропадет главная идея. На больших размерах шрифты выглядят более-менее нормально. Вот только радикально отличаются от своей маленькой версии.
Поимимо размытости, в "нормальной" версии можно заметить:
— вертикальные штрихи толще горизонтальных
— у букв w, с справа вверху шарик, а не штрих
— засечки совсем-совсем тонкие.

... << RSDN@Home 1.1.4 stable rev. 510>>

Для пущей убедительности процитирую Стива Джобса (перевод выступления перед выпускниками Cтэнфорда):

Reed College всегда предлагал лучшие уроки по каллиграфии. По всему кампусу каждый постер, каждая метка были написаны каллиграфическим почерком от руки. Так как я отчислился и не брал обычных уроков, я записался на уроки по каллиграфии. Я узнал о serif и sans serif, о разных отступах между комбинациями букв, о том, что делает прекрасную типографику прекрасной. Она была красивой, историчной, мастерски утонченной до такой степени, что наука этого не смогла бы понять.

Ничто из этого не казалось полезным для моей жизни. Но десять лет спустя, когда мы разрабатывали первый Макинтош, всё это пригодилось. И Мак стал первым компьютером с красивой типографикой. Если бы я не записался на тот курс в колледже, у Мака никогда бы не было несколько гарнитур и пропорциональных шрифтов. Ну а так как Windows просто сдули это с Мака, скорее всего, у персональных компьютеров вообще бы их не было. Если бы я не отчислился, я бы никогда не записался на тот курс каллиграфии и у компьютеров не было бы такой изумительной типографики, как сейчас.

Я бы добавил, что Windows не просто "сдули", но и основательно испортили. Хинты, это конечно же хорошо, но до определенного предела — они не имеют права менять визуальное начертание символов. Хинты Type I — более-менее оптимальны, они не приводят к деградации начертания. Хинты TrueType — это уже перебор. Причины понятны — "деньги здесь и сейчас", но этот подход погружает население в пучину невежества.

Здравствуйте, <Аноним>, Вы писали:

А>(Whistler)

А>Я извиняюсь еще раз. Перегнул палку, обещаю впредь больше не беспредельничать.

Во. Это слова "не мальчика, но мужа".

ЗХ>>Есть мнение, что попав в новое место, не стоит сразу же демонстрировать понты. Можно оказаться в глупом положении (например, начать учить жизни эксперта в обсуждаемой теме, что и произошло в данном случае).

А>Ваше мнение ошибочно, я на форуме с 2002 года.

Я подразумевал, что Вы ничего не знали о квалификации собеседника. Под "новым местом" подразумевался не RSDN вообще, а философские дискуссии в юзабилити — в частности.

А>И не озадачен целью кидать понты, так как не считаю себя самым умным — иначе меня бы сдесь небыло.
Вот и я ж о том

По исходному Вашему сообщению складывалось другое впечатление, на что я и указал.

ЗЫ: ходатайствую к модератору о назначении инцидента исчерпанным.

Здравствуйте, McSeem2, Вы писали:

MS>SVG — генерируется элементарно, но почти ничем не отображается (Adobe SVG не в счет — это такая дырища в security, что лучше не ставить).

FF 1.5 умеет

... << RSDN@Home 1.2.0 alpha rev. 615 on Windows XP 5.1.2600.131072>>

Здравствуйте, GlebZ, Вы писали:

GZ>Я бы сказал так. Если человеческий глаз не будет отличать линию нарисованную одним пикселем, и двумя пикселями, то это начало новой эпохи.

На VGA PDA что то близкое наблюдается.

... << RSDN@Home 1.2.0 alpha rev. 615 on Windows XP 5.1.2600.131072>>

Здравствуйте, McSeem2, Вы писали:

MS>Это не так просто как кажется. Вот скажи, много ли сейчас осталось матричных иголочных принтеров? Лазерники-струйники с их 600 или 1200 dpi давно победили. Почему? Потому что "так красивше". Экстраполируя, могу предположить (гипотетически), что если ты пару месяцев поработаешь с полноценной экранной графикой в 600dpi, ты будешь воспринимать современные мониторы 1280x1024 как "полный ацтой" и скажешь "что это за издевательство над зрением?!" Разве не так?

Тут есть еще одна проблема.
Предположим, что у тебя разрешение 8000x6000. Минимальная частота развертки, моргания от которой абсолютно не заметно глазом — более 200 Гц (!!!, а не 100Гц, как думают некоторые). Насколько я понял, частота развертки стоит раньше по приоритетам?

Теперь попытайся спроектировать либо цифровую либо аналоговую систему передачи данных на монитор с такими параметрами.

Успехов.

ЗЫ.

Телевидение высокой четкости имет параметры всего лишь в 2 раза превышающие параметры обычного телевидения, я те примерно таковы:
512 строк для яркостной информации, полоса пропускания соответствует примерно 800 точкам. Для информации о цвете — по вертикали в 2 раза худшие, по горизонтали — в 5-6.

------------
Ругать MS за шрифты вообще смешно. Когда графические интерфейсы завоевывали популярность разниа в стоимости 14" и 15" мониторов была чуть ли не в 2 раза. 19" мониторы стоили целое состояние. MS элементарно собрали требования к актуальным характеристикам своего времени и воплотили их.

------------
Кстати, сама архитектура Windows никак не ограничивает собственные механизмы рендеринга шрифтов. Бери какой-нить рендерер и рендери сам.

Здравствуйте, AndrewVK, Вы писали:

AVK>Здравствуйте, GlebZ, Вы писали:

GZ>>Я бы сказал так. Если человеческий глаз не будет отличать линию нарисованную одним пикселем, и двумя пикселями, то это начало новой эпохи.

AVK>На VGA PDA что то близкое наблюдается.
Я читал как-то по VGA КПК адобовские документы. Буквы там кривые. У меня (не VGA) кривее кривых.

С уважением, Gleb.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Здравствуйте, GlebZ, Вы писали:

AVK>>На VGA PDA что то близкое наблюдается.
GZ>Я читал как-то по VGA КПК адобовские документы.

Запустил, посмотрел. Кривизны особой не наблюдаю.

... << RSDN@Home 1.2.0 alpha rev. 617>>

Здравствуйте, AndrewVK, Вы писали:

AVK>Здравствуйте, GlebZ, Вы писали:

AVK>>>На VGA PDA что то близкое наблюдается.
GZ>>Я читал как-то по VGA КПК адобовские документы.

AVK>Запустил, посмотрел. Кривизны особой не наблюдаю.
Нее, особая кривизна это у меня

. Буквы разные по размеру даже в одном слове. Я специально смотрел у друзей на VGA, как бы значительно лучше, но все равно присутствует. Пока не присмотришся не увидишь.

С уважением, Gleb.
ЗЫ Это Adobe Reader 2.0 for Pocket PC.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Здравствуйте, vdimas, Вы писали:

V>Предположим, что у тебя разрешение 8000x6000. Минимальная частота развертки, моргания от которой абсолютно не заметно глазом — более 200 Гц (!!!, а не 100Гц, как думают некоторые). Насколько я понял, частота развертки стоит раньше по приоритетам?

Интересно, откуда эти басни про 200 герц? Кому нужна такая частота? Я долгое время жил на CRT 75 герц. Это чуть маловато, но уже приемлемо. На практике 100 герц — вполне достаточно. Это для CRT. Все LCD по цифровому DVI работают на 60 герцах. За счет инерционности LCD, ни малейшего мерцания просто не существует. Возможно, что эти байки идут от думеров-квакеров, которым подавай 200 FPS? Но там и не надо никаких 8000x6000.
Шизнутые аудиофилы якобы слышат разницу в звуке, когда заменяют провод от усилителя к розетке специальным "аудиофильским" за 100 баксов. 200 герц развертки — это примерно из той же оперы.

V>Теперь попытайся спроектировать либо цифровую либо аналоговую систему передачи данных на монитор с такими параметрами.

Безусловно, канал должен быть очень широким. Но нам не обязательно каждую 1/60 секунды гнать весь кадр, как это делается сейчас.
Повторюсь.
http://www.rsdn.ru/Forum/Message.aspx?mid=1410129&only=1

Можно представить себе следующую схему (я, кстати говоря, еще лет 15 назад о такой мечтал). У нас есть светодиодная матрица 8000x6000. Под каждым пикселом находится маленький процессор и сотня байт памяти. Этот процессор умеет выполнять операцию AlphaBlend. В продвинутых случаях — остальные color compositing операции. Управляются эти процессоры строчно-столбцовым способом. Типа "открыть порт для передачи данных по всей строке номер 1343 — передать данные в колонку 2345". Таким образом мы засветили один пиксел. Закраска прямоугольника 1000x1000 при этом требует не миллион итераций, а всего-навсего 1000+1000. Anti-aliasing при таком разрешении нам не нужен и это сильно упрощает дело. Кроме того, каждый пиксел может сам себе быть альфа-маской и/или z-буфером.

V>Ругать MS за шрифты вообще смешно. Когда графические интерфейсы завоевывали популярность разниа в стоимости 14" и 15" мониторов была чуть ли не в 2 раза. 19" мониторы стоили целое состояние. MS элементарно собрали требования к актуальным характеристикам своего времени и воплотили их.

Хинты TrueType были актуальны во времена 16 цветов, когда ни о каком сглаживании не было и речи. Как только появилось сглаживание, "агрессивность" хинтов можно было бы сразу поубавить в угоду возможности свободного масштабирования. Кстати говоря, даже для чисто черно-белого рисования вполне достаточно Type I. Берем тот же Acrobat и выключаем сглаживание — текст выглядит нормально. Возможно, несколько хуже, чем TrueType без сглаживания, но вполне приемлемо. Но с появлением ClearType, агрессивность хинтов только возросла. В ClearType — вообще можно сказать, что линии в буквах приколачиваются гвоздями. Раз уж я завел об этом речь, ClearType — это вещь в себе. Это не технология рендеринга, ClearType жестко завязан на сами шрифты. В составе словаря MultiLex есть шрифт PhoneticTM, сделанный по старым правилам. Вот он: http://antigrain.com/stuff/PHONTM__.TTF Так вот, WinXP отказывается рисовать этот шрифт с ClearType как ни крути, хотя с обчным grayscale сглаживанием — рисуется. Следовательно, не каждый шрифт поддерживает "ClearType-ность". Получается, что "хотите ClearType — пользуйтесь нашими шрифтами". Я считаю правила такой игры нечестными — это та же профанация.

V>Кстати, сама архитектура Windows никак не ограничивает собственные механизмы рендеринга шрифтов. Бери какой-нить рендерер и рендери сам.

Адоба именно так и делает. Но ведь массовое сознание определяется именно тем, что предоставлено в виде базовых средств, разве не так? И это очень большая ответственность на самом деле. Настолько большая, что никакие прибыли не могут служить оправданием подобной профанации.

Здравствуйте, AndrewVK, Вы писали:

MS>>SVG — генерируется элементарно, но почти ничем не отображается (Adobe SVG не в счет — это такая дырища в security, что лучше не ставить).

AVK>FF 1.5 умеет

Поставил, посмотрел. "Полный аццтой". Паттерны не рисует вообще, маркеры — очень криво. С производительностью — просто беда. SVG-файл, размером в 700K рендерился 10 секунд (чертеж, состоящий в основном из одних линий и текста). При этом отъел более 20 мег памяти (почти тридцатикратный перерасход!). Я умею парсить и рисовать этот файл менее чем за секунду с памятью меньше мега.

Ждем XAML, может он скажет веское слово. Хотя надежды мало — очень уж там все навороченное.
Вообще, мне очень не нравится эта тенденция — типа, "вот у нас векторная графика". Но на практике это только размахивание флагом. Как только попросишь нарисовать что-то серьезное, так сразу и кирдык.

Ну, когда true type появлялся, негласно признавалось, что он не супер, postscript лучше. Просто тогда Adobe кормилась за счет postscript и не дала бы использовать его и элементы его технологии в виндоус. Шрифтовые дела уже много лет оттачивались на тот момент, Postcript был близок к оптимуму. MS именно придумывала что-то радикально отличное postscript, т.е. фактически от оптимума. Винды еще тащат груз, который был внесен в доисторическую эпоху какими-то недалекими разработчиками. Кому-то когда-то показалось умным мерить UI-объекты Windows в dlu — dialog units (это 1/4 системного шрифта по горизонтали и 1/8 по вертикали). Кто-то поумничал, и вот теперь мы так живем.

Здравствуйте, McSeem2, Вы писали:

MS>Ждем XAML, может он скажет веское слово.

Не жди. XAML это не формат векторной графики. Это вобще, по большому счету, формат сериализации почти произвольных объектов.

MS> Хотя надежды мало — очень уж там все навороченное.

Скорее наоборот — там слишком все примитивно.

MS>Вообще, мне очень не нравится эта тенденция — типа, "вот у нас векторная графика". Но на практике это только размахивание флагом. Как только попросишь нарисовать что-то серьезное, так сразу и кирдык.

В случае XAML все возможности по рисованию на 100% определяются набором реализаций dependency object.

... << RSDN@Home 1.2.0 alpha rev. 617>>

Здравствуйте, AndrewVK, Вы писали:

AVK>Не жди. XAML это не формат векторной графики. Это вобще, по большому счету, формат сериализации почти произвольных объектов.

Как так? Они выдают его за некое "всеобщее щасте" — замена HTML+PDF+Flash в одном флаконе.

Using the XAML file format, organizations will no longer be required to support multiple languages, such as HTML, Flash and PDF. The marriage of XAML and WPF allow for 2D and 3D imaging, animation, audio, video, multipage fixed format and flow format documents. XAML and WPF delivers quick and economical 2D and 3D vector based application and web user interfaces. The XAML file format works great in delivering revolutionary web sites and can also be used in .NET Applications.

AVK>Скорее наоборот — там слишком все примитивно.

Что имеется в виду под "примитивно"? Возможна ли хотя бы замена растровых иконок векторными XAML-файлами (произвольно масштабируемыми)?
Кстати, я уже спрашивал — где бы взять более-менее полную спецификацию XAML, хотя бы драфт? Может это я такой неврубастый, но что-то не находится.

MS>>Вообще, мне очень не нравится эта тенденция — типа, "вот у нас векторная графика". Но на практике это только размахивание флагом. Как только попросишь нарисовать что-то серьезное, так сразу и кирдык.

AVK>В случае XAML все возможности по рисованию на 100% определяются набором реализаций dependency object.

Можно об этом поподробнее? Или скажем так — может оно нарисовать файл с векторной 2D графикой, объемом в 30 мег и при этом не требовать пары гиг памяти?

Вообще, сдается мне, что в случае с SVG FireFox основное время тратится не на рендеринг как таковой, а на сканирование DOM-контейнера, с распарсиванием строк на лету. Просто я знаю, что в качестве backend там используется Cairographics, а он достаточно шустрый, хоть и примитивный (мой основной конкурент). Но если так, то это полный маздай. Рендеринг — по идее самая вычислительно дорогая операция, но просто не отсвечивает среди этого XML-DOM хлама.

У меня — свой псевдо-DOM, в бинарном виде. И он работает на порядок быстрее и ест на порядок меньше памяти, чем любой традиционный XML-DOM.

Здравствуйте, McSeem2, Вы писали:

AVK>>Не жди. XAML это не формат векторной графики. Это вобще, по большому счету, формат сериализации почти произвольных объектов.

MS>Как так?

А вот так

MS>The marriage of XAML and WPF allow for 2D and 3D imaging, animation, audio, video, multipage fixed format and flow format documents. XAML and WPF delivers quick and economical 2D and 3D vector based application and web user interfaces.

Вот так — XAML и WPF. XAML это формат сериализации, в WPF есть набор классов, реализующих векторную графику. Можешь написать свой вариант — будет XAML and AGG.

AVK>>Скорее наоборот — там слишком все примитивно.

MS>Что имеется в виду под "примитивно"?

То, что хотелось бы несколько более гибкие возможности. В частности ограничивать scope attached свойств или возможность управления маппингом классов на теги.

MS> Возможна ли хотя бы замена растровых иконок векторными XAML-файлами (произвольно масштабируемыми)?

В XAML нет понятия иконки.

MS>Кстати, я уже спрашивал — где бы взять более-менее полную спецификацию XAML, хотя бы драфт? Может это я такой неврубастый, но что-то не находится.

Скачиваешь WinFX SDK, ставишь. В хелпе получаешь несколько статей по структуре и принципам организации XAML и class reference по WPF.

AVK>>В случае XAML все возможности по рисованию на 100% определяются набором реализаций dependency object.

MS>Можно об этом поподробнее? Или скажем так — может оно нарисовать файл с векторной 2D графикой, объемом в 30 мег и при этом не требовать пары гиг памяти?

XAML не может ничего рисовать. Что касаемо конкретных классов WPF — не знаю, не пробовал.

MS>Вообще, сдается мне, что в случае с SVG FireFox основное время тратится не на рендеринг как таковой, а на сканирование DOM-контейнера, с распарсиванием строк на лету.

Ну это вряд ли. Парсинг XML на современных процессорах это ничтожно мало, даже если его через задницу делать. Скорее всего проблема в позиционировании и рассчете координат.

MS>У меня — свой псевдо-DOM, в бинарном виде. И он работает на порядок быстрее и ест на порядок меньше памяти, чем любой традиционный XML-DOM.

XAML десериализует прямо в отрисовывающие компоненты.

... << RSDN@Home 1.2.0 alpha rev. 617>>

Здравствуйте, AndrewVK, Вы писали:

MS>>Кстати, я уже спрашивал — где бы взять более-менее полную спецификацию XAML, хотя бы драфт? Может это я такой неврубастый, но что-то не находится.

AVK>Скачиваешь WinFX SDK, ставишь. В хелпе получаешь несколько статей по структуре и принципам организации XAML и class reference по WPF.
AVK>XAML не может ничего рисовать. Что касаемо конкретных классов WPF — не знаю, не пробовал.

Спасибо за информацию. Но все-таки, документ-то существует в природе вообще? Для PDF — есть, для SVG — есть, для Flash-SWF — есть. А для XAML?

MS> Возможна ли хотя бы замена растровых иконок векторными XAML-файлами (произвольно масштабируемыми)?
AVK>В XAML нет понятия иконки.

Я говорю вот о чем: Есть у нас на десктопе иконка, скажем "My Computer" и прочие. Сейчас они банально растровые. Возможна ли в будущем замена этого растрового безобразия на векторые XAML-файлы с возможностью произвольного масштабирования в зависимости от DPI монитора?

MS>>Вообще, сдается мне, что в случае с SVG FireFox основное время тратится не на рендеринг как таковой, а на сканирование DOM-контейнера, с распарсиванием строк на лету.

AVK>Ну это вряд ли. Парсинг XML на современных процессорах это ничтожно мало, даже если его через задницу делать. Скорее всего проблема в позиционировании и рассчете координат.

Я работаю над проектом Renesis http://gosvg.net. И моя практика показывает, что распарсить 30 мег XML на моем древнем P4-1.9 занимает примерно 16 секунд (это с Expat, MS-XML, Xerces — немного быстрее). А нарисовать всю сцену — около 3 секунд:
http://antigrain.com/stuff/svg/arbeitskopie_esv1.jpg
http://antigrain.com/stuff/svg/arbeitskopie_esv2.png
http://antigrain.com/stuff/svg/arbeitskopie_esv3.png

Все числовые значения у меня хранятся в виде float/double. В стантартной схеме XML-DOM мы вынуждены хранить все значения в строках, поскольку этот DOM ничего не знает о сущности данных. Простое сканирование (traverse) этого DOM (а он раздувается в памяти до 200-400 мег) уже занимает порядка 10 секунд. А при этом нам приходится еще парсить строки и превращать их в числовые значения. Так что собственно рисование — это 10-15% всего времени. Это полный маздай. Доложно быть 90%. В общем, модель хранения данных в виде XML DOM не является жизнеспособной для графики, но пока что все имплементации SVG используют именно ее — Adobe SVG, KSVG (кстати, в KSVG используется AGG), FireFox. Именно поэтому у меня есть сомнения в жизнеспособности SVG вообще. Наворотили монстра, которого никто не может толком имплементировать. Вот Макромедию я очень уважаю — взяли и сделали стандарт де-факто, без лишних ковыряний в носу. Но модель данных там очень уж нетривиальная — что для генерации, что для рисования.

AVK>XAML десериализует прямо в отрисовывающие компоненты.

Что это означает на практике? Генерируется код MSIL? Сколько памяти будут занимать, скажем 10000 окружностей?
В любом существующем SVG — это ж... полная. Десятикратный и более перерасход (ну, кроме моего, который пока что в стадии эмбриона). Как с этим обстоят дела в XAML/WPF? Какие-то меня гложут сомнения по поводу эффективности модели данных.

Здравствуйте, McSeem2, Вы писали:

MS>Что это означает на практике? Генерируется код MSIL? Сколько памяти будут занимать, скажем 10000 окружностей?
MS>В любом существующем SVG — это ж... полная. Десятикратный и более перерасход (ну, кроме моего, который пока что в стадии эмбриона). Как с этим обстоят дела в XAML/WPF? Какие-то меня гложут сомнения по поводу эффективности модели данных.

Я не специалист, но на всякий случай ... Xara стала open-source, может взять .xar?
http://www.xara.com/support/docs/webformat/spec/

The Xar file format, previously known as the Flare file format, is an ultra-compact, open, vector graphic format. It is also the native graphics format for Xara X application (and also its predecessors such as CorelXARA).

The document below describes the format in detail and provides information for third parties interested in converting to or from this graphics format.

Why another vector graphics format? The Xar file format is not new. It dates back nearly ten years and so it predates more recent formats such as SVG. It is not designed to compete with SVG, but Xar files are considerably simpler to understand (the SVG spec is 700 pages) and, more compact (often 10:1). However the primary reason for the existence of the open file format specification is to enable third parties to read and write the Xara X native files.

Здравствуйте, McSeem2, Вы писали:

AVK>>XAML не может ничего рисовать. Что касаемо конкретных классов WPF — не знаю, не пробовал.

MS>Спасибо за информацию. Но все-таки, документ-то существует в природе вообще? Для PDF — есть, для SVG — есть, для Flash-SWF — есть. А для XAML?

Документ о чем?

MS>> Возможна ли хотя бы замена растровых иконок векторными XAML-файлами (произвольно масштабируемыми)?
AVK>>В XAML нет понятия иконки.

MS>Я говорю вот о чем: Есть у нас на десктопе иконка, скажем "My Computer" и прочие. Сейчас они банально растровые. Возможна ли в будущем замена этого растрового безобразия на векторые XAML-файлы с возможностью произвольного масштабирования в зависимости от DPI монитора?

А при чем тут XAML? В Vista можно будет векторные иконки делать. Про формат ничего не знаю.

AVK>>Ну это вряд ли. Парсинг XML на современных процессорах это ничтожно мало, даже если его через задницу делать. Скорее всего проблема в позиционировании и рассчете координат.

MS>Я работаю над проектом Renesis http://gosvg.net. И моя практика показывает, что распарсить 30 мег XML на моем древнем P4-1.9 занимает примерно 16 секунд (это с Expat, MS-XML, Xerces — немного быстрее). А нарисовать всю сцену — около 3 секунд:

Утянуть такой XML где нибудь можно?

MS>Все числовые значения у меня хранятся в виде float/double. В стантартной схеме XML-DOM мы вынуждены хранить все значения в строках, поскольку этот DOM ничего не знает о сущности данных.

А зачем вобще DOM? Он большие объемы не любит. Такие вещи нужно напрямую с потока обрабатывать.

MS>В общем, модель хранения данных в виде XML DOM не является жизнеспособной для графики,

Графика тут не при чем. Проблема в объемах. До 5 мег где то, на современных машинах вполне приемлемо. Если больше — DOM не подходит.

AVK>>XAML десериализует прямо в отрисовывающие компоненты.

MS>Что это означает на практике?

Это означает как минимум никакого DOM, все парсится прямо в целевую модель. Кроме того, для хранения, передачи и интерпретации чаще используется не XAML, а BAML (B — binary).

MS> Генерируется код MSIL?

В ранних реализациях генерировался. В теперешних нет, используется BAML, который затем интерпретируется.

MS> Сколько памяти будут занимать, скажем 10000 окружностей?

ХЗ. Если время будет попробую провести эксперимент.

MS>В любом существующем SVG — это ж... полная. Десятикратный и более перерасход (ну, кроме моего, который пока что в стадии эмбриона).

Оптимизированные версии DOM имеют коэффициент в районе 7. Но, в любом случае, хранить в DOM десятки мег XML плохая идея.

MS> Как с этим обстоят дела в XAML/WPF? Какие-то меня гложут сомнения по поводу эффективности модели данных.

В XAML нет модели данных как таковой — модель определяется поставщиком реализаций.

... << RSDN@Home 1.2.0 alpha rev. 617>>

Здравствуйте, AndrewVK, Вы писали:

MS>>Спасибо за информацию. Но все-таки, документ-то существует в природе вообще? Для PDF — есть, для SVG — есть, для Flash-SWF — есть. А для XAML?

AVK>Документ о чем?

Спецификация XAML+WPF. Что-то аналогичное SVG: http://www.w3.org/TR/SVG11/
Грубо говоря, как там квадратики рисовать, градиенты задавать, паттерны всякие. Но еще раз повторюсь, мне бы хотелось посмотреть именно спецификацию, примеры мне мало интересны.

AVK>Утянуть такой XML где нибудь можно?
http://antigrain.com/esv/arbeitskopie.zip
Файл — жутко неоптимальный. Это он специально такой

Еще маленький примерчик, http://antigrain.com/esv/recursive_pattern.svg
Валит все SVG рендереры, которые яко бы умеют рисовать паттерны. Можно нечто подобное сделать на XAML?

AVK>А зачем вобще DOM? Он большие объемы не любит. Такие вещи нужно напрямую с потока обрабатывать.

В принципе у меня так и делается. Но данные все равно надо где-то хранить, в каком-нибудь виде. Причем, весь файл. Если бы не было ссылок (причем, ссылки вперед — нормальное явление в XML), то можно было бы вообще обойтись SAX-парсером, который сразу бы растеризовал данные и требовал O(1) памяти. Но это было бы медленнее чем с неким промежуточным компактным контейнером. Фактически, контейнер у меня — это тот же XML (сплошной поток в памяти), но в бинарном виде. Поскольку он все знает про SVG, то "бинаризация" не представляет никакой проблемы. И при отрисовке этот поток "проигрывается" тоже в SAX-режиме (там еще присутствует ссылочный индекс для быстрой навигации, но это уже не важно).

AVK>В ранних реализациях генерировался. В теперешних нет, используется BAML, который затем интерпретируется.
MS>> Сколько памяти будут занимать, скажем 10000 окружностей?
AVK>ХЗ. Если время будет попробую провести эксперимент.

Было бы замечательно. И сколько времени оно будет рисоваться.

MS>> Как с этим обстоят дела в XAML/WPF? Какие-то меня гложут сомнения по поводу эффективности модели данных.
AVK>В XAML нет модели данных как таковой — модель определяется поставщиком реализаций.

В вопросе был XAML/WPF, а не просто XAML. WPF, как я понимаю, и есть некая реализация.

Здравствуйте, McSeem2, Вы писали:

AVK>>Документ о чем?

MS>Спецификация XAML+WPF.

Спецификация WPF называется class reference — неймспейсы System.Windows.*. Вот, например, упомянутая тобой окружность:
ms-help://MS.WinFXSDK.1033/Cpref/html/T_System_Windows_Shapes_Ellipse.htm

Ellipse Class
[This topic is pre-release documentation and is subject to change in future releases. Blank topics are included as placeholders.]
Draws an ellipse.

Namespace: System.Windows.Shapes
Assembly: PresentationFramework (in presentationframework.dll)

Syntax
Visual Basic (Declaration) 
Public NotInheritable Class Ellipse
    Inherits Shape
 
Visual Basic (Usage) 
 
C# 
public sealed class Ellipse : Shape
 
C++ 
public ref class Ellipse sealed : public Shape
 
J# 
public final class Ellipse extends Shape
 
JScript 
public final class Ellipse extends Shape
 
"XAML" 
<Ellipse .../>
Example
This example shows how to draw ellipses and circles using the Ellipse element. To draw an ellipse, create an Ellipse element and specify its Width and Height. Use its Fill property to specify the Brush used to paint its interior. Use its Stroke property to specify the Brush used to paint its outline. The StrokeThickness property specifies the thickness of the outline. To draw a circle, make the Ellipse element's Width and Height equal to each other.

In the following example, four Ellipse elements are drawn within a Canvas.

"XAML"
<Canvas Height="200" Width="200">
  
  
  <Ellipse
    Width="100"
    Height="50"
    Fill="Blue"
    Canvas.Left="10"
    Canvas.Top="25" />

  
  <Ellipse
    Width="100"
    Height="50"
    Fill="Blue"
    Stroke="Black"
    StrokeThickness="4"
    Canvas.Left="10"
    Canvas.Top="100"/>

  
  <Ellipse
    Width="50"
    Height="50"
    Fill="Blue"
    Canvas.Left="135"
    Canvas.Top="25"/>

  
  <Ellipse
    Width="50"
    Height="50"
    Stroke="Black"
    StrokeThickness="4"
    Canvas.Left="135"
    Canvas.Top="100" />

</Canvas>
Although a Canvas is used to contain the ellipses in this example, ellipse elements (and all the other shape elements) may be used with any Panel or Control that supports non-text content.

This example is part of a larger sample; for the complete sample, see Shape Elements Sample.

More Code
Paint an Area with a Solid Color This example shows several ways to use the SolidColorBrush class to paint an area with a solid color.

Inheritance Hierarchy
System.Object 
   System.Windows.Threading.DispatcherObject 
     System.Windows.DependencyObject 
       System.Windows.Media.Visual 
         System.Windows.Media.OnDemandVisual 
           System.Windows.UIElement 
             System.Windows.FrameworkElement 
               System.Windows.Shapes.Shape 
                System.Windows.Shapes.Ellipse
Thread Safety
Any public static (Shared in Visual Basic) members of this type are thread safe. Any instance members are not guaranteed to be thread safe.

Устроит?
Что же касается XAML, то именно референса нет ни в SDK (пишет что топик не найден), ни в вебе (http://winfx.msdn.microsoft.com/library/default.asp?url=/library/en-us/wcp_conceptual/html/a2df53ab-66d3-4b91-80e8-df0709ab873f.asp). Зато есть то, что МС называет Programming Model — ms-help://MS.WinFXSDK.1033/Wcp_conceptual/html/56c7fbe0-05b8-4d83-b2f5-ab280dbafa9c.htm

MS>Грубо говоря, как там квадратики рисовать, градиенты задавать, паттерны всякие.

WinFX SDK, я же тебе уже писал. Вот тебе ссылка на него в вебе — http://winfx.msdn.microsoft.com/library/default.asp?url=/library/en-us/cpref/html/H_home.asp.

AVK>>Утянуть такой XML где нибудь можно?
MS>http://antigrain.com/esv/arbeitskopie.zip
MS>Файл — жутко неоптимальный. Это он специально такой

Попозже отпишу

MS>Еще маленький примерчик, http://antigrain.com/esv/recursive_pattern.svg

А чего там должно быть нарисовано? Опера выводит просто черный круг в синеньком квадратике, а других вьюверов у меня под рукой нет.

MS>Валит все SVG рендереры, которые яко бы умеют рисовать паттерны. Можно нечто подобное сделать на XAML?

На XAML можно, на WPF ХЗ.

MS>В принципе у меня так и делается. Но данные все равно надо где-то хранить, в каком-нибудь виде.

Ну так и хранить в том виде, который нужен для отрисовки. XAML именно так и работает.

MS> Причем, весь файл. Если бы не было ссылок (причем, ссылки вперед — нормальное явление в XML), то можно было бы вообще обойтись SAX-парсером, который сразу бы растеризовал данные и требовал O(1) памяти. Но это было бы медленнее чем с неким промежуточным компактным контейнером. Фактически, контейнер у меня — это тот же XML (сплошной поток в памяти), но в бинарном виде. Поскольку он все знает про SVG, то "бинаризация" не представляет никакой проблемы.

Ну абсолютно логичное решение. Непонятно зачем делать иначе.

MS>Было бы замечательно.

Только текущему WinFX нужен beta 2, а у меня стоит RC. Жду когда с релизами утрясется.

AVK>>В XAML нет модели данных как таковой — модель определяется поставщиком реализаций.

MS>В вопросе был XAML/WPF, а не просто XAML. WPF, как я понимаю, и есть некая реализация.

Да.

... << RSDN@Home 1.2.0 alpha rev. 617>>

Здравствуйте, AndrewVK, Вы писали:

AVK>WinFX SDK, я же тебе уже писал. Вот тебе ссылка на него в вебе — http://winfx.msdn.microsoft.com/library/default.asp?url=/library/en-us/cpref/html/H_home.asp.

Спасибо, Андрей. Подход c документацией у них конечно несколько своеобразный, но тоже имеющий право на жизнь.

MS>>http://antigrain.com/esv/arbeitskopie.zip
MS>>Файл — жутко неоптимальный. Это он специально такой

AVK>Попозже отпишу

Ждемс. Можешь его сконвертить в XAML и попробовать нарисовать? Жутко интересно. Просто у меня сейчас нет возможности все эти беты и SDK ставить.

MS>>Еще маленький примерчик, http://antigrain.com/esv/recursive_pattern.svg

AVK>А чего там должно быть нарисовано? Опера выводит просто черный круг в синеньком квадратике, а других вьюверов у меня под рукой нет.

Ну значит, опера не обрабатывает паттерны вообще. Я помню чуть мозг сломал, пока разобрался со всеми этими трансформациями.
Должен быть красивый "фрактал":
http://antigrain.com/esv/recursive_pattern.png

MS>> Причем, весь файл. Если бы не было ссылок (причем, ссылки вперед — нормальное явление в XML), то можно было бы вообще обойтись SAX-парсером, который сразу бы растеризовал данные и требовал O(1) памяти. Но это было бы медленнее чем с неким промежуточным компактным контейнером. Фактически, контейнер у меня — это тот же XML (сплошной поток в памяти), но в бинарном виде. Поскольку он все знает про SVG, то "бинаризация" не представляет никакой проблемы.

AVK>Ну абсолютно логичное решение. Непонятно зачем делать иначе.

Ну не совсем, на самом деле. Например, SVG — это XML. И в спецификации заявлено, что там может присутствовать возможность XSLT трансляции. Причем, конечный результат этой трансляции — не другой сгенерированный файл, а непосредственно нарисованная картинка. И все это должно делаться на лету. Если пользоваться стандартным DOM, транслятор у нас уже есть. И мы просто напускаем его на исходный DOM после загрузки, после чего рисуем. Но это жутко неэффективно. А если у нас свой велосипед в бинарном представлении, то получается, что надо и транслятор самим писать. Жуть! Либо же отказаться от поддержки XSLT вообще. Apache Xalan вроде бы как позволяет выполнять трансляцию в потоке, но как я слабо себе представляю, как такое возможно.
Ну и есть некоторые другие "мелочи", неявно предполагающие использование натурального XML DOM. Вообще, там много нелепостей нагорожено.

Здравствуйте, McSeem2, Вы писали:

MS>Спасибо, Андрей. Подход c документацией у них конечно несколько своеобразный, но тоже имеющий право на жизнь.

Нормальный подход, я бы сказал классический. Просто ты, похоже, так и не понял до конца что такое XAML

.

AVK>>Попозже отпишу

MS>Ждемс.

Отписываю. Результаты тестов (Cel 2.4, 1Gb RAM)

File read: 65ms
XmlReader read: 669ms
XmlDocument read: 3169ms
XmlSerializer read: 2694ms

Выводы:
1) Тот парсер, что ты глядел, никуда не годится. Нетовский управляется с твоим файлом на сопоставимой машине на порядок быстрее.
2) DOM в 5 раз быстрее последовательного парсинга, что вполне ожидаемо.
3) Последовательное чтение в специализированную модель заметно быстрее DOM, даже при том что в тесте float-переменные в спец. модели парсились. Ну и 2.5 секунды на 30М файл на весьма средненькой машинке вполне приемлемо, не находишь?
По поводу памяти ничего сказать не могу, в дотнете это не так то просто померять.

MS>Можешь его сконвертить в XAML и попробовать нарисовать?

Не, на это нужно массу времени. В ближайшее время вряд ли. Но рассчитывать на то, что ранние беты WPF что то из себя представляют в плане производительности не стоит.

MS>Ну не совсем, на самом деле. Например, SVG — это XML. И в спецификации заявлено, что там может присутствовать возможность XSLT трансляции.

Ну тогда при первом сканировании, если встретится такая бякость, то кусок для преобразований грузить таки в DOM. Причем этот DOM может быть оптимизирован под задачи XSTL-трансформации. Например в том же тесте:

XPathDocument read: 2188ms

Видишь, вполне приемлемо. Ну а результат трансформации без преобразования к тексту напрямую конвертируем в нашу модель.

MS> Причем, конечный результат этой трансляции — не другой сгенерированный файл, а непосредственно нарисованная картинка. И все это должно делаться на лету. Если пользоваться стандартным DOM, транслятор у нас уже есть. И мы просто напускаем его на исходный DOM после загрузки, после чего рисуем. Но это жутко неэффективно. А если у нас свой велосипед в бинарном представлении, то получается, что надо и транслятор самим писать.

В дотнете трансформер умеет работать по любому иерархическому источнику данных, лишь бы для него была реализация XPathNavigator (иерархический ДКА — курсор). Другое дело что исходные данные могут быть произвольным xml, а не svg, а в этом случае все равно кроме DOM ты ничего лучше не придумаешь.

... << RSDN@Home 1.2.0 alpha rev. 617>>

Здравствуйте, AndrewVK, Вы писали:

AVK>Выводы:
AVK>1) Тот парсер, что ты глядел, никуда не годится. Нетовский управляется с твоим файлом на сопоставимой машине на порядок быстрее.
AVK>2) DOM в 5 раз быстрее последовательного парсинга, что вполне ожидаемо.
AVK>3) Последовательное чтение в специализированную модель заметно быстрее DOM, даже при том что в тесте float-переменные в спец. модели парсились. Ну и 2.5 секунды на 30М файл на весьма средненькой машинке вполне приемлемо, не находишь?
AVK>По поводу памяти ничего сказать не могу, в дотнете это не так то просто померять.

Вот облом! Это же самое главное и есть. Может быть хотя бы грубую оценку по неким "вторичным половым признакам"?
Я согласен, Expat, Xerces, и прочие — довольно тормозные парсеры. Но в случае собственной модели данных это не так уж и критично. То, что "натуральтный" DOM сканируется быстро, это конечно хорошо (и я вполне верю, что Xerces DOM гораздо медленнее). Но кроме сканирования там возникает куча другой работы, например, распaрсить SVG path — уже достаточно дорогая операция.

MS>>Можешь его сконвертить в XAML и попробовать нарисовать?

AVK>Не, на это нужно массу времени. В ближайшее время вряд ли. Но рассчитывать на то, что ранние беты WPF что то из себя представляют в плане производительности не стоит.

Вот, например, есть: http://workspaces.gotdotnet.com/svg2xaml но у меня нет пока возможнгости поставить все необходимые приблуды.
Насколько я понимаю, все рендереры пока что основаны на GDI+, который даже кубические кривые не умеет толком рисовать (промахивается иногда мимо конечной точки на 1-2 пиксела, выглядит очень смешно).

AVK>В дотнете трансформер умеет работать по любому иерархическому источнику данных, лишь бы для него была реализация XPathNavigator (иерархический ДКА — курсор). Другое дело что исходные данные могут быть произвольным xml, а не svg, а в этом случае все равно кроме DOM ты ничего лучше не придумаешь.

Дак в том-то и дело, что XSLT для графики по большому счету на фиг не уперлось (IMO). Конечно, это кое-что дает, может быть даже достаточно много. Но в реальности эти рендереры, сделанные по типу Adobe SVG или FireFox, именно из за этой навороченности и становятся малопригодными на практике. Эта общая монстроузность реально губит SVG и создает ему нехорошую репутацию. Что ни говори, но 20 мег памяти на 700K файл (весьма "рыхлый", надо сказать) — это перебор.

Здравствуйте, McSeem2, Вы писали:

MS>Вот облом! Это же самое главное и есть. Может быть хотя бы грубую оценку по неким "вторичным половым признакам"?

В понедельник посмотрю, если не забуду. Могу только сказать, что за счет NameTable нетовский DOM расходует память довольно экономно. Что же касается варианта с XmlSerializer, то он расходует память настолько мало, насколько это вобще возможно в .NET при сохранении структуры.

MS>Я согласен, Expat, Xerces, и прочие — довольно тормозные парсеры. Но в случае собственной модели данных это не так уж и критично.

Ну я бы не сказал. По тесту видно, что собственно парсинг составляет 25% веремени. Довольно ощутимо.

MS>Но кроме сканирования там возникает куча другой работы, например, распaрсить SVG path — уже достаточно дорогая операция.

Ну, тут уж тебе никакое стандартное решение не поможет.

MS>Вот, например, есть: http://workspaces.gotdotnet.com/svg2xaml но у меня нет пока возможнгости поставить все необходимые приблуды.

Погляжу как только вйдет WinFX под релиз второго фреймворка.

MS>Насколько я понимаю, все рендереры пока что основаны на GDI+

Нет. Где то с мая они переползли на DirectX.

MS>, который даже кубические кривые не умеет толком рисовать (промахивается иногда мимо конечной точки на 1-2 пиксела, выглядит очень смешно).

На самом деле конкретный рендерер для WPF можно подсунуть свой. Подробнее http://winfx.msdn.microsoft.com/library/default.asp?url=/library/en-us/cpref/html/T_System_Windows_Media_DrawingContext.asp. Так что, при желании, можешь и под AGG заставить работать.

MS>Дак в том-то и дело, что XSLT для графики по большому счету на фиг не уперлось (IMO).

Вот это черт его знает. Видишь ли, SVG не столько векторный формат вобще, сколько векторный формат для веб-страниц. И с этой точки зрения XSLT там вполне нормально, поскольку данные для трансформации могут использоваться и для генерации HTML.

... << RSDN@Home 1.2.0 alpha rev. 615 on Windows XP 5.1.2600.131072>>

Кто там висту ставил?
Что-ть изменилось?

[RSDN@Home][1.2.0][alpha][655]
[Главнейшая дорога человеческого воспитания есть убеждение. [К. Д. Ушинский]]

Здравствуйте, McSeem2, Вы писали:

[...]

Прошло чуть больше года. И, вот, кажется началось:
http://hard.compulenta.ru/291229/

Поздравляю всех участников с началом новой гонки.

Здравствуйте, WoldemaR, Вы писали:

WR>Прошло чуть больше года. И, вот, кажется началось:
WR>http://hard.compulenta.ru/291229/

WR>Поздравляю всех участников с началом новой гонки.

Ну, это уже нечто, 165 dpi. Еще столько же, и мы перешагнем заветный порог в 300dpi, когда анти-алиасинг можно будет списать на помойку истории. Хотя без AA кроме лестниц возникают сложности с так называемым tie-breaking rules.

Здравствуйте, McSeem2, Вы писали:

MS>Ну, это уже нечто, 165 dpi. Еще столько же, и мы перешагнем заветный порог в 300dpi, когда анти-алиасинг можно будет списать на помойку истории. Хотя без AA кроме лестниц возникают сложности с так называемым tie-breaking rules.

А как это по-русски?

Я прикалываюсь над другим эффектом. — В 3Д сцене все элементы оказываются в фокусе, нет размазанности граней при удалении. Как — то это должно по крутому называться. И как то оно должно компенсироваться при рендеринге. —

Никто не в курсе?

Здравствуйте, WoldemaR, Вы писали:
WR>Я прикалываюсь над другим эффектом. — В 3Д сцене все элементы оказываются в фокусе, нет размазанности граней при удалении. Как — то это должно по крутому называться.
Это ты про бесконечную глубину резкости?
WR>И как то оно должно компенсироваться при рендеринге. —
А, собственно, зачем?
Конечность глубины резкости, вообще говоря, это баг аппаратуры человеческого зрения. Она может применяться в кино/фото/видеоискусстве как художественный прием, для концентрации внимания на чем-то.
В техническом UI ей в общем-то делать нечего.

1.2.0 alpha rev. 655

> MS>Ну, это уже нечто, 165 dpi. Еще столько же, и мы перешагнем заветный порог в 300dpi, когда анти-алиасинг можно будет списать на помойку истории. Хотя без AA кроме лестниц возникают сложности с так называемым tie-breaking rules.
>
> А как это по-русски?
>
> Я прикалываюсь над другим эффектом. — В 3Д сцене все элементы оказываются в фокусе, нет размазанности граней при удалении. Как — то это должно по крутому называться. И как то оно должно компенсироваться при рендеринге. —
>
> Никто не в курсе?

Туману равномерного напусти, будет получше выглядеть. Но заметно медленней.

Posted via RSDN NNTP Server 2.0

> Здравствуйте, WoldemaR, Вы писали:
> WR>Я прикалываюсь над другим эффектом. — В 3Д сцене все элементы оказываются в фокусе, нет размазанности граней при удалении. Как — то это должно по крутому называться.
> Это ты про бесконечную глубину резкости?
> WR>И как то оно должно компенсироваться при рендеринге. —
> А, собственно, зачем?
> Конечность глубины резкости, вообще говоря, это баг аппаратуры человеческого зрения.

Речь идет явно не о том, что обычно называется "глубиной резкости". Конечность глубины резкости человек вообще редко воспринимает (ну разве что при стрельбе без оптики она мешает), поскольку глаз всегда фокусируется на том предмете, который человек в данный момент разглядывает.

> Она может применяться в кино/фото/видеоискусстве как художественный прием, для концентрации внимания на чем-то.
> В техническом UI ей в общем-то делать нечего.

Еще как есть чего. Без такого "бага" расстояние до предметов оценить сложнее.

Posted via RSDN NNTP Server 2.0

Смотрю, эта тема снова всплыла.

Так вот, имею добавить.
Нижеследующее:

ЗХ>Попробуй объяснить мне (не мне — Зверьку, а "мне" — некоторому среднестатистическому пользователю), зачем мне разрешение 6000х9000 (в условиях обычного монитора)? На графическом устройстве вывода (aka монитор) возможно вывести всего 2 типа информации — текст и графику. Размер выводимого текста ограничен снизу физическими (а не логическими) размерами монитора: даже если монитор способен отобразить текст высотой 1мм — кто станет его читать?

— просьба считать недействительным. В моем сегодняшнем понимании, важна возможность не "вывести текст высотой 1мм", а "вывести две строки текста, высота которых отличается на 1мм". То есть не высокая степень миниатюризации, а гибкость варьирования размера.

Живой пример — весьма модные tag cloud ("облако тегов" — "взвешенный" список всех тегов, которыми помечен контент, где размер каждого тега зависит от частоты его упоминания) — отличная идея, но соврешенно чудовищно выглядит в современных реализациях. А все именно из-за убогости градаций размера шрифтов: чтобы сделать 8-10 ступеней размера (а это не предел), начиная, скажем, с 8 кегля — всё равно получишь "самые популярные теги" кеглем в районе 18-20 — то есть в полмонитора (а попытки избежать это дают "плоское", невыразительное облако). А вот возможность плавно наращивать размер шрифта давала бы как раз искомый эффект.

Так что я приношу свои извинения за поднятую в свое время бучу.

WR>Прошло чуть больше года. И, вот, кажется началось:
WR>http://hard.compulenta.ru/291229/

Такие штуки, и бОльшего разрешения, уже давно выпускают http://www.pcmag.ru/?ID=287915.
Но уж очень узкая область применения.
А меня, например,, по специфике деятельности интересуют мониторы высокого разрешения и немаленьких геометрических размеров, типа такого:
http://www.dell.com/content/products/productdetails.aspx/monitor_3007wfp?c=us&cs=19&l=en&s=dhs
это и более ранние аналоги от Apple уже год-два как доступны.

Здравствуйте, WoldemaR, Вы писали:

WR>Здравствуйте, McSeem2, Вы писали:

WR>[...]

WR>Прошло чуть больше года. И, вот, кажется началось:
WR>http://hard.compulenta.ru/291229/

WR>Поздравляю всех участников с началом новой гонки.

E-Ink дисплей от Plastic Logic с разрешением 150ppi

Экран для "электронной бумаги" произведен в Кембридже, на опытном оборудовании, которое является результатом усилий инженеров компании Plastic Logic за последние 12 месяцев. Намечено массовое производство 10-дюймового 150ppi экрана в 2008 году.

На таком экране уже более-менее читать можно будет. Особенно радостно это будет делать в метро.

Здравствуйте, WoldemaR, Вы писали:

WWR>Прошло чуть больше года. И, вот, кажется началось:
WR>http://hard.compulenta.ru/291229/
WR>Поздравляю всех участников с началом новой гонки.

А вот тут продолжилось:

Прогресс мультимедийных возможностей портативных устройств стимулирует развитие технологий отображения визуальной информации. Подразделением NEC LCD Technologies было доложено о разработке нового 3,5-дюймового LCD-модуля в форм-факторе SOG (system-on-glass, готовая система на стеклянной поверхности) для мобильных устройств. Экран обладает разрешением 960 ? 540 (quarter high definition, QHD), что соответствует более 300 точкам на дюйм. Дисплей такого класса подойдет для использования в профессиональных цифровых видеокамерах в качестве откидного монитора и прекрасно справится с воспроизведением HD-видео.

Хорошие показатели по яркости в 350 кд/кв.м и великолепная цветопередача дисплея были получены путем оптимизации системы задней подсветки и благодаря достоинствам низкотемпературной поликремниевой (low temperature polysilicon, LTPS) LCD-технологии NEC, позволяющей добиться ярких и насыщенных цветов на экранах маленьких размеров. Подобные LTPS LCD-модули могут найти широкое применение в мобильных телефонах, КПК или цифровых фотокамерах, то есть, там, где требуется получить качественное изображение с высоким разрешением на ограниченной площади.

Компания NEC с 1 октября запустила опытное производство новых LCD-модулей. Разработка будет впервые продемонстрирована публике на японской выставке Inter BEE 2006, которая пройдет с 15 по 17 ноября.

... << RSDN@Home 1.2.0 alpha rev. 665>>

От:	McSeem2	http://www.antigrain.com
Дата:	28.09.05 16:34
Оценка:	501 (53) +7 -8

	От:	korzhik
	Дата:	28.09.05 17:01
	Оценка:	1 (1) +3

От:	McSeem2	http://www.antigrain.com
Дата:	28.09.05 17:16
Оценка:	3 (2) +1

	От:	Зверёк Харьковский
	Дата:	28.09.05 18:03
	Оценка:	12 (3) +6

От:	McSeem2	http://www.antigrain.com
Дата:	28.09.05 19:15
Оценка:	10 (2) +1

От:	dmitre	http://del.icio.us/dmitre
Дата:	29.09.05 07:51
Оценка:

От:	Mamut	http://dmitriid.com
Дата:	29.09.05 08:03
Оценка:

От:	WinterMute	http://yarrr.ru
Дата:	29.09.05 10:17
Оценка:

От:	.silent	http://www.bezhetsk.ru
Дата:	29.09.05 14:11
Оценка:

От:	Sinclair	https://github.com/evilguest/
Дата:	30.09.05 03:43
Оценка:	+1

От:	c-smile	http://terrainformatica.com
Дата:	01.10.05 00:48
Оценка:

От:	FreshMeat	http://www.rsdn.org
Дата:	01.10.05 11:30
Оценка:

От:	Andrei N.Sobchuck	www.smalltalk.ru
Дата:	03.10.05 20:20
Оценка:

От:	Whistler	Блог на GotDotNet.ru
Дата:	06.10.05 03:48
Оценка:	-11

От:	AndrewVK	http://blogs.rsdn.org/avk
Дата:	22.10.05 19:16
Оценка:

	От:	Красин
	Дата:	25.10.06 01:00
	Оценка:	3 (1)

	От:	Дьяченко Александр
	Дата:	15.11.06 17:49
	Оценка:	22 (3)