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, не более того. Ты всерьез считаешь, что нормальный редактор должен делать рендеринг прямо на экран?
Не понял? Почему не объехать? Нельзя рисовать по точкам или плюнуть в него битмапом? Он тебе даже антиалиасинг заботливо сделает, если хочешь
