S>Опять ты смешиваешь архитектуру и реализацию. Вот не надо переносить косяки реализации на архитектуру. Да, парни, которые реализовывали это дело — халтурщики. И что теперь, выкидывать базовый класс из-за того, что есть убогие наследники?
А вот это уже вполне филосовский вопрос. А что если этот класс имеет одного единственного нетривиального наследника, да и тот убогий? Ну это утрированно, на самом деле никакого там базового карандаша нет — просто карандаш может создаваться как сплошной, пунктирный или текстурный, то есть внутри — банальный switch(). Но вопрос несколько в другом — надо ли изобретать некие интерфейсные сущности для некой гипотетической будущей реализации? Я считаю, что это не только не нужно, но и крайне вредно. Отталкиваться нужно от нашего физического мира прежде всего, от того, что уже работает. Такие нереализованные (или полу-реализованные) возможности, заложенные в интерфейсе, приводят к возникновению неуклюжих уродцев, которые становится нереально имплементировать или на имплементацию их требуются неимоверные усилия c мизерным результатом.
Вернемся к тому же карандашу. Это полный бардак — в нем намешаны в одну кучу принципиально разные вещи, как то геометрия и цвет. Width и LineJoin — это геометрические свойства, Color и Brush не имеют никакого отношения к геометрии. Можно сказать, что ну и фиг с ним, удобно же — в одном объекте устанавливаем все свойства, какие нужны. Для тривиальных задач, типа рисования линии на экране, это так. Но шаг-вправо-шаг-влево карается мгновенным ступором. Например, я хочу посчитать в векторном виде толстую штрих-пунктирную линию с RoundJoin и RoundCap и вычесть ее из некого полигона, тоже в векторном виде. Координаты записать в файл. Пусть библиотека это умеет. Но при этом я должен использовать Pen, чтобы метод знал Width, RoundJoin и RoundCap. А зачем мне тогда в этом Pen иметь Color? И что будет если я установлю TextureBrush? — он что, ринется верторизовать растровый паттерн? А если эту операцию вычитания можно сделать без привлечения Pen, то Width, RoundJoin и RoundCap должны устанавливаться где-то еще. Таким образом, постепенно весь так называемый "дизайн" превращается в нагромождение нелепостей.
Или другой пример с тем же карандашом. В нем можно устанавливать ширину линии и пунктир. А если я хочу нарисовать цепь из маленьких кружочков вдоль ломаной (причем, не растровых, а векторных, то есть маштабируемых)? Какой для этого нужен карандаш? — правильно, нет такого. И самое главное — его невозможно добавить в библиотеку без модификации этой самой библиотеки, то есть это может сделать только Microsoft только по своей прихоти. Спрашивается, о каком таком дизайне идет речь? Нет его этого дизайна — один сплошной бардак.
Правильный дизайн заключался бы в том, чтобы можно было самому составлять векторные конвейеры, например, полигон->пунктир->строкер->трансформер. И чтобы выход трансформера можно было использовать идентичным образом как для рисования, так и для записи в файл. При этом у нас Width, LineJoin, LineCap — свойства строкера, длина пунктира — ствойство класса-"пунктирщика", масштаб — свойство трансформера и т.д. Но главное — что все элементы этого конвейера являются интерфейсно совместимыми, то есть, их можно выстраивать в любые цепочки (и даже ветвить). И если у нас чего-то не хватает в библтотеке — всегда можно дописать не затригивая исходников, например, элемент конвейера, который "ляпает" кружочки вдоль линии. Вставляем его в нужное место конвейера и вот у нас линии стали точечными.
Вот это то, что и называется дизайном. Это дает свободу действий, обладает неограниченной расширяемостью и внутренней стройностью.
А называть этот бардак с карандашами GDI+ дизайном (или даже архитектурой!) — это все равно, что восхищаться остроумием Петросяна. Кому-то нравится, но лично меня — тошнит.
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
Читаю сейчас книгу "Исскуство прогртиаммирования для UNIX", там в начале обсуждаются философские метафоры, на которых построены операционки. И про винды сказано, что их метафора скорее всего такая: пользователь должен быть замкнут.
Читая твой пост как раз про это и вспомнил, создаётся впечатление, что большинство API, которое делает MC именно с таким прицелом и написано: программер должен быть замкнут. Т.е. работать только в оговоренных рамках, чтоб случайно куда-нть ещё не соскочить, а всю жизнь потратить на то, чтобы стать гуру по извращениям
Хотя надо признать, с момента выхода .нет неколторые интерфейсы вполне приличные.
Здравствуйте, McSeem2, Вы писали:
MS>Вернемся к тому же карандашу. Это полный бардак — в нем намешаны в одну кучу принципиально разные вещи, как то геометрия и цвет.
Объекты GDI — это были просто признаки стилей, сгруппированные "по смыслу". GDI+ ушла не далеко. Действительно, ничего объектного в этой системе нет by design. Даже нативный C++ интерфейс — суть надстройка над хенлами. Т.е. как и в GDI мы лишь можем оперировать стилями.
Дополнительно в GDI+ появилось лишь сглаживание и трансформация, применяемая не ко всему DC (как раньше), а к конкретным стилям — кисти/карандашу.
MS>... Таким образом, постепенно весь так называемый "дизайн" превращается в нагромождение нелепостей. MS>... Какой для этого нужен карандаш? — правильно, нет такого. И самое главное — его невозможно добавить в библиотеку без модификации этой самой библиотеки...
Так, это уже мы малость обгоняем события. Не секрет, что GDI+ — это растровая библиотека, а не векторная. Какие могут быть объекты в растровой библиотеке??? Ты сейчас говоришь об объектности и графических примитивах. В векторной библиотеке должны быть твои примитивы. Но эти примитивы — не кисть/карандаш (которые по прежнему суть стили), а линии, овалы и т.д.
Смешно ругать растровую библиотеку за то, что она не векторная. Кстати, хинт: векторные библиотеки строят поверх растровых. Так что — вам и карты в руки
И еще, мощная векторная библиотека — это охрененное количество труда, ну просто охрененное. Стоимость оборачивания этой либы в приложение с менюшками и окошками на порядок ниже. Это намек на то, что если ты способен разработать такую либу, так давай я тебе по-быстрому заверну ее в красивое GUI и мы пойдем громить всякие FreeHand и CorelDraw
По крайней мере, я готов обещать, что моя часть будет не хуже, чем у конкурентов, а твоя?
Да и растровые либы — не шутка. Чем берет Photoshop? GUI — минимальное, невзрачное. Плагинами? А только ли? А как насчет прецизионной работы с цветами, дающей "промышленное" качество? Это инструмент профессионала, и попробуй обыграть все эти вещи сам... (Хотя, совмещение, например, 2-х слоев под управлением 3-го с градиентами прозрачности — не такой уж сложный алгоритм, я бы даже сказал — тривиальный)
MS>Правильный дизайн заключался бы в том, чтобы можно было самому составлять векторные конвейеры, например, полигон->пунктир->строкер->трансформер. И чтобы выход трансформера можно было использовать идентичным образом как для рисования, так и для записи в файл. При этом у нас Width, LineJoin, LineCap — свойства строкера, длина пунктира — ствойство класса-"пунктирщика", масштаб — свойство трансформера и т.д. Но главное — что все элементы этого конвейера являются интерфейсно совместимыми, то есть, их можно выстраивать в любые цепочки (и даже ветвить). И если у нас чего-то не хватает в библтотеке — всегда можно дописать не затригивая исходников, например, элемент конвейера, который "ляпает" кружочки вдоль линии. Вставляем его в нужное место конвейера и вот у нас линии стали точечными.
Ну, не надо рассказывать, как писать графические примитивы векторных либ. На самом деле у графических примитивов может быть очень малое кол-во базовых св-в, навскидку этого достаточно: Origin, Transform, Children. Все остальные св-ва — это кастомные св-ва конкретных примитивов. Например, у нас может быть примитив — кнока. И у нее свои св-ва, типа RoundRadius, BaseColor, Contrast, ShapeEnum.
Далее, сами графические примитивы для прорисовки используют другие графические примитивы. Разумеется, нужны некоторые базовые, типа Line, Curve, Arc. Даже Path — суть контейнер из оных.
Если тебе нужно пересечение примитивов — его можно вычислять в терминах самых базовых примитивов. И еще, у базовых примитивов не может быть ширины, это как бы математические абстракции. Если примитив более высокго уровня (LineWithWidth) рисует себя, то она, разумеется, использует базовые примитивы для определения собственного векторного рисунка.
MS>Вот это то, что и называется дизайном. Это дает свободу действий, обладает неограниченной расширяемостью и внутренней стройностью.
Ну про карты в руки и векторные либы уже сказано... Можно даже на sourceforge пойти, там неоднократно затевались векторные либы.
MS>А называть этот бардак с карандашами GDI+ дизайном (или даже архитектурой!) — это все равно, что восхищаться остроумием Петросяна. Кому-то нравится, но лично меня — тошнит.
Зря ты так. Для растровой либы — вполне нехилый набор инструментария. Нарисовать можно ВСЕ ЧТО УГОДНО, многие операции/хелперы уже есть, т.е. я готов приписать этой либе св-во полноты
Другое дело — КАК рисовать? Ну этот вопрос — к началу данного сообщения. Дерзайте, творите, пробуйте.
Здравствуйте, vdimas, Вы писали:
V>Так, это уже мы малость обгоняем события. Не секрет, что GDI+ — это растровая библиотека, а не векторная. Какие могут быть объекты в растровой библиотеке??? Ты сейчас говоришь об объектности и графических примитивах. В векторной библиотеке должны быть твои примитивы. Но эти примитивы — не кисть/карандаш (которые по прежнему суть стили), а линии, овалы и т.д.
Как так "растровая"? Я чего-то не понимаю. Как только у нас возникают функции MoveTo/LineTo, все — мы уже имеем дело с векторными примитивами. В конце концов, я работаю с GDI+ или даже с GDI на уровне векторных данных — координат на плоскости. Чисто растровая операция — это, например, наложение изображения с градиентом прозрачности.
V>И еще, мощная векторная библиотека — это охрененное количество труда, ну просто охрененное. Стоимость оборачивания этой либы в приложение с менюшками и окошками на порядок ниже. Это намек на то, что если ты способен разработать такую либу, так давай я тебе по-быстрому заверну ее в красивое GUI и мы пойдем громить всякие FreeHand и CorelDraw V>По крайней мере, я готов обещать, что моя часть будет не хуже, чем у конкурентов, а твоя?
Моя часть уже не хуже.
Но любое "заворачивание" — это уже ограничения. Поэтому я выбрал настолько открытый дизайн, насколько это вообще возможно.
Я уже приводил эту дему: http://antigrain.com/stuff/page_demo.exe
Все векторное, все масштабируется
V>Ну, не надо рассказывать, как писать графические примитивы векторных либ. На самом деле у графических примитивов может быть очень малое кол-во базовых св-в, навскидку этого достаточно: Origin, Transform, Children. Все остальные св-ва — это кастомные св-ва конкретных примитивов. Например, у нас может быть примитив — кнока. И у нее свои св-ва, типа RoundRadius, BaseColor, Contrast, ShapeEnum.
Ничего не понимаю. У каждго примитива должно быть свойство "Transform"?! Это же маразм. Если есть массив примитивов и надо увеличить всю сцену, то что — модицицировать все объекты через это свойство Transform? Да функция рисования вообще не имеет права модифицировать объекты. Смею заверить, что Transform это не свойство "графического примитива", это — свойство конвейера. И вообще, я не очень-то представляю, что понимается под "графическим примитивом". И я тоже категорически протестую против наличия свойства RoundRadius у кнопки. Вид кнопки ни в коем случае не должен определяться самой кнопкой. Точнее, технически конечно может, но это тупиковый путь.
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
Здравствуйте, McSeem2, Вы писали:
MS>Но вопрос несколько в другом — надо ли изобретать некие интерфейсные сущности для некой гипотетической будущей реализации? Я считаю, что это не только не нужно, но и крайне вредно. Отталкиваться нужно от нашего физического мира прежде всего, от того, что уже работает. Такие нереализованные (или полу-реализованные) возможности, заложенные в интерфейсе, приводят к возникновению неуклюжих уродцев, которые становится нереально имплементировать или на имплементацию их требуются неимоверные усилия c мизерным результатом.
MS>Вернемся к тому же карандашу. Это полный бардак — в нем намешаны в одну кучу принципиально разные вещи, как то геометрия и цвет. Width и LineJoin — это геометрические свойства, Color и Brush не имеют никакого отношения к геометрии...
MS>...А зачем мне тогда в этом Pen иметь Color?...
Сплю и вижу карандаш из физического мира не имеющий цвета! Эдакое творение прогресса в котором перед тем как нарисовать линию нужно выскоблить грифель и вставить другой. И все ради удобства. Не, не барское право дело карандаши из стакана таскать!
Театр абсурда, блин.
ЗЫ
В общем, вы господа философы совсем от нечего делать заговорились.
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
VladD2 wrote: > > Сплю и вижу *карандаш из физического мира не имеющий цвета*! Эдакое > творение прогресса в котором перед тем как нарисовать линию нужно > выскоблить грифель и вставить другой. И все ради удобства. Не, не > барское право дело карандаши из стакана таскать!
Здравствуйте, VladD2, Вы писали:
MS>>...А зачем мне тогда в этом Pen иметь Color?...
VD>Сплю и вижу карандаш из физического мира не имеющий цвета! Эдакое творение прогресса в котором перед тем как нарисовать линию нужно выскоблить грифель и вставить другой. И все ради удобства. Не, не барское право дело карандаши из стакана таскать!
VD>Театр абсурда, блин.
Я тебе как художник художнику скажу: есть такой прием при рисовании пастелью
когда рисуют голым пальцем, ну и какого цвета палец?.
Еще кто-то рисует стреляя из рогатки тюбиками по холсту...
Пуанталисты рисуют например цветными точками, что есть brush в этом смысле?
Это я к тому что если ты разрабатываешь систему пригодную для художественного рисования то
твоя система классов должна как минимум в классе Brush иметь virtual method draw()
чтобы можно было определять свои "пальцы".
Если же у тебя Pen и Brush sealed в этом смысле — значит они являются атомарными примитивами нижнего
уровня. Возникает вопрос — зачем они сделаны классами тогда?
Далее возникает вопрос: какого рода рисовательные задачи преполагалось решать с пом.
GDI+? Рисование UI? Или программирование графичеких редакторов?
Как мы видим GDI+ не решает ни одну из поставленных задач толком.
Возникает третий законный вопрос: что конкретно имели ввиду авторы GDI+, зачем оно вообще?
Здравствуйте, VladD2, Вы писали:
VD>Сплю и вижу карандаш из физического мира не имеющий цвета! Эдакое творение прогресса в котором перед тем как нарисовать линию нужно выскоблить грифель и вставить другой. И все ради удобства. Не, не барское право дело карандаши из стакана таскать!
Ты опять ни фига не понял, Влад. Речь была не о том, что уместно, а что нет в карандаше, а о том, нафига он вообще нужен этот карандаш? А особенно — зачем он нужен для чисто векторонй операции вычитания полигонов?
Кстати, я слыхал краем уха, что в авалоне отделили геометрию от всяких там цветов. Это ж какое, блин, великое достижение!
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
Здравствуйте, c-smile, Вы писали:
CS>Я тебе как художник художнику скажу: есть такой прием при рисовании пастелью CS>когда рисуют голым пальцем, ну и какого цвета палец?.
А палец и карандаш одно и тоже? Или просто в МС хотели сделать объект реального мира "палец", но накосячили и обломались?
CS>Еще кто-то рисует стреляя из рогатки тюбиками по холсту... CS>Пуанталисты рисуют например цветными точками, что есть brush в этом смысле?
Рогатка?
В общем, кончай филосовствовать. А то вы с McSeem2 и так договорились до такого, что без слез не взглянешь.
CS>Далее возникает вопрос: какого рода рисовательные задачи преполагалось решать с пом. CS>GDI+? Рисование UI? Или программирование графичеких редакторов?
А что, что-то из перечисленного невозможно реализовать на GDI+?
CS>Как мы видим GDI+ не решает ни одну из поставленных задач толком.
Где выидим? Ну, или кто мы?
Я вижу только одно. Иногда GDI+ не очень проворна. Но то что на нем прекрасно работает то же Визио подсказывает мне, то GDI+ все же для чего-то пригодна.
CS>Возникает третий законный вопрос: что конкретно имели ввиду авторы GDI+, зачем оно вообще?
Ой, это ты спроси, например, у разработчиков того же Визио. После перехода на GDI+ визио стало работать намного лучше. Появилась куча возможностей, исчезли проблемы с экспортом.
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, McSeem2, Вы писали:
MS>Ты опять ни фига не понял, Влад.
Да, я и не пытался. Я просто процитировал тебя. Мне показалось забавным, что разные части твоего текста противоречат друг другу.
MS> Речь была не о том, что уместно, а что нет в карандаше,
Да? А мне показалось, что вот цвет в нем был лишний. Или ты не это хотел сказать?
MS> а о том, нафига он вообще нужен этот карандаш? А особенно — зачем он нужен для чисто векторонй операции вычитания полигонов?
Вот последний вопрос просто в точку. Мне кажется он для этого вообще не нужен. Полигон есть полигон. Захотим ранисовать, тогда и передадим его вместе с карадашем в функцию рисования полигонов. А для рассчетов можно и одними полигонами обойтись.
MS>Кстати, я слыхал краем уха, что в авалоне отделили геометрию от всяких там цветов. Это ж какое, блин, великое достижение!
Что-то я этого не аметил. Разные кружки и т.п. на базе. И их цвета вроде как анимируются даже. Там просто все посложнее сделали. Но это скорее наоборот... ОО-усложнение.
Кстати, Авалон доступен свободно (вроде). Скачай — погляди.
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
MS>> а о том, нафига он вообще нужен этот карандаш? А особенно — зачем он нужен для чисто векторонй операции вычитания полигонов?
VD>Вот последний вопрос просто в точку. Мне кажется он для этого вообще не нужен. Полигон есть полигон. Захотим ранисовать, тогда и передадим его вместе с карадашем в функцию рисования полигонов. А для рассчетов можно и одними полигонами обойтись.
С дизайном GDI+ он как раз нужен для векторных операций. Так, еще раз повторяю, для тех кто в танке. В классе Pen вместе с цветами намешаны чисто геометрические свойства — такие, как Width, LineJoin, LineCap, MiterLimit. И если ты все-таки прочитаешь мое сообщение, то ты увидишь, что речь была не просто об операции над полигонами, а о том, чтобы линию представить как полигон (это называется stroke) и вычесть ее из некого другого полигона. И для этого тоже нужен карандаш и это уже само по себе противоестественно. А теперь вопрос — для какой цели в этом карандаше и в этой операции нужен цвет?
Я просто на конкретном примере демонстрируую, что эта концепция карандашей не выдерживает самой элементарной критики. И закончим на этом.
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
Здравствуйте, VladD2, Вы писали:
CS>>Я тебе как художник художнику скажу: есть такой прием при рисовании пастелью CS>>когда рисуют голым пальцем, ну и какого цвета палец?.
VD>А палец и карандаш одно и тоже? Или просто в МС хотели сделать объект реального мира "палец", но накосячили и обломались?
Не знаю что ты имеешь ввиду. А вот Brush и Pen (кисть и ручка) это в принципе одно и тоже — это
чем рисуют.
CS>>Еще кто-то рисует стреляя из рогатки тюбиками по холсту... CS>>Пуанталисты рисуют например цветными точками, что есть brush в этом смысле?
VD>Рогатка?
VD>В общем, кончай филосовствовать. А то вы с McSeem2 и так договорились до такого, что без слез не взглянешь.
Мы-то как раз практики т.е. для нас это вопрос практических имплементаций.
CS>>Далее возникает вопрос: какого рода рисовательные задачи преполагалось решать с пом. CS>>GDI+? Рисование UI? Или программирование графичеких редакторов?
VD>А что, что-то из перечисленного невозможно реализовать на GDI+?
"Иногда GDI+ не очень проворна" (автор указан ниже).
Это киллер и UI и редактора как ты сам понимаешь.
И самое грустное — ни объехать сие ни на какой козе.
CS>>Как мы видим GDI+ не решает ни одну из поставленных задач толком.
VD>Где выидим? Ну, или кто мы?
Я вижу, ты видишь — я + ты = мы.
VD>Я вижу только одно. Иногда GDI+ не очень проворна. Но то что на нем прекрасно работает то же Визио подсказывает мне, то GDI+ все же для чего-то пригодна.
Что-то не критичное наверное работает. Я тебе верю на слово.
CS>>Возникает третий законный вопрос: что конкретно имели ввиду авторы GDI+, зачем оно вообще?
VD>Ой, это ты спроси, например, у разработчиков того же Визио. После перехода на GDI+ визио стало работать намного лучше. Появилась куча возможностей, исчезли проблемы с экспортом.
Cпрошу конечно.
А пока интересует:
1) какая куча возможностей связанных с GDI+?
2) проблемы с экспортом куда?
3) Visio UI написан с помощью GDI+?
Документы типа диаграмм имеют простой DOM. блок в Visio это один Brush один Pen.
Т.е. GDI+ — для рисования блок-схем? Соответственно System.Drawing.* для того же, ы?
class Visio.Dom.LineStyle
class Visio.Dom.BorderStyle
class Visio.Dom.BackgroundStyle
— я понимаю.
Но зачем:
System.Drawing.Brush
System.Drawing.Pen
— не понимаю.
Здравствуйте, c-smile, Вы писали:
CS>Я вижу, ты видишь — я + ты = мы.
Дык, я то не вижу.
VD>>Я вижу только одно. Иногда GDI+ не очень проворна. Но то что на нем прекрасно работает то же Визио подсказывает мне, то GDI+ все же для чего-то пригодна.
CS>Что-то не критичное наверное работает. Я тебе верю на слово.
Значит весь ГУИ-код на дотнете не критичен.
CS>А пока интересует: CS>1) какая куча возможностей связанных с GDI+?
Да, вся отрисовка, импорт и экспорт графики в Визио через него сделано.
Если ты о том что дало GDI+ по сравнению с предыдущими версиями, то лично мне в глаза бросаются:
1. Сглаживания.
2. Градиентные заливки всего чего попало.
3. Управление прозрачностью всего чего попало.
CS>2) проблемы с экспортом куда?
В разные форматы. Раньше на экспорт из Визио без слез было нельзя смотреть. Теперь все ОК.
CS>3) Visio UI написан с помощью GDI+?
Визио — это система векторного рисования и рисования диаграмм. Вся отрисовка сделано через GDI+. Если ты под UI имеешь в виду менюшки, то это просто мелочь по сравнению с тем что делается в Визио. Я так понимаю ты его даже не видел. Ты бы глянул сначала на него, а потом бы уже критиковал, если конечно рука подымится.
К сведению, почти все векторные картинки к нашему журналу и статьям на сайте делаются именно на Визио.
CS>Документы типа диаграмм имеют простой DOM. блок в Visio это один Brush один Pen. CS>Т.е. GDI+ — для рисования блок-схем? Соответственно System.Drawing.* для того же, ы?
Ты какую версию Визио видел то?
CS>...- не понимаю.
Дык не хочешь.
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
MS>Как так "растровая"? Я чего-то не понимаю. Как только у нас возникают функции MoveTo/LineTo, все — мы уже имеем дело с векторными примитивами.
Понимаешь, после выполнения операции MoveTo ты не можешь получить линию как объект. ТЫ получаешь ее растровое представление (в большинстве случаев, WMF — отдельный случай).
MS>В конце концов, я работаю с GDI+ или даже с GDI на уровне векторных данных — координат на плоскости. Чисто растровая операция — это, например, наложение изображения с градиентом прозрачности.
Именно это и происходит при операции LineTo — там накладывается изображение или цвет (смотря как мы создали карандаш), и при включенном антиаллиасинге — именно с градиентом прозрачности. У векторной либы вообще нет такой операции как "наложение" чего-то там куда-нить, помимо транформации самих объектов, эти наложения — суть операция рендеринга.
MS>Моя часть уже не хуже.
Неужели???
MS>Но любое "заворачивание" — это уже ограничения. Поэтому я выбрал настолько открытый дизайн, насколько это вообще возможно.
Да, правильное направление, насчет открытого дизайна. Ибо в одиночку провернуть разработку графических либ сложновато.
MS>Я уже приводил эту дему: MS>http://antigrain.com/stuff/page_demo.exe MS>Все векторное, все масштабируется
И что показывает эта дема? Я ее видел.
V>>Ну, не надо рассказывать, как писать графические примитивы векторных либ. На самом деле у графических примитивов может быть очень малое кол-во базовых св-в, навскидку этого достаточно: Origin, Transform, Children. Все остальные св-ва — это кастомные св-ва конкретных примитивов. Например, у нас может быть примитив — кнока. И у нее свои св-ва, типа RoundRadius, BaseColor, Contrast, ShapeEnum.
MS>Ничего не понимаю. У каждго примитива должно быть свойство "Transform"?!
Да, это св-во дано каждому примитиву "свыше", правильней сформулировать так (если уж ты зацепился): к каждому примитиву привязан некий Transform. Этот Transform назначается примитиву как результат, скажем, редактирования сцены в некоем редакторе.
MS>Если есть массив примитивов и надо увеличить всю сцену, то что — модицицировать все объекты через это свойство Transform? Да функция рисования вообще не имеет права модифицировать объекты.
Так я и знал. Все вмешалось в доме Облоньских. Ты операцию рендеринга с самими примитивами не путаешь?
MS>Смею заверить, что Transform это не свойство "графического примитива", это — свойство конвейера.
Почему? У меня есть некий овал. На конкретной сцене я его повернул как угодно. Так к чему мне привязать это св-во?
Я же сказал, основные св-ва примитивов в графической сцене: Origin, Transform, Children. То, что ты называешь конвеером — это такой спецальный вид графического объекта, который генерирует другие объекты? Я же говорю об иерархии контейнеров. Это немного другой взглдя на вещи, более "традиционный". Смотрим тот же FreeHand. Они запоминают ОПЕРАЦИИ, но запомненная операция у них — это такой объект... Наверно, как твой конвеер.
MS>И я тоже категорически протестую против наличия свойства RoundRadius у кнопки. Вид кнопки ни в коем случае не должен определяться самой кнопкой. Точнее, технически конечно может, но это тупиковый путь.
Это — способ открыть двери разработчикам библиотек графических объектов. Кнопка, как и любой графический объект должна генерировать набор неких простейших графических примитивов в ответ на изменение своих св-в. Сами св-ва открыты для редактирвоания в некоем редакторе. Программист пишет графические объекты с открытыми св-вами, художник настраивает эти св-ва в конкретной сцене. Так зачем усложнять простейшие вещи?
Здравствуйте, c-smile, Вы писали:
CS>Оптимальная архитектура для GDI и рисования (и кстати не только для них) CS>это то что Макс нызывает конвейером или потоком в простонародье.
CS>Рисование а тем более универсальное рисование на разных устройствах и CS>геометриях это как и в жизни "рисуем чем придется" в т.ч. ножиком на заборе.
CS>Для реализации такой идеологии больше подходит функциональный стиль CS>который проверен веками: PS/metafile со товарищи.
CS>Например
CS>hdc << BeginPen(0) << BeginPath << ... << EndPath << EndPen(0); CS>hdc << BeginPath << BeginBezier << Point(1,2)... << EndPath << Draw(0);
CS>т.е. рисование состоит из цепочек атомарных и простых примитивов CS>Классов там нет — ибо нельзя описать то что ты еще не знаешь.
CS>Pen как sealed класс не существует в принципе.
Замечание, Pen — это набор стилей, а не класс. Мы эти наборы стилей можем представить как экземпляры в терминах ЯП, чем плох способ?
CS>В моем примере (и в примере Макса) Pen это в общем случае цепочка (или конвейер) CS>неких рисовательных действий.
CS>Укладывать же сию неописуемую (буквально) сущность в прокрустово ложе CS>классов — по меньшей мере ошибка.
Так стоп. Насколько я понял, кое-кто предлагает рисовать только лишь программно? Если речь идет о векторной либе, то перебор
Конвеер — это алгоритм. Какие, блин, могут быть пробблемы в заворацивание этого алгоритма в метод. И почему я не могу настраивать некий алгоритм некоего экземпляра некоторыми св-вами? И где здесь нет места удобным и проверенным вещам, типа инкапсуляции и декомпозиции?
CS>Далее возникает вопрос: какого рода рисовательные задачи преполагалось решать с пом. CS>GDI+? Рисование UI? Или программирование графичеких редакторов?
А рендериниг в 2D. Более ничего. Вполне приличный антиалиасинг и заливка. Что еще надо? Остальное имеет такое невообразимое количество инвариантов, что мне трудно представить их реализацию в либе, преттендующей на "базовую". Не забывай, что кому-то ведь и дрова писать надо, поддерживающие GDI (уверен, что скоро и GDI+)
CS>Как мы видим GDI+ не решает ни одну из поставленных задач толком.
А не обязана. GDI (GDI+) — это абстракция холста, а не художника.
CS>Возникает третий законный вопрос: что конкретно имели ввиду авторы GDI+, зачем оно вообще?
Дрова и еще раз дрова. Одинаковый способ рисования как на принтере, так и на плоттере.
Здравствуйте, c-smile, Вы писали:
VD>>А палец и карандаш одно и тоже? Или просто в МС хотели сделать объект реального мира "палец", но накосячили и обломались?
CS>Не знаю что ты имеешь ввиду. А вот Brush и Pen (кисть и ручка) это в принципе одно и тоже — это CS>чем рисуют.
Блин, ну хотя бы поинтересовалсь, НАФИГА некие стли рисования были вынесены в хендлы? И почему раньше разрабатывали системы не с таким способом рисования:
DrawLine(dc, x1, y1, x2, y2, color, width);
а именно с таким:
DrawLine(dc, x1, y1, x2, y2, pen);
Заодно помедитировать на тему — причем тут собственно, плоттеры или удаленные графические терминалы и особенно ширина канала связи при заливке шрихом сотен участков на сложном чертеже? Действиетльно, ну нахрена Brush, если можно каждый раз передать каждую линию штриха Ну блин, как дети, ей богу...
Повторяю еще раз, в терминах GDI brush и pen — это группированные наборы стилей. Это не нужно понимать, это надо запомнить.
CS>Мы-то как раз практики т.е. для нас это вопрос практических имплементаций.
Отделите плиз векторную часть от ср-в рендеринга, и все будет ok. Да, найдите хоть одного толкового программиста, который не потратил кучу времени ан эксперименты с рисованием. Кстати, вам давно пора было перйти на эксперименты с 3D, и тоже обругать там все
CS>"Иногда GDI+ не очень проворна" (автор указан ниже).
Иногда GDI+ сидит поверх дров GDI. Скоро будет наоборот.
CS>Это киллер и UI и редактора как ты сам понимаешь. CS>И самое грустное — ни объехать сие ни на какой козе.
Это уровень 0, не более того. Ты всерьез считаешь, что нормальный редактор должен делать рендеринг прямо на экран?
Не понял? Почему не объехать? Нельзя рисовать по точкам или плюнуть в него битмапом? Он тебе даже антиалиасинг заботливо сделает, если хочешь
Здравствуйте, McSeem2, Вы писали:
MS>Здравствуйте, VladD2, Вы писали:
MS>>> а о том, нафига он вообще нужен этот карандаш? А особенно — зачем он нужен для чисто векторонй операции вычитания полигонов?
VD>>Вот последний вопрос просто в точку. Мне кажется он для этого вообще не нужен. Полигон есть полигон. Захотим ранисовать, тогда и передадим его вместе с карадашем в функцию рисования полигонов. А для рассчетов можно и одними полигонами обойтись.
MS>С дизайном GDI+ он как раз нужен для векторных операций. Так, еще раз повторяю, для тех кто в танке. В классе Pen вместе с цветами намешаны чисто геометрические свойства — такие, как Width, LineJoin, LineCap, MiterLimit. И если ты все-таки прочитаешь мое сообщение, то ты увидишь, что речь была не просто об операции над полигонами, а о том, чтобы линию представить как полигон (это называется stroke) и вычесть ее из некого другого полигона. И для этого тоже нужен карандаш и это уже само по себе противоестественно. А теперь вопрос — для какой цели в этом карандаше и в этой операции нужен цвет? MS>Я просто на конкретном примере демонстрируую, что эта концепция карандашей не выдерживает самой элементарной критики. И закончим на этом.
Прекрасно понимаем о чем ты, но не для того был разработан GDI, не для того... GDI — это абстракция устройства, а не графического редактора. А устройства всякие бывают. И как всегда при разработке оптимизировали самые критичные моменты, коими вывод на экран не является.
Если бы они сделали как предлагаешь ты, то от виндов отвернулись бы производители устройств в первую очередь, ибо — не было бы смысла вкладывать силы в реализацию сверхсложного АПИ, 99% из которого устройство не способно поддержать физически ...
vdimas wrote: > А рендериниг в 2D. Более ничего. Вполне приличный антиалиасинг и > заливка. Что еще надо? Остальное имеет такое невообразимое количество > инвариантов, что мне трудно представить их реализацию в либе, > преттендующей на "базовую". Не забывай, что кому-то ведь и дрова писать > надо, поддерживающие GDI (уверен, что скоро и GDI+)
Можно было бы ожидать от GDI+ слегка более качественной реализации.
Все-таки большую часть времени она будет исопльзоваться для визуализации
изображений на обычный экран.
Antigrain показывает, что можно было сделать все намного лучше.
> CS>Возникает третий законный вопрос: что конкретно имели ввиду авторы > GDI+, зачем оно вообще? > Дрова и еще раз дрова. Одинаковый способ рисования как на принтере, так > и на плоттере.
Это скорее из области фантастики. Мне в текущем проекте нужно выводить
научную графику на принтер (в том числе на листы A1). Я перепробовал
кучу способов рендеринга моделей:
1. Рисовать OpenGL на контекст принтера — не работает вообще (хотя
документация говорит обратное).
2. Руками рендерить модель в виде векторного описания через OpenGL
feedback'и. На принтере выглядит уродливо.
3. Переводить векторную модель в PostScript и отсылать его на принтер.
На некоторых PS-принтерах выглядит нормально, но куча проблем с
совместимостью.
В итоге теперь мы прикрутили софтовый Mesa GL и при печати делаем
рендеринг изображения по кусочкам (100-200Мб размером) во внеэкранный
буффер. Эти изображения парраллельно отсылаем на принтер.
Вообще, принтеры умеют нормально растеризовать только небольшие
фрагменты векторных описаний — символы из шрифтов, например.
vdimas wrote: > Заодно помедитировать на тему — причем тут собственно, плоттеры или > удаленные графические терминалы и особенно ширина канала связи при > заливке шрихом сотен участков на сложном чертеже?
Если какие принтеры и занимаются полноценной заливкой, то стоят они
$$$$$ и не используют для печати GDI.
> Действиетльно, ну нахрена Brush, если можно каждый раз передать > каждую линию штриха Ну блин, как дети, ей богу...
Дело в том, что рисование нестандартной шириной — достаточно редкая
операция. Поэтому можно было бы сделать две функции: draw_line и
draw_styled_line.
CS>>"Иногда GDI+ не очень проворна" (автор указан ниже).
V>Иногда GDI+ сидит поверх дров GDI. Скоро будет наоборот.
Эту мулечку я уже от кого-то из здесь присутвующих слышал...
Года три тому назад.
Только ты все перепутал.
GDI как и GDI+ будут эмулирваться в
Windows Graphics Foundation которая есть "многоканальная" версия DirectX.
CS>>Это киллер и UI и редактора как ты сам понимаешь. CS>>И самое грустное — ни объехать сие ни на какой козе.
V>Это уровень 0, не более того. Ты всерьез считаешь, что нормальный редактор должен делать рендеринг прямо на экран? V>Не понял? Почему не объехать? Нельзя рисовать по точкам или плюнуть в него битмапом? Он тебе даже антиалиасинг заботливо сделает, если хочешь
"плюнуть в него битмапом" можно конечно если у тебя есть чем этот битмап эффективно наполнять.
Только битмап то только на экран можно это самое... На принтере-то пикселов нет...
Я вообще не понимаю... ну есть же в .NET GDI+ ну и рисуйте на нем в конце концов...
Он классовый по сами помидоры. Ну медленнее, ну дык ить как говорят в преферансе "за той горой все спрячется".
Чего не хватает-то? Еще десятка классов всяко разных? Или чего? В чем проблема GDI+?
Кто-нибудь может задачу/проблему-то описать? Только без эзотерики.
Я свою гипотезу изложил почему медленно и как надо правильнно.
Макс на примере AGG, я на примере Harmonia/HTMLayout демонстрируем наши подходы на практике.
C>В итоге теперь мы прикрутили софтовый Mesa GL и при печати делаем C>рендеринг изображения по кусочкам (100-200Мб размером) во внеэкранный C>буффер. Эти изображения парраллельно отсылаем на принтер.
...
C>Вообще, принтеры умеют нормально растеризовать только небольшие C>фрагменты векторных описаний — символы из шрифтов, например.
По моим экспериментам — это зависит от памяти принтера. Боролся как-то с цветным лазерным принтером — громадина старая на 64М памяти. Кое-какие фото A3 не выводит и все тут... Памяти не хватало...
vdimas wrote: > C>Вообще, принтеры умеют нормально растеризовать только небольшие > C>фрагменты векторных описаний — символы из шрифтов, например. > По моим экспериментам — это зависит от памяти принтера. Боролся как-то с > цветным лазерным принтером — громадина старая на 64М памяти. Кое-какие > фото A3 не выводит и все тут... Памяти не хватало...
Принтеры — существа нежные. Изображения надо печатать по кусочкам, чтобы
умешались в буффер принтера.
Здравствуйте, Cyberax, Вы писали:
C>Принтеры — существа нежные. Изображения надо печатать по кусочкам, чтобы C>умешались в буффер принтера.
C>У нас печатаются полосками по 20-30Мб толщиной.
То есть, вы гоните через всю сеть эти толстые битмапы? А вообще, просто GDI на принтерный DC почему не работает? У меня вроде бы все работает, правда я не знаю, что делается там внутри — возможно тоже растеризуется в пямяти.
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
McSeem2 wrote: > C>У нас печатаются полосками по 20-30Мб толщиной. > То есть, вы гоните через всю сеть эти толстые битмапы?
А что делать? На самом деле не так уж и тормозит на 100МБит или по USB2.
> А вообще, просто GDI на принтерный DC почему не работает?
Он принтеру напрямую передает только простейшие команды (рисование
текста, простых линий и т.п.)
> У меня вроде бы все работает, правда я не знаю, что делается там > внутри — возможно тоже растеризуется в пямяти.
Так и делаем. Только внутри он все равно сам все растеризует, причем с
ограничением в 2Гб по возможному размеру картинки (у нас бывают и
намного больше).
MS>>Как так "растровая"? Я чего-то не понимаю. Как только у нас возникают функции MoveTo/LineTo, все — мы уже имеем дело с векторными примитивами.
V>
V>Понимаешь, после выполнения операции MoveTo ты не можешь получить линию как объект. ТЫ получаешь ее растровое представление (в большинстве случаев, WMF — отдельный случай).
А здесь речь идет не о библиотеке как таковой, а о модели данных. Грубо говоря (сильно утрированно!), XML DOM имеет к этому вопросу большее отношение, чем GDI+. Не надо все в одну кучу валить. Есть модель данных, например, Flash. Есть проигрыватель Flash. И никому не приходит в голову требовать от проигрывателя векторные примитивы. Вот GDI+ — это и есть некий такой проигрыватель. И он — векторный, что характерно. Так понятней?
MS>>Смею заверить, что Transform это не свойство "графического примитива", это — свойство конвейера.
V>Почему? У меня есть некий овал. На конкретной сцене я его повернул как угодно. Так к чему мне привязать это св-во?
Начнем с вопроса — а зачем это "свойство" к чему-то привязывать? И почему поворот должен быть свойством? Вообще-то поворот — это операция.
V>Я же сказал, основные св-ва примитивов в графической сцене: Origin, Transform, Children. То, что ты называешь конвеером — это такой спецальный вид графического объекта, который генерирует другие объекты? Я же говорю об иерархии контейнеров. Это немного другой взглдя на вещи, более "традиционный". Смотрим тот же FreeHand. Они запоминают ОПЕРАЦИИ, но запомненная операция у них — это такой объект... Наверно, как твой конвеер.
Ну, во-первых, не надо путать модель данных (контейнер) с "рисовальщиком". Во-вторых, зачем надо запоминать ОПЕРАЦИИ? Чтобы Undo сделать? Ну так это еще более другая категория — категория редактирования данных.
И еще раз — что такое "графический примитив"?
Короче говоря, я так и не понял, чего же ты хочешь сказать. Есть лекторы двух типов. После речи первого все думают "надо же какой он умный — ничего не понятно". После речи второго — "какой лектор дурак — мне все понятно!". Я стремлюсь, чтобы меня относили ко второй категории.
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
Здравствуйте, c-smile, Вы писали:
CS>GDI как и GDI+ будут эмулирваться в CS>Windows Graphics Foundation которая есть "многоканальная" версия DirectX.
Вы оба неправы . WGF, когда (если) оно будет, будет предназначено скорее для игрушек и low level. Для десктопа будет использоваться System.Windows.Media, под которым может быть и GDI+, и теперешний DirectX, и будущий WGF, и специализированные, заточенные под конкретное устройство вывода, библиотеки..
P.S. Свойства Color в System.Windows.Media нет ни у Pen, ни у базового Brush.
... << RSDN@Home 1.2.0 alpha rev. 624 on Windows XP 5.1.2600.131072>>
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, c-smile, Вы писали:
CS>>GDI как и GDI+ будут эмулирваться в CS>>Windows Graphics Foundation которая есть "многоканальная" версия DirectX.
AVK>Вы оба неправы . WGF, когда (если) оно будет, будет предназначено скорее для игрушек и low level. Для десктопа будет использоваться System.Windows.Media, под которым может быть и GDI+, и теперешний DirectX, и будущий WGF, и специализированные, заточенные под конкретное устройство вывода, библиотеки..
В данном случае речь идет не про то как в .NET будет видеть рисовательный слой.
Я отвечал на вопрос как будут выглядеть legacy native GDI/GDI+ интерфейсы.
Здравствуйте, Cyberax, Вы писали:
C>c-smile wrote: >> Только битмап то только на экран можно это самое... На принтере-то >> пикселов нет... C>Есть, есть. Только они маленькие....
Тебя обманули.
Есть dots перменного размера которые не привязаны к решетке.
Смотрим например что есть REt и думаем почему PS это родной формат ввода для принтеров.
C>-- C>С уважением, C> Alex Besogonov (alexy@izh.com)
Здравствуйте, Cyberax, Вы писали:
C>McSeem2 wrote: >> C>У нас печатаются полосками по 20-30Мб толщиной. >> То есть, вы гоните через всю сеть эти толстые битмапы? C>А что делать? На самом деле не так уж и тормозит на 100МБит или по USB2.
Как-то это все подозрительно выглядит.
Т.к. струйным нужен один тип "bitmap", лазерным нужно другой тип.
>> У меня вроде бы все работает, правда я не знаю, что делается там >> внутри — возможно тоже растеризуется в пямяти. C>Так и делаем. Только внутри он все равно сам все растеризует, причем с C>ограничением в 2Гб по возможному размеру картинки (у нас бывают и C>намного больше).
Это для лазерных принтеров как я понимаю?
C>-- C>С уважением, C> Alex Besogonov (alexy@izh.com)
Здравствуйте, c-smile, Вы писали:
CS>В данном случае речь идет не про то как в .NET будет видеть рисовательный слой.
Это не просто .NET, это WinFX.
CS>Я отвечал на вопрос как будут выглядеть legacy native GDI/GDI+ интерфейсы.
Точно так же, как они выглядят сейчас. Какой смысл это обсуждать? И насчет эмуляции все намного сложнее. Тут пока непонятно что в Висте с ними будет, особенно при работающем DCE, а там ведь пока никакого WGF не планируется.
CS>Windows Graphics Overview
Я ее смотрел. И ей уже 200 лет. На практике там наверняка уже все поменялось.
... << RSDN@Home 1.2.0 alpha rev. 624 on Windows XP 5.1.2600.131072>>
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, c-smile, Вы писали:
AVK>>>Я ее смотрел. И ей уже 200 лет. На практике там наверняка уже все поменялось.
CS>>Это с WinHEC 2005 (Апрель)
AVK>Ну я и говорю — 200 лет в обед. Для сравнения — последний CTP WinFX — конец ноября и от апрельского он отличается как небо от земли.
Если за это время все поменялось настолько радикально то можно уже говорить о том что
реально в обозримые сроки ничего не будет.
Здравствуйте, c-smile, Вы писали:
AVK>>Ну я и говорю — 200 лет в обед. Для сравнения — последний CTP WinFX — конец ноября и от апрельского он отличается как небо от земли.
CS>Если за это время все поменялось настолько радикально то можно уже говорить о том что CS>реально в обозримые сроки ничего не будет.
Это ты о чем?
... << RSDN@Home 1.2.0 alpha rev. 624 on Windows XP 5.1.2600.131072>>
Здравствуйте, vdimas, Вы писали:
V>Прекрасно понимаем о чем ты, но не для того был разработан GDI, не для того... GDI — это абстракция устройства, а не графического редактора. А устройства всякие бывают. И как всегда при разработке оптимизировали самые критичные моменты, коими вывод на экран не является.
А что является? Что конкретно? Какие такие "устройства" и какими они бывают "разными"?
V>Если бы они сделали как предлагаешь ты, то от виндов отвернулись бы производители устройств в первую очередь, ибо — не было бы смысла вкладывать силы в реализацию сверхсложного АПИ, 99% из которого устройство не способно поддержать физически ...
Подобные заявления должны подкрепляться некими доказательствами. Перечисли хотя бы несколько устройств, напрямую поддерживающих GDI+. Или производителей устройств, которые бы "отвернулись от виндов, если бы было сложнее". Я верю, что такие имеются, но мне просто хотелось бы знать кого-то конкретно для примера. В противном случае эти заявления пахнут демагогоией.
Ну и потом — не вижу большой связи между неким API (GDI, GDI+) и интерфейсом устройства. Безусловно, связь присутствует, но требовать от устройства поддержки полной спецификации GDI+ — это маразм.
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
Здравствуйте, vitaly_spb, Вы писали:
B>>пользователь должен быть замкнут.
_>у нас в универе была такая шутка: математик должен быть компактен — ограничен и замкнут (кто помнит топологию поймет)
Угу. Только не для всех пространств прокатывает. В общем случае Гильбертова пространства ограниченности и замкнутости недостаточно для компактности
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
c-smile wrote: > C>А что делать? На самом деле не так уж и тормозит на 100МБит или по USB2. > Как-то это все подозрительно выглядит. > Т.к. струйным нужен один тип "bitmap", лазерным нужно другой тип.
Преобразовывать их драйвера сами прекрасно умеют. Хотя мы тестировали с
простыми струйными принтерами.
>> > У меня вроде бы все работает, правда я не знаю, что делается там >> > внутри — возможно тоже растеризуется в пямяти. > C>Так и делаем. Только внутри он все равно сам все растеризует, причем с > C>ограничением в 2Гб по возможному размеру картинки (у нас бывают и > C>намного больше). > Это для лазерных принтеров как я понимаю?
Да. Лучше всего показал себя фотонаборный аппарат за $50000 — там было
4Гб памяти, куда влезала большая часть картинки
Здравствуйте, McSeem2, Вы писали:
MS>Подобные заявления должны подкрепляться некими доказательствами. Перечисли хотя бы несколько устройств, напрямую поддерживающих GDI+.
A common theme of GDI+ is the integration of 2-D and 3-D, from the API (application programming interface) to the DDI (device driver interface). On the DDI side, GDI+ will use existing 2-D and 3-D hardware acceleration capabilities by leveraging the Microsoft Direct3D® command stream for all hardware acceleration. GDI+ will use a mixture of D3D and GDI+ command tokens for all its rendering. In this way, GDI+ will share a common driver interface with Direct3D, giving the following benefits:
•
GDI+ can freely intermix "3-D" and "2-D" rendering without incurring costly state changes.
•
There will be reduced code duplication in the driver from eliminating multiple ways to access the same hardware accelerations, with corresponding improvements in test coverage.
•
There will be more efficient resource utilization for writing drivers and doing optimization and debugging, resulting in better drivers.
GDI+ will define new tokens for primitives that are not already described by existing Direct3D and DirectDraw tokens. All GDI+ accelerated drawing primitives will be much "closer to the metal" than is so with GDI, with less abstraction of the hardware. For example, GDI+ might specify "draw this list of triangles" instead of "stroke this path with this geometric pen."
For backward compatibility considerations, the existing GDI DDI will continue to be supported.
Call to Action
•
Graphics accelerators should be prepared for mixtures of 2-D and 3-D drawing primitives in the command stream. It should not be expensive to do a context switch between "2-D" and "3-D" drawing primitives.
Здравствуйте, AndrewVK, Вы писали:
MS>>Подобные заявления должны подкрепляться некими доказательствами. Перечисли хотя бы несколько устройств, напрямую поддерживающих GDI+.
[. . .] AVK>
Graphics accelerators should be prepared for mixtures of 2-D and 3-D drawing primitives in the command stream. It should not be expensive to do a context switch between "2-D" and "3-D" drawing primitives.
Это все конечно хорошо, но совершенно неубедительно. Что-нибудь более конкретное, кроме пропаганды светлого будущего вообще имеется? Или хотя бы планируется? Под конкретным понимается, например, закраска полигонов внутри железяки, причем без предварительной триангуляции (то есть, триангуляция, если она нужна, должна быть внутри железяки). Ну или хотя бы рисование полилинии произвольной толщины. Да, ну и разумеется, чтобы было пригодно к использованию — то есть со сгаживанием границ и субпиксельным позиционированием. А то вон говорят, что OpenGL умеет линии рисовать, а на поверку это оказывается не более чем слухами. Не умеют пока что железячники линии рисовать, следовательно и разговоры о глубокой хардварной поддержке GDI+ — это не более, чем маркетинговый трындеж.
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
Здравствуйте, McSeem2, Вы писали:
MS>Это все конечно хорошо, но совершенно неубедительно. Что-нибудь более конкретное, кроме пропаганды светлого будущего вообще имеется?
Ссылочку я дал, если интересно можешь поковырять.
MS> Или хотя бы планируется?
Не планируется. GDI+ вобщем то уже устарел. Теперича рулит System.Windows.Media поверх DirectX. И в нем да, в нем аппаратной акселерации должно быть очень много.
... << RSDN@Home 1.2.0 alpha rev. 624 on Windows XP 5.1.2600.131072>>
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, c-smile, Вы писали:
AVK>>>Ну я и говорю — 200 лет в обед. Для сравнения — последний CTP WinFX — конец ноября и от апрельского он отличается как небо от земли.
CS>>Если за это время все поменялось настолько радикально то можно уже говорить о том что CS>>реально в обозримые сроки ничего не будет.
AVK>Это ты о чем?
Это я о том что если графическая подсистема "конеца ноября отличается как небо от земли от апрельского" (этого года) то это значит что надежного решения (stable API) еще ждать года три как минимум.
Т.е. старый добрый GDI будет все это время "рулить".
И даже более того — так как в нем в принципе все есть для "повседневного UI" то и потом. Т.е. лет десять как минимум.
Даже тот самый antialiasing... достаточно поднять разрешение раза в два и он в принципе уже не нужен на экране.
Здравствуйте, Cyberax, Вы писали:
C>c-smile wrote: >> C>А что делать? На самом деле не так уж и тормозит на 100МБит или по USB2. >> Как-то это все подозрительно выглядит. >> Т.к. струйным нужен один тип "bitmap", лазерным нужно другой тип. C>Преобразовывать их драйвера сами прекрасно умеют. Хотя мы тестировали с C>простыми струйными принтерами.
Согласен что умеют, но памяти при этом кушают — мама, не горюй.
>>> > У меня вроде бы все работает, правда я не знаю, что делается там >>> > внутри — возможно тоже растеризуется в пямяти. >> C>Так и делаем. Только внутри он все равно сам все растеризует, причем с >> C>ограничением в 2Гб по возможному размеру картинки (у нас бывают и >> C>намного больше). >> Это для лазерных принтеров как я понимаю? C>Да. Лучше всего показал себя фотонаборный аппарат за $50000 — там было C>4Гб памяти, куда влезала большая часть картинки
Опять я не понял. А как тогда обычный принтер фотографии печатает?
Или ваша картинка имеет разрешение "больше" принтерного ( смысл чего мне не ясен )
или я не знаю.
Кстати бытовые струйники делают преобразование в памяти PC (в драйвере) — на принтер
уходят "ленты".
Т.е. памяти не должно хватать на PC а не на принтере.
C>-- C>С уважением, C> Alex Besogonov (alexy@izh.com)
Здравствуйте, vdimas, Вы писали:
MS>>Как так "растровая"? Я чего-то не понимаю. Как только у нас возникают функции MoveTo/LineTo, все — мы уже имеем дело с векторными примитивами.
V>
V>Понимаешь, после выполнения операции MoveTo ты не можешь получить линию как объект. ТЫ получаешь ее растровое представление (в большинстве случаев, WMF — отдельный случай).
Вообще-то в данном случае Graphics можно рассматривать как одну из реализаций паттерна Строитель. Тогда MoveTo/LineTo всего лишь методы строителя которые могут делать все что угодно. Могут отрисовываться в точечный контест создавая последовательности пикселей. А могут приспокойно создавть ДОМ-дерево некой объектной модели.
Кстати, в Авалоне биледры идругие паттерны используются во всю.
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, McSeem2, Вы писали:
MS>Короче говоря, я так и не понял, чего же ты хочешь сказать. Есть лекторы двух типов. После речи первого все думают "надо же какой он умный — ничего не понятно". После речи второго — "какой лектор дурак — мне все понятно!". Я стремлюсь, чтобы меня относили ко второй категории.
Сэр! Каой вы умный! Я нихрена не понял!
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, c-smile, Вы писали:
CS>Я помню ты говорил что переписываешь Drawing? CS>А с какой целью можно узнать?
К сожалению GDI+ не умеет отрисовать текс с фоном. Без этого если не включать сглаживаение получается нехилое моргание. А если включать, то слабые видюхи не тянут. Плюс мой вариант примерно вдвое быстрее GDI+-ного. Мне ведь их выпендрежи (сглаживаение, полупрозрачности, текстурирвоание текста...) не нужны. Вопрос стоял так. Или опримизировать отрисовку перерисовывая дельту изменившуюся при редактировании или немного разогнав отрисовку оставить перерисовку всего экрана. Как бы лень победила.
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, c-smile, Вы писали:
CS>Это я о том что если графическая подсистема "конеца ноября отличается как небо от земли от апрельского" (этого года) то это значит что надежного решения (stable API) еще ждать года три как минимум.
Ошибаешься. Судя по последним билдам API более менее стабилизировалось. Так что через год закончат.
CS>Даже тот самый antialiasing... достаточно поднять разрешение раза в два и он в принципе уже не нужен на экране.
Этого точно не будет на десктопах в юлижайшее время.
... << RSDN@Home 1.2.0 alpha rev. 624 on Windows XP 5.1.2600.131072>>
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, c-smile, Вы писали:
CS>>Это я о том что если графическая подсистема "конеца ноября отличается как небо от земли от апрельского" (этого года) то это значит что надежного решения (stable API) еще ждать года три как минимум.
AVK>Ошибаешься. Судя по последним билдам API более менее стабилизировалось. Так что через год закончат.
"Зуб даешь?"
CS>>Даже тот самый antialiasing... достаточно поднять разрешение раза в два и он в принципе уже не нужен на экране.
AVK>Этого точно не будет на десктопах в юлижайшее время.
А два зуб сразу дать слабо?
IBM's 200 ppi "Roentgen" LCD Display
native resolution of 3840x2400 pixels. Это еще в 2003 году было.
Аналогичный от ViewSonic
Но это дороговато.
К концу года IBM обещает нечто более практичное: quad SXGA (2560*2048) с 122 ppi.
Что в общем-то уже совсем близко к тому что ты видишь на бумаге.
vdimas wrote: > CS>Как-то это все подозрительно выглядит. > CS>Т.к. струйным нужен один тип "bitmap", лазерным нужно другой тип. > У струйников драйвер DC в память PC растерезит, а в лазерниках — > растерезит сам принтер в своей памяти.
Не все так просто — память у большинства принтеров не очень большая, так
что цветная картинка на полный A4 туда просто не влезла бы.
Здравствуйте, c-smile, Вы писали:
AVK>>Ошибаешься. Судя по последним билдам API более менее стабилизировалось. Так что через год закончат.
CS>"Зуб даешь?"
МС дает.
CS>>>Даже тот самый antialiasing... достаточно поднять разрешение раза в два и он в принципе уже не нужен на экране.
AVK>>Этого точно не будет на десктопах в юлижайшее время.
CS>А два зуб сразу дать слабо?
CS>IBM's 200 ppi "Roentgen" LCD Display
IBM такие дисплеи выпускала чуть ли не 10 лет назад. А воз и ныне там.
CS>К концу года IBM обещает нечто более практичное: quad SXGA (2560*2048) с 122 ppi. CS>Что в общем-то уже совсем близко к тому что ты видишь на бумаге.
Ага, и по цене такой, что о массовом применении можно даже не думать.
Ты пойми, проблема не в том, чтобы сделать такой дисплей, а в том чтобы выход годных при производстве был приемлемым. А для этого, похоже, нужно сильно менять технологию.
Здравствуйте, Sinclair, Вы писали:
_>>у нас в универе была такая шутка: математик должен быть компактен — ограничен и замкнут (кто помнит топологию поймет) S>Угу. Только не для всех пространств прокатывает. В общем случае Гильбертова пространства ограниченности и замкнутости недостаточно для компактности
Гильбертово пространство в данном случае не общий случай, а очень даже частный. Общим случаем было бы, наверное, метрическое пространство.
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, McSeem2, Вы писали:
MS>>Подобные заявления должны подкрепляться некими доказательствами. Перечисли хотя бы несколько устройств, напрямую поддерживающих GDI+.
AVK>А вот что собственно этот support означает: AVK>http://www.microsoft.com/whdc/archive/GDInext.mspx#EEE AVK>
A common theme of GDI+ is the integration of 2-D and 3-D, from the API (application programming interface) to the DDI (device driver interface). On the DDI side, GDI+ will use existing 2-D and 3-D hardware acceleration capabilities by leveraging the Microsoft Direct3D® command stream for all hardware acceleration. GDI+ will use a mixture of D3D and GDI+ command tokens for all its rendering. In this way, GDI+ will share a common driver interface with Direct3D, giving the following benefits:
Цитата конечно впечатляет, но если помотреть на дату документа становиться грустно :
Draft March 10, 1999
Updated: December 4, 2001
Arhived Paper.
Вот список функций GDI
котрые могут реализовываться аппаратно.
Большая часть этих функций была еще в WinNT, с выходом Win2k добавились DrvGradientFill,TransparentBlt AlphaBlend и еще несколько.
Похоже именно эти новые функции и считаются относящимися к поддержке GDI+ .
Поддержка Direct3D планировалась , но сейчас ее нет, по крайней мере я никогда не видел
в списке загруженных Dll,(рядом с GDIPlus.dll) хоть одну относящихся к Direct3D... видео у меня не самое слабое (Radeon X850 XT).
Здравствуйте, c-smile, Вы писали:
CS>Даже тот самый antialiasing... достаточно поднять разрешение раза в два и он в принципе уже не нужен на экране.
16х будет соотвествовать где-то задиранию разрешения раз в 8. Сам как-то сравнивал разницу в картинке Doom3 в разных режимах. Приел к выводу, что все же 16х на 1024 лучше, чем 1280 без сглаживания. Но так как это все безбожно тормозило, то отключил сглаживание к чертям. Все равно в движении тебе оно по фигу.
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Cyberax, Вы писали:
C>vdimas wrote: >> CS>Как-то это все подозрительно выглядит. >> CS>Т.к. струйным нужен один тип "bitmap", лазерным нужно другой тип. >> У струйников драйвер DC в память PC растерезит, а в лазерниках — >> растерезит сам принтер в своей памяти. C>Не все так просто — память у большинства принтеров не очень большая, так C>что цветная картинка на полный A4 туда просто не влезла бы.
Угу, в этом и загвоздка. Те лазерники, которые растерезят именно в свою память иногда имеют проблемы с некоторыми картинками, если память не проапгрейдить.
(работал с лазерниками, которые выплевывают по 30 листов в минуту — эдакие печатные станки, они работают только со своей памятью)
Здравствуйте, McSeem2, Вы писали:
V>>Понимаешь, после выполнения операции MoveTo ты не можешь получить линию как объект. ТЫ получаешь ее растровое представление (в большинстве случаев, WMF — отдельный случай).
MS>А здесь речь идет не о библиотеке как таковой, а о модели данных. Грубо говоря (сильно утрированно!), XML DOM имеет к этому вопросу большее отношение, чем GDI+. Не надо все в одну кучу валить. Есть модель данных, например, Flash. Есть проигрыватель Flash. И никому не приходит в голову требовать от проигрывателя векторные примитивы. Вот GDI+ — это и есть некий такой проигрыватель. И он — векторный, что характерно. Так понятней?
Понятен взгляд на вещи. Непонятен вывод — он векторный. Там Влад правильно ниже про билдеры сказал. LineTo — это просто один из методов рисования, что он генерирует — не важно. Для WMF — это генерация команды LineTo, для BMP — генерация серии точек.
И насчет Flash. Ты легко можешь получить из ролика его составляющие, и векторные примитивы в т.ч. Кстати, тебя не смущает, что в Flash я тоже могу задавать цвет, толщину и прозрачность линий?
V>>Почему? У меня есть некий овал. На конкретной сцене я его повернул как угодно. Так к чему мне привязать это св-во?
MS>Начнем с вопроса — а зачем это "свойство" к чему-то привязывать? И почему поворот должен быть свойством? Вообще-то поворот — это операция.
Вообще-то, построение линии — это тоже операция. Ничего, если я предлагаю тебе представить отрезок как объект?
Я, кажется, допер до твоей точки зрения. У тебя такой взгляд на вещи, что графику надо рисовать только программно, так? У меня немного другое мнение, особенно, если это касается сложной графики, как в твоем примере. Программист должен предоставлять инструмент, а рисует пусть художник.
Ну а трансформация — это неотъемлемая часть процесса редактирования векторной сцены. Я не против для некоторых примитивов присвоить ей null (в терминах... неважно чего )
MS>Ну, во-первых, не надо путать модель данных (контейнер) с "рисовальщиком".
Кстати, правильное замечание, я тебе его уже который раз делаю, другими словами.
Но, даже пользуясь твоей терминологией — рисовальщики разные бывают. Какой-то из них пусть будет способен рисовать контейнеры и т.д. рекурсивно.
MS>Во-вторых, зачем надо запоминать ОПЕРАЦИИ? Чтобы Undo сделать?
Чтобы воспроизвести. Чтобы клонировать. Чтобы редактировать затем параметры последовательности, порождая другие. Это продолжение того вопроса — как генерить графику: полностью программно или же описательно, доступно редактору+художнику.
Кстати, в конвеере OpenGL есть похожая фича — запомнить последовательность операций, затем применить многократно. Чем не способ порождения твоих же конвееров?
MS>Ну так это еще более другая категория — категория редактирования данных.
Данные — слишком общее понятие. И набор операций тоже можно представить как данные. Просто это будет немного другой плеер. Вот кажется я нащупал точку разногласия. Ты выступаешь за "непосредственные" плееры, т.е. за алгоритмические. Получается, чтобы по-другому нарисовать ту же пресловутую кнопку мне нужен будет другой алгоритм. Мммм... не очень красиво...
И кстати, к твоим конвеерам тоже можно привязать данные. Для твоих "конвееров" данными будут являться их св-ва, например конвеер, генерирующий последовательность точек имеет как минимуму св-ва: {шаг, радиус}.
MS>И еще раз — что такое "графический примитив"?
Это некие объекты, составляющие некий базис. Возможно, я неверно применил однажды этот термин. Читать как "графический объект".
Правда, прикол в том, что можно и не читать как "графический объект", а продолжать употреблять "графический примитив", ибо выбор базиса никто не ограничивает. Ввиду того, что я представляю себе возможность объединения графических объектов в некие более крупные объекты-контейнеры (с учетом трансфомаций!!! именно здесь я их хочу привязать к объектам, если ты еще не понял в каком контексте я ее упоминаю), то так же я хочу рассматривать полученные объекты затем как единое целое и как базис для объектов следующего уровня и т.д.
Т.е. это из области "что такое объект?". Примерно то же самое. Даже с агрегацией и инкапсуляцией.
Например, результатом работы твоего конвеера по рисованию пунктира является некое множество более простых элементов. В простейшем случае — это последовательность кривых или окружностей. Хотя, кто нам мешает генерировать вместо окружностей/отрезков последовательность вообще любых графических примитивов. Просто вместо набора св-в: {шаг, радиус} надо иметь набор: {шаг, трансформ}
Насколько я понимаю, в твоем представлении тоже самое может достигаться как "сцепка" конвееров. Почему бы нет? А можно я в твоих же терминах назову свой объект-агрегат разновидностью конвеера? Хотя, это твоя терминология. Мне не нравится слово "конвеер" применительно к построению сцены.
И еще у нас разный взгляд на вещи в этом:
И чтобы выход трансформера можно было использовать идентичным образом как для рисования, так и для записи в файл.
Без дополнительных пояснений это понимается как запись в файл простейших команд типа LineTo даже при прорисовке сложных контейнеров. Правильно тебя понял? В общем, весьма неоптимальное и непригодное к "повторному применению" представление. Хотелось бы в файлах хранить модель в первозданном виде. А так... для описанного тобой есть WMF — тот же BMP, только в профиль (ничего, что сравнил векторное с растровым?)
MS>Короче говоря, я так и не понял, чего же ты хочешь сказать. Есть лекторы двух типов. После речи первого все думают "надо же какой он умный — ничего не понятно". После речи второго — "какой лектор дурак — мне все понятно!". Я стремлюсь, чтобы меня относили ко второй категории.
Я пока хотел понять причины, по которым ты пытался смешать в кучу векторное, растровое, данные и операции и уровень №0 — GDI.
Хотя, я немного разобрался. Твой взгляд на вещи таков, что графику надо генерировать только программно. Если ты настаиваешь на таком положении вещей, то мне нечего добавить, ибо незачем. Могу только сделать замечание о твоем стремлении сделать что-то узкоспециализированное по концепции (невзирая на "открытость" реализации).
Иначе — можно пообсуждать вопрос "гладкой" стыковки модели твоих конвееров и модели графических объектов типа DOM XML.
А так же попытаться разобраться, где здесь место плеерам и конвеерам, в расчете на некую универсальность. А так же постараться не забыть, что наиболее частоиспользуемые вещи должны делаться наиболее просто. И GDI/GDI+ этому вполне отвечает.
Заодно, я уверен, можно будет придти к интересному мнению: "ну и хрен с ней, с GDI/GDI+". Ибо, ну нафига тебе потратить кучу усилий на некое платформенно-зависимое решение? Мне представляется, что сформалировав свои плееры/конвееры тебе должно быть глубоко фиолетово, что лежит на самом низком уровне.
Здравствуйте, c-smile, Вы писали:
CS>Для реализации такой идеологии больше подходит функциональный стиль CS>который проверен веками: PS/metafile со товарищи.
Кстати, PS — это не функциональный стиль, это нечто вроде Forth. Ты производишь не вычисления, а определяешь последовательности операций, которые затем используешь в других операциях и т.д. иерархически.
Metafile — немного по-другому.
CS>т.е. рисование состоит из цепочек атомарных и простых примитивов
В метафайле — да, в PS — нет. PS — это программа.
CS>Классов там нет — ибо нельзя описать то что ты еще не знаешь.
Там есть операции. И их можно описать для повторного применения. Что не так?
CS>В моем примере (и в примере Макса) Pen это в общем случае цепочка (или конвейер) неких рисовательных действий.
CS>Укладывать же сию неописуемую (буквально) сущность в прокрустово ложе классов — по меньшей мере ошибка.
Поясни выделенное. Почему я не могу алгоритм рисования + его параметры оформить в виде инстанса некоего объекта? Да оно само напрашивается именно на такое представление. Если ты представишь по-другому описанное (разделишь некий алгоритм/конвеер и набор его параметров), то это будет эмуляция того же ОО, ибо чаще всего некий алгоритм будет привязан к уникальной структуре собственных параметров.
Другими словами, можно я буду рассматривать алгоритмы/конвееры без параметров как некий очень частный случай?
На самом деле не так уж и тормозит на 100МБит или по USB2.
1.1.4 stable rev. 510
видео у меня не самое слабое (Radeon X850 XT).