Здравствуйте, 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>Укладывать же сию неописуемую (буквально) сущность в прокрустово ложе классов — по меньшей мере ошибка.
Поясни выделенное. Почему я не могу алгоритм рисования + его параметры оформить в виде инстанса некоего объекта? Да оно само напрашивается именно на такое представление. Если ты представишь по-другому описанное (разделишь некий алгоритм/конвеер и набор его параметров), то это будет эмуляция того же ОО, ибо чаще всего некий алгоритм будет привязан к уникальной структуре собственных параметров.
Другими словами, можно я буду рассматривать алгоритмы/конвееры без параметров как некий очень частный случай?
