Здравствуйте, 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>Глеб, я безусловно отношусь с уважением к твоей точке зрения. И очень ценю то время, что ты потратил на написание этого ответа. Моя цель в споре — не задавить кого-то своим "авторитетом", а самому понять что-то важное. Спасибо!
Самому понравилась ваша точка зрения. Просто не считаю ее верной
Здравствуйте, 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 модели. Это просто отсутствие стандартов и более высокий класс дизайнеров.
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
MS>>Я хотел лишь донести спорную мысль (даже для меня самого спорную), что наличие этой "гламурной четкости" само по себе тормозит развитие. Но не прямо, а косвенно — через невозможность свободно масштабировать текст. GZ>Идея кстати стара. Если забыть о шрифтах, то идею того, что нужно рисовать именно в логических device-independ координатах Microsoft продвигала еще со времен Windows 2.0. У них и размер стандартного диалога тогда рассчитывался по размеру экрана(но который рассчитывался по DPI что было (и осталось но тогда она была меньше, сколько сейчас не помню) константой. Потом все эти системы, что вижу то и печатаю. Она полностью держится на логических координатах. Но все равно не пошла. Как-то пришлось созданием интерфейса по типу ActiveX — приходится в то или иное место закрашивать пикселями. А тут не до
алайзинга.(согласен что данный вопрос прямо связан с DPI)
Но с одной стороны, ты прав. Некие логические единицы не должны зависеть от разрешения устройства. Другое дело — нужны ли реально миллиметры и дюймы? Я считаю, что не нужны. И даже более того — их использование противоречит тому, что мы наблюдаем на мониторах! (догадайтесь с одного раза, почему).
Должны быть некие абстрактные единицы, типа 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, но гарантированно работающее везде и всюду.
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
1) "Если бы MS не было его стоило бы выдумать". "Майккрософту — от Вольтера" и пр.
2) Концепт "растеризации вектора" порочен сам по себе. Вектор нужно рисовать вектором.
Сколько бы ты не делал DPI все равно проблемы остаются.
На 600 DPI например делают REt I, II, III и конца тому не видно.
Здравствуйте, minorlogic, Вы писали:
M>А кстати слышал ли ты про некий комп с названием NEXT и его графический интерфейс ?
Сорри , не всю ветку прочел. Но это то что сразу пришло на ум.
Ну вот , дочитал тему до конца , теперь выскажусь.
Не смог найти место кому высказать конкретно , поэтому сразу в главную ветку.
Тут звучало мнение что векторные иконки будут выглядеть намного хуже чем пиксельные уже адаптированные под конкретное разрешение.
Так мне кажется это просто часный случай , недостаток. Надо просто рендрить векторное изображение с упором на мелкие детали , автоматически подстраивать по восприятие пиксельной картинки .
Плюс .
Есть один замечательный дедовский способ ( кстати не видел в AGG ,надо бы исправить !!! ) .
Векторное изображение рендрится в пиксельное представление , но не статически , а изображение как бы анимируется . Изображение как бы медленно плавает в пределах ПОЛОВИНЫ пиксела ( по кругу например или восьмеркой ).
Если анимация достаточно быстра , то Субъективное разрашение такого изображения увеличивается НА ПОРЯДОК , больше чем в 4 раза !!!.
Здравствуйте, minorlogic, Вы писали:
M>Есть один замечательный дедовский способ ( кстати не видел в AGG ,надо бы исправить !!! ) . M>Векторное изображение рендрится в пиксельное представление , но не статически , а изображение как бы анимируется . Изображение как бы медленно плавает в пределах ПОЛОВИНЫ пиксела ( по кругу например или восьмеркой ).
M>Если анимация достаточно быстра , то Субъективное разрашение такого изображения увеличивается НА ПОРЯДОК , больше чем в 4 раза !!!.
Вот это интересно. Можно пример? Хотя бы анимированный GIF?
Впрочем есть сомнения по причине инерционности и/или ограниченного refresh rate.
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
Здравствуйте, c-smile, Вы писали:
CS>2) Концепт "растеризации вектора" порочен сам по себе. Вектор нужно рисовать вектором.
То есть плоттером на бумаге? А на экране — чем? Лучем с регенерацией, как в древних векторных дисплеях? Рискну утверждать, что это не так. Плоттеры хоть и применяются, но все более и более ограниченно.
CS>Сколько бы ты не делал DPI все равно проблемы остаются. CS>На 600 DPI например делают REt I, II, III и конца тому не видно.
Это проблемы из другой области. И как раз из области печати фотографий. Для ровных контрастных линий вполне достаточно 600 dpi безо всяких сглаживаний. А вот для печати голубого неба — и 2400 маловато.
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
Здравствуйте, 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>Пока что такого формата нету.
Здравствуйте, minorlogic, Вы писали:
M>Насчет инерционности это да , это продлема, но новые ЖК панельки все быстрее и быстрее , так что и на PDA такой трюк думаю сработает .
Даже дело не в инерционности. Refresh rate все равно ограничен.
M>Недавно читал что некоторые ЖК мониторы похожую технику применяют , для повышения цветового разрешения.
Как для цветового — это понятно. Есть такой способ для GIF (с разными палитрами). А вот как это должно работать для увеличения пространственного разрешения — что-то не соображу. Колись давай.
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
Совсем простой тестик можно провести , обычный текст с разрешением при котором плохо различим отрендрить в статике и тут же в динамике , просто проанимировать.
То есть чтобы текст совершал легкие плавные движения. Текст который движется должен быть намного лучше различим.
В действительности не знаю. 
Просто не считаю ее верной 
Как минимум, насчёт PDA не согласен — даже у пресловутого адоборидера для КПК есть Reflow plugin (кстати, не всегда срабатывает), который создан именно для убийства трудов верстальщиков, чтобы на масеньком экранчике PDA смотреть ебуки с нормальным размером шрифта. А HTML — он тем и хорош,что приемлемо отображается на куче устройств с различными размерами и пропорциями экранов.
