Здравствуйте, 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
Я жертва цепи несчастных случайностей. Как и все мы.
На самом деле не так уж и тормозит на 100МБит или по USB2.
