Это уже офтоп, ну да ладно.
AG>Максим, меня в AGG не устраивают 3 вещи: AG>1. Он не принимает на вход аналог gdi hatch brush
Да, закраска сплошным цветом принципиально отличается от какой-либо еще.
Для hatch brush надо использовать span_pattern_rgba — простой паттерн без трансфопмаций или span_pattern_filter_rgba span_pattern_resample_rgba — аналог текстурирования с произвольными трансформациями. Примеры — pattern_fill.cpp, pattern_perspective.cpp, pattern_resample.cpp
AG>2. Что-то там накрутили с clipping regions. Т.е. как я могу clip rgn, выделенный в HDC, передать в AGG, чтобы он не рисовал по запрещенным участкам? Опять же, лицензия на использование clipping — либы.
GPC надо использовать, если есть насущная необходимость получать данные в векторном представлении. Для чисто визуального отсечения по регионам есть scanline boolean algebra и есть alpha-mask. Примеры — alpha_mask*.cpp и scanline_boolean*.cpp. Визуальный эффект — тот же, работает в разы быстрее и нет ограничений на использование. GPC — удовольствие дорогое, scanline boolean — дешево и сердито.
AG>3. Clip работает крайне медленно, если координаты большие. Пример — рисуем линию с x=от -10000 до 10000, clip rect (0,0,5,5). В этом случае на AGG тормоза начинаются просто нереальные, хотя на GDI и GDI+ это вообще никак не влияет, они рисуют эти 5 пикселов без лишних раздумий.
Более того — он и памяти при этом мощно отъест (ну, не так мощно как дот-нет, но все же).
Это неизбежно при loosely coupled дизайне. Растеризатор понятия не имеет, что тем есть какие-то окна, в которые надо чего-то рисовать с отсечением. Его задача — выдать набор сканлайнов, которые будут потом использоваться не обязательно для рисования. Соответственно, надо явным образом "объяснить" растеризатору, чтобы он отсекал в векторном виде: ras.clip_box(x1, y1, x2, y2);
Но и это еще не все. Если значения координат не вписываются в 24 бита, возникнут глюки из за переполнения. Для устранения этого можно последним элементом конвейера поставить conv_clip_polygon — он работает чуть медленнее, чем встроенный клиппер, но зато обеспечивает честное отсечение при любых масштабах — хоть космических.
И вообще, дизайн таков, что использовать библиотеку непосредственно — это плохая идея. Надо сначала завернуть требуемую функциональность во что-то типа GDI+ного Graphics или Java2D. И использовать уже ее. Почему это не сделать сразу? Да просто потому, что если завернуть всю функциональность, то получится неуклюжий монстр. Надо действовать как-то более избирательно.
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
Здравствуйте, ArtemGorikov, Вы писали:
AG>Да, что-то было, просто хотелось бы иметь уже реализованным, чтобы принимало на вход LOGBRUSH.
Понятно. Но я не позиционирую AGG в качестве некого готового решения. Это просто набор пил, топоров и стамесок для краснодеревщика, но не сами окна-двери-наличники.
AG>Вы не ответили на вопрос: как полученный у HDC регион (HRGN) скормить растеризатору? Если бы это был только clipbox, тогда было бы все просто. И даже после того, как написал транслятор из HRGN в формат либы клиппера, как быть с ее лицензией?
Не ответил. Беда в том, что я понятия не имею, что такое HRGN, как из него вытащить данные и как они вообще представлены. В виде скан-лайнов или в виде полигона? Если первое (есть подозрение, что это так), то можно написать простой класс, который ведет себя как растеризатор (rewind_scanlines/sweep_scanline) и использовать его вместо растеризатора для дальнейших операций. Если это полигон — его надо предварительно растеризовать при помощи того же rasterizer_scanline_aa и потом уже использовать в scanline_boolean.
AG>ras.clip_box(x1, y1, x2, y2) — это я и вызывал, иначе имеем падение с Access Violation. В том случае мне еще не надо было отсекать регионы.
Падение без clip_box с гигантскими координатами вполне объяснимо, а вот почему медленно работало при включенном отсечении — это для меня загадка. Может быть, это был не rasterizer.clip_box(), а renderer.clip_box()? renderer_base тоже имеет такую функцию и она выполняет отсечение в растровом виде.
AG>Т.е. можно включить отсечение регионов и не получить гемора с лицензией? AG>conv_clip_polygon — и решать проблему с лицензией?
Если нужно только отсечение по ортогональному прямоугольнику — то да. Еще раз — rasterizer.clip_box() эквивалентен conv_clip_polygon, если координаты не вылезают за пределы 24-х бит. Если с этим были проблемы — то я не исключаю возможность глюка, хотя это и маловероятно, поскольку многократно проверено. Скорее всего имело место какое-то недопонимание (но я ни в коем случае не снимаю с себя ответственности за это).
AG>Почему бы не иметь неуклюжего монстра размером в 1-1.5 метра, если GDI+ весит столько? В наше время это не размер, и хорошо бы иметь сборки в виде либы и dll, с макросами, определяющими используемые возможности. AG>А сейчас получается, что с GDI+ на порядок меньше траха, он принимает GDI объекты и его константы на входе, не озадачивается особенно форматом устройства вывода и "космическими координатами". Только вот качество его антиалиасинга не супер
Вполне согласен. С точки зрения программиста, которому надо "нарисовать-линию-и-фсе", AGG — это далеко не лучший выбор. Я этого и не скрываю. Теоретически, конечно же, если бы был такой класс типа Graphics — это было бы гораздо более usable. Но здесь уже вступает в силу некая диалектика. Беда в том, как всю эту квачу поддерживать. GDI+ поддерживает толпа голодных индусов. Им бы только на хлеб заработать, а на чем — это совершенно не существенно. Для меня же это существенно. Просто потому, что я не "толпа голодных индусов" и весь этот объем рутинной работы я просто-напросто не потяну в одиночку. При таком подходе очень велик риск попасть в сказку-неотвязку (never ending story) — то есть, когда все силы будут уходить только на поддержку. Я же хочу работать и над новыми алгоритмами, типа ClearType-like rendering. Поэтому и такое отношение. Вполне допускаю, что это не лучшее отношение.
Хорошо, колюсь. Вот есть некий Agg2D — довольно примитивный класс, оформленный в стиле класса Graphics. Пользоваться им просто. http://antigrain.com/stuff/Agg2D.zip
Чтобы скомпилировать, надо скачать http://antigrain.com/agg23.zip и положить файлы Agg2D* в что-то типа agg23/research/win32/Agg2D/*.* — просто чтобы не перенестраивать пути в проекте.
Есть даже мысль — завести этот проект на РСДН и хозяева эту мысль одобряют. Но честно сказать, я просто боюсь потонуть в рутине. Нужны собутыльники
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
Здравствуйте, c-smile, Вы писали:
CS>Честно говоря старая добрая Xara с точки зрения usability CS>мне нравится в разы больше. У Xara более "спартанский" UI CS>что (лично мне) позволяет лучше сфокусироваться именно CS>на предмете рисования.
CS>ИМХО конечно.
Xara мне тоже нравится. Но Creative Docs имеет то преимущество, что у него фиксированный layout и нет этих плавающих окон, которые везде мешаются. Но при этом тема клавиатуры совершенно не раскрыта.
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
Здравствуйте, ArtemGorikov, Вы писали:
AG>Здравствуйте, c-smile, Вы писали:
CS>>Лирические отступления:
CS>>1) Это Open Source. Предполагается что если что-то не нравится то молоток в руки и на благо сообщества... CS>>2) Критикуя — предлагай. Это золотой принцип дискуссии. Его нужно в RSDN прибить на самом видном месте кстати. AG>Почитайте сначала ветку выше, там я предлагал Максиму свои мысли по поводу интерфейса.
Из черного юмора Губермана:
Надпись на могильной плите: "Лежал бы ты, смотрел бы я"
В том смысле что а) подними проект такого уровня.
b) выложи его бесплатно в Open Source
c) а потом сядь и слушай фразы "что мне не нравится в твоем проекте" или "слышь, тебе надо сделать так и так и тогда я так и быть начну твою либу использовать она ж ведь бесплатная, да?".
Еще раз повторю: критикуя — предлагай.
В данном контексте предложение заключается в следующем:
идешь на news://gmane.comp.graphics.agg
и говоришь : "люди добрые вот мое предложение как сделать вот это и вот это, файлы лежат там-то и там-то". Можно еще сначала спросить а есть ли готовое у кого на эту тему.
добрые люди есть — могут поделиться заготовками.
CS>>По делу:
CS>>"как я могу clip rgn, выделенный в HDC, передать в AGG"
CS>>А зачем? Не проще ли то что у тебя есть на экране подсунуть как уже готовый растр AGG (background)
AG>Это нужно затем, чтобы ограничить область отрисовки windowless контролу. Не по делу замечу, что в Harmonia при уменьшении размеров окна закладки табов налазят на дерево слева, т.е. клипа по региону котрола, чтобы он рисовал только там, где положено, нет.
Опять же, если ты посмотришь в код то ты увидишь что есть там отсечение.
В данном конкретном контейнере по всей видимости бага наличесвует.
(Если бы ты подумал немного то понял что например скроллинг с дочерними конторолами без отсечения не сделать)
CS>>и рисовать поверх AGG функциями. Потом скопировать bitmap обратно. Это кстати в общем случае быстрее будет CS>>чем BitBlt на COMPLEXRGN. AG>В теории может и так. А на практике копирование в/из DIB-секции через BitBlt с нулевым регионом отсечения жутко тормозит. Если копировать между экраном и DDB, созданным через CreateCompatibleBitmap, то это вообще стоит 0. Вот я теперь думаю, а не из-за того ли тормоза в GDI+, что он внутри использует DIB-секцию?
В предлагаемой схеме нет вообще никаких регионов.
И что такое "BitBlt с нулевым регионом отсечения"?
CS>>Если вариант выше не проходит то используем либо ::BitBlt либо ::AlphaBlend на выбор. AG>Это высказывание я вообще не понял.
Рисуешь AGG на DDB и делаешь BitBlt. BitBlt саи разберется с rgn.
Использование AlphaBlend — экзотика но может иногда сработать.
Русуешь AGG на 32bpp DIB. Заливешь регион отсечения transparent color на этом
DIB и делаешь ::AlphaBlend. Выглядит сие действо не очень но иногда the only option.
Успехов в пути.
ПыСы: Свистни как напишешь чего, а лучше прям сюда выкладывай — обсудим
I am glad to announce, finally, the availability of the first public
version of Creative Docs .NET, a vector-based graphic design tool
written in C# and based entierly on AGG for all painting operations.
You can check it out and download the first beta version from:
CS>В том смысле что а) подними проект такого уровня. CS>b) выложи его бесплатно в Open Source CS>c) а потом сядь и слушай фразы "что мне не нравится в твоем проекте" или "слышь, тебе надо сделать так и так и тогда я так и быть начну твою либу использовать она ж ведь бесплатная, да?".
Андрей, не бухти, все нормально
Иногда подобный критицизм наводит на некоторые конструктивные мысли.
CS>Еще раз повторю: критикуя — предлагай. CS>В данном контексте предложение заключается в следующем: CS>идешь на CS>news://gmane.comp.graphics.agg CS>и говоришь : "люди добрые вот мое предложение как сделать вот это и вот это, файлы лежат там-то и там-то". Можно еще сначала спросить а есть ли готовое у кого на эту тему. CS>добрые люди есть — могут поделиться заготовками.
На самом деле, есть. Вот, один чувачок из Македонии сделал: http://www.point.com.mk/aggplus/
Называет сябя ником Marlon.
Он даже соптимизировал кой-чего для MMX, так что его творение кроет GDI+ по скорости как... ну вы поняли.
Но если что-то не так — все вопросы к нему. Это не я...
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
Здравствуйте, Denis_TST, Вы писали:
D_T>>> Круто! а как сделана печать? тоже через Antigrain? MS>>Да. Но методом грубой силы — рендерится огромный битмап и гонится через всю сеть на принтер. Трафик жуткий. D_T> Это единственное обстоятельство которое удерживает меня от перехода на ag . Приходиться сидеть на тормозном gdi+ и D_T>с завистью разглядывать скиншоты таких прог как эта
Вообще, это интересный вопрос. Я не знаю, как GDI+ печатает. Если, например, нарисовать на принтер что-нибудь с градиентом, да еще и полупрозрачное, как это напечатать? Теоретически, PostScript имеет и градиенты и альфа-канал, но на практике поддерживают ли все это принтеры? Если да, то можно все печатать в компактном векторном виде. Но что если там растровая картинка? Да еще с градиентом прозрачности? Есть у меня некоторое подозрение, что GDI+ тоже все рендерит в памяти и гонит на принтер битмап.
D_T>Интересно а как сделана перерисовка экрана при изменеии объктов — только часть картинки или все целиком?
Сдается мне (по некоторым вторичным половым признакам), что все перерисовывается с нуля. Но не уверен. По крайней мере, разные слои вполне можно альфа-блендить.
D_T>И еще : в каталоге с прграмой нашел AntiGrain.NET.dll — это ,я так понимаю, враппер для дотнета. D_T>Его можно где нибудь скачать и использовать в своих проектах?
Это нало у Пьера спрашивать. Они там вообще много чего понаделали, фактически — целый GUI framework. Спрошу, в общем.
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
CS>Артем, я так понимаю ты не смотрел внутрь Гармони. CS>Там есть абстракция themes.
Я бы с интересом посмотрел на ее исходники А чем ваша абстракция принципиально отличается от использованной в MS uxtheme.dll?
CS>То что ты видишь в demo это тема слепленная на скорую руку чтобы показать CS>единственное — можно делать свой стиль как систему объектов CS>Theme/Style.
Как я уже говорил, демка мне не понравилась именно коричневым цветом. Если бы вы отнеслись к демке более основательно, т.е., к примеру, наняли хорошего веб-дизайнера (не путать с верстальщиком!), то и впечатление было бы совсем другое. Плюс еще, не всем вообще надо разрабатывать свою тему, большинство скорее возьмет готовую (IMHO).
CS>Что я сделал в Гармони принципиального — отработка в принципе новой для такого CS>типа frameworks архитектуры распространения событий — event propagation.
Что такое event propagation? Я знаю event bubbling — эта схема используется в DHTML и после некоторого количества гемора работает в приложениях с интерфейсом на WebBrowser-контроле. Ее же использовал и Bjarke в своем DirectUI.
MS>Что характерно, пямять уходит не на храниение всяких там битмапов, а на просто структуры данных, типа XML DOM. То что потребляет AGG — это вообще не отсвечивает. It's dot-net, baby. It's dot-net...
XML DOM живет в MSXML.dll, не имеющем никакого отношения к .NET. Его часто используют MFC-шники, хотя есть SAX и куча велосипедов, не зависящих от MSXML.dll.
MS>Я, кстати думаю, как получше прикрутить это дело. Если получится, то не только текст, но и вообще всю графику можно сделать ClearType. Это должен быть breakthrough.
Максим, меня в AGG не устраивают 3 вещи:
1. Он не принимает на вход аналог gdi hatch brush
2. Что-то там накрутили с clipping regions. Т.е. как я могу clip rgn, выделенный в HDC, передать в AGG, чтобы он не рисовал по запрещенным участкам? Опять же, лицензия на использование clipping — либы.
3. Clip работает крайне медленно, если координаты большие. Пример — рисуем линию с x=от -10000 до 10000, clip rect (0,0,5,5). В этом случае на AGG тормоза начинаются просто нереальные, хотя на GDI и GDI+ это вообще никак не влияет, они рисуют эти 5 пикселов без лишних раздумий.
Если бы не эти недостатки, я с удовольствием бы заменил GDI+ на AGG — надоело уже, как GDI+ мылит и коряво рисует линии.
Здравствуйте, ArtemGorikov, Вы писали:
AG>Здравствуйте, c-smile, Вы писали:
CS>>Артем, я так понимаю ты не смотрел внутрь Гармони. CS>>Там есть абстракция themes. AG>Я бы с интересом посмотрел на ее исходники А чем ваша абстракция принципиально отличается от использованной в MS uxtheme.dll?
А то получается как в том анекдоте — "Рембранта не читал но мнение свое имею"
CS>>То что ты видишь в demo это тема слепленная на скорую руку чтобы показать CS>>единственное — можно делать свой стиль как систему объектов CS>>Theme/Style. AG>Как я уже говорил, демка мне не понравилась именно коричневым цветом. Если бы вы отнеслись к демке более основательно, т.е., к примеру, наняли хорошего веб-дизайнера (не путать с верстальщиком!), то и впечатление было бы совсем другое. Плюс еще, не всем вообще надо разрабатывать свою тему, большинство скорее возьмет готовую (IMHO).
Эта коричневая тема имеет имя Pathfinder.
D это продукт DigitalMars — там традиционно все библиотеки вертятся
вокруг оного. Phobos, Deimos, Ares и т.д.
Для спарвки у меня два образования — одно из них художественное (класс живопись).
CS>>Что я сделал в Гармони принципиального — отработка в принципе новой для такого CS>>типа frameworks архитектуры распространения событий — event propagation. AG>Что такое event propagation? Я знаю event bubbling — эта схема используется в DHTML и после некоторого количества гемора работает в приложениях с интерфейсом на WebBrowser-контроле. Ее же использовал и Bjarke в своем DirectUI.
Угу. Я опубликовал Harmonia на WTL newsgroup . Он и воспылал
после того со своим UI (очень личное имхо — ничего хорошего в этот раз у него не получилось)
Здравствуйте, ArtemGorikov, Вы писали:
AG>Максим, меня в AGG не устраивают 3 вещи: AG>1. Он не принимает на вход аналог gdi hatch brush AG>2. Что-то там накрутили с clipping regions. Т.е. как я могу clip rgn, выделенный в HDC, передать в AGG, чтобы он не рисовал по запрещенным участкам? Опять же, лицензия на использование clipping — либы. AG>3. Clip работает крайне медленно, если координаты большие. Пример — рисуем линию с x=от -10000 до 10000, clip rect (0,0,5,5). В этом случае на AGG тормоза начинаются просто нереальные, хотя на GDI и GDI+ это вообще никак не влияет, они рисуют эти 5 пикселов без лишних раздумий. AG>Если бы не эти недостатки, я с удовольствием бы заменил GDI+ на AGG — надоело уже, как GDI+ мылит и коряво рисует линии.
Лирические отступления:
1) Это Open Source. Предполагается что если что-то не нравится то молоток в руки и на благо сообщества...
2) Критикуя — предлагай. Это золотой принцип дискуссии. Его нужно в RSDN прибить на самом видном месте кстати.
По делу:
"как я могу clip rgn, выделенный в HDC, передать в AGG"
А зачем? Не проще ли то что у тебя есть на экране подсунуть как уже готовый растр AGG (background)
и рисовать поверх AGG функциями. Потом скопировать bitmap обратно. Это кстати в общем случае быстрее будет
чем BitBlt на COMPLEXRGN.
Если вариант выше не проходит то используем либо ::BitBlt либо ::AlphaBlend на выбор.
Здравствуйте, ArtemGorikov, Вы писали:
AG>XML DOM живет в MSXML.dll, не имеющем никакого отношения к .NET. Его часто используют MFC-шники, хотя есть SAX и куча велосипедов, не зависящих от MSXML.dll.
В .NET Framework собственная реализация XML DOM и XML парсера, не имеющая никакого отношения к MSXML.dll
AG>Максим, меня в AGG не устраивают 3 вещи:
Да у тебя "талант" — постоянно путаешь божий дар с яичницей.
CS>svn://harmonia.dyndns.org
К сожалению, у меня в терминале не установлен subversion. А можно закачать просто в виде zip-архива?
CS>А то получается как в том анекдоте — "Рембранта не читал но мнение свое имею"
Рембрант был художником, соответственно картины его не читают, а смотрят.
CS>Эта коричневая тема имеет имя Pathfinder. CS>D это продукт DigitalMars — там традиционно все библиотеки вертятся CS>вокруг оного. Phobos, Deimos, Ares и т.д.
Ну не нравится мне коричневый цвет. В Windows традиционно используется серый/серебристый/синий.
CS>Для спарвки у меня два образования — одно из них художественное (класс живопись). Какое это имеет отношение к делу? Вы же зарабатываете на жизнь, работая программистом, а не дизайнером
CS>>>Что я сделал в Гармони принципиального — отработка в принципе новой для такого CS>>>типа frameworks архитектуры распространения событий — event propagation. AG>>Что такое event propagation? Я знаю event bubbling — эта схема используется в DHTML и после некоторого количества гемора работает в приложениях с интерфейсом на WebBrowser-контроле. Ее же использовал и Bjarke в своем DirectUI.
CS>http://www.terrainformatica.com/wiki/pmwiki.php?pagename=Harmonia.Harmonia CS>четвертый параграф сверху.
"Принципиально новая архитектура" это и есть event bubbling, она используется веб-программистами еще с появления DHTML (IE 4.0).
CS>"и после некоторого количества гемора" — ???
После "много траха" с WebBrowser. Знаете, удобнее инициализировать контролы в OnInitDialog, а не в OnDocumentComplete, который приходит намного позже, а в промежутке между этими двумя событиями юзер может любоваться неинициализированными и даже неактивными (в случае, если на странице хостятся ActiveX-ы) — контролами. А еще юзер может в настройках броузера выключить скрипты или от контрола потребует сертификат.
CS>"использовал и Bjarke в своем DirectUI."
CS>Угу. Я опубликовал Harmonia на WTL newsgroup . Он и воспылал CS>после того со своим UI (очень личное имхо — ничего хорошего в этот раз у него не получилось)
В данном случае, схему событий Вы тоже не сами придумали, а позаимствовали у DHTML. Он на сайте честно написал, что идеи брал у DHTML, Java и других windowless библиотек и ссылку привел на блог майкросовтовца. Там написано, что первая windowless либа использовалась в Access, потом перешла на все продукты из пакета Office, а уже потом такую же написала команда Internet Explorer.
Здравствуйте, c-smile, Вы писали:
CS>Лирические отступления:
CS>1) Это Open Source. Предполагается что если что-то не нравится то молоток в руки и на благо сообщества... CS>2) Критикуя — предлагай. Это золотой принцип дискуссии. Его нужно в RSDN прибить на самом видном месте кстати.
Почитайте сначала ветку выше, там я предлагал Максиму свои мысли по поводу интерфейса.
CS>По делу:
CS>"как я могу clip rgn, выделенный в HDC, передать в AGG"
CS>А зачем? Не проще ли то что у тебя есть на экране подсунуть как уже готовый растр AGG (background)
Это нужно затем, чтобы ограничить область отрисовки windowless контролу. Не по делу замечу, что в Harmonia при уменьшении размеров окна закладки табов налазят на дерево слева, т.е. клипа по региону котрола, чтобы он рисовал только там, где положено, нет.
CS>и рисовать поверх AGG функциями. Потом скопировать bitmap обратно. Это кстати в общем случае быстрее будет CS>чем BitBlt на COMPLEXRGN.
В теории может и так. А на практике копирование в/из DIB-секции через BitBlt с нулевым регионом отсечения жутко тормозит. Если копировать между экраном и DDB, созданным через CreateCompatibleBitmap, то это вообще стоит 0. Вот я теперь думаю, а не из-за того ли тормоза в GDI+, что он внутри использует DIB-секцию?
CS>Если вариант выше не проходит то используем либо ::BitBlt либо ::AlphaBlend на выбор.
Это высказывание я вообще не понял.
Здравствуйте, uw, Вы писали:
uw>Здравствуйте, ArtemGorikov, Вы писали:
AG>>XML DOM живет в MSXML.dll, не имеющем никакого отношения к .NET. Его часто используют MFC-шники, хотя есть SAX и куча велосипедов, не зависящих от MSXML.dll.
uw>В .NET Framework собственная реализация XML DOM и XML парсера, не имеющая никакого отношения к MSXML.dll
Я просто заступился на .NET Не в тему: может, и спецификация XML в .NET тоже собственная
AG>>Максим, меня в AGG не устраивают 3 вещи: uw>Да у тебя "талант" — постоянно путаешь божий дар с яичницей.
А что, если не секрет, из .NET и AGG Вы считаете божьим даром и что — яичницей
Здравствуйте, Аноним, Вы писали:
А>Здравствуйте, c-smile, Вы писали:
CS>>svn://harmonia.dyndns.org А>К сожалению, у меня в терминале не установлен subversion. А можно закачать просто в виде zip-архива?
Посмотри ниже, добрая душа выкладывала.
CS>>А то получается как в том анекдоте — "Рембранта не читал но мнение свое имею" А>Рембрант был художником, соответственно картины его не читают, а смотрят.
Да ну!?? Эх, вона как...
Ошибся я. Писателя Рерихом звали...
Судя по описанию на сайте, GUI у софтины крутой. Может быть, я бы тоже подумаю об использовании AGG для рендера GUI, но пока что программа стартует очень медленно, жрет процессорного времени 0..40%, памяти 115 + 140, потом выкидывет исключение и валится . Система Win2003, запущена студия 2003.
Здравствуйте, McSeem2, Вы писали:
MS>Pierre Wrote: MS>[q] MS>I am glad to announce, finally, the availability of the first public MS>version of Creative Docs .NET, a vector-based graphic design tool MS>written in C# and based entierly on AGG for all painting operations.
Я предлагал Пьеру написать это все на D/Harmonia.
Работало бы в разы быстрее.
Он сказал что мое предложение поступило поздно.
Макс там явные проблемы с системными фонтами. Читать на LCD меню
и стандартные (которые нестандартные вообще-то) элементы
контроля невозможно — антиалиасинг вместо cleartype на LCD — плохо.
Здравствуйте, c-smile, Вы писали:
CS>Макс там явные проблемы с системными фонтами. Читать на LCD меню CS>и стандартные (которые нестандартные вообще-то) элементы CS>контроля невозможно — антиалиасинг вместо cleartype на LCD — плохо.
Честно сказать, я тоже не очень-то понимаю подобного фанатизма. Ну, самому рендерить текст это куда ни шло. Но зачем самому парсить TTF файлы?! Весь текст у него — принципиально без хинтов. Он даже сделал свой растровый глиф-кэш для быстрого рисования с субпиксельным позиционированием. Каждая буква храниться в 4 вариантах, со смещением в 1/4 пиксела по горизонтали, за счет чего получается правильное позиционирование. Я не спорю, это важно для верстки. Но рисовать меню таким способом — это уже перебор.
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
Здравствуйте, ArtemGorikov, Вы писали:
AG>Судя по описанию на сайте, GUI у софтины крутой. Может быть, я бы тоже подумаю об использовании AGG для рендера GUI, но пока что программа стартует очень медленно, жрет процессорного времени 0..40%, памяти 115 + 140, потом выкидывет исключение и валится . Система Win2003, запущена студия 2003.
Да, памяти жрет как в том дурацком анегдоте — "не знаю, кто там, но сыр любииит!..."
Но у меня на XP пока не падало.
А стартует долго из за того, что они все иконки парсят и рендерят из собственого векторного формата при старте. Причем, основное время — это именно распарсить и разложить по контейнерам. В предыдущей версии их вообще можно было редактировать тем же редактором. Сейчас их запихали куда-то внутрь.
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
MS>Да, памяти жрет как в том дурацком анегдоте — "не знаю, кто там, но сыр любииит!..." MS>Но у меня на XP пока не падало. MS>А стартует долго из за того, что они все иконки парсят и рендерят из собственого векторного формата при старте. Причем, основное время — это именно распарсить и разложить по контейнерам. В предыдущей версии их вообще можно было редактировать тем же редактором. Сейчас их запихали куда-то внутрь.
Запустили на Win2k — пошла. Крутая софтина . Особенно впечатлен двиглом GUI, который весь windowless и поддерживает дофига тем. Почему у меня на машине не пошла- не знаю, у меня еще второй фреймворк стоит, снести его не могу, даже чтобы поставить следующую его бету
В общем, я ожидал от GUI на C# больших тормозов, а оказалось, что все в пределах допустимого, если учесть, что сама отрисовка AGG с антиалиасингом не быстрая. У Авалона появился серьезный конкурент.
CS>Я предлагал Пьеру написать это все на D/Harmonia. CS>Работало бы в разы быстрее. CS>Он сказал что мое предложение поступило поздно.
Мне GUI в Creative Docs понравился больше, чем в Harmonia. Скорость сопоставима со скоростью Corel Draw!. Только с памятью надо что-то делать, а то жрет больше студии
CS>Макс там явные проблемы с системными фонтами. Читать на LCD меню CS>и стандартные (которые нестандартные вообще-то) элементы CS>контроля невозможно — антиалиасинг вместо cleartype на LCD — плохо.
Да, тут перестарались.
Здравствуйте, ArtemGorikov, Вы писали:
AG>Здравствуйте, c-smile, Вы писали:
CS>>Я предлагал Пьеру написать это все на D/Harmonia. CS>>Работало бы в разы быстрее. CS>>Он сказал что мое предложение поступило поздно.
AG>Мне GUI в Creative Docs понравился больше, чем в Harmonia. Скорость сопоставима со скоростью Corel Draw!. Только с памятью надо что-то делать, а то жрет больше студии
Артем, я так понимаю ты не смотрел внутрь Гармони.
Там есть абстракция themes. То что ты видишь в
demo это тема слепленная на скорую руку чтобы показать
единственное — можно делать свой стиль как систему объектов
Theme/Style.
Что я сделал в Гармони принципиального — отработка в принципе новой для такого
типа frameworks архитектуры распространения событий — event propagation.
Здравствуйте, McSeem2, Вы писали:
MS>Pierre Wrote: MS>
MS>I am glad to announce, finally, the availability of the first public
MS>version of Creative Docs .NET, a vector-based graphic design tool
MS>written in C# and based entierly on AGG for all painting operations.
MS>You can check it out and download the first beta version from:
Честно говоря старая добрая Xara с точки зрения usability
мне нравится в разы больше. У Xara более "спартанский" UI
что (лично мне) позволяет лучше сфокусироваться именно
на предмете рисования.
Здравствуйте, McSeem2, Вы писали:
MS>Pierre Wrote: MS>
MS>I am glad to announce, finally, the availability of the first public
MS>version of Creative Docs .NET, a vector-based graphic design tool
MS>written in C# and based entierly on AGG for all painting operations.
MS>You can check it out and download the first beta version from:
Здравствуйте, ArtemGorikov, Вы писали:
AG>Мне GUI в Creative Docs понравился больше, чем в Harmonia. Скорость сопоставима со скоростью Corel Draw!. Только с памятью надо что-то делать, а то жрет больше студии
Что характерно, пямять уходит не на храниение всяких там битмапов, а на просто структуры данных, типа XML DOM. То что потребляет AGG — это вообще не отсвечивает. It's dot-net, baby. It's dot-net...
CS>>Макс там явные проблемы с системными фонтами. Читать на LCD меню CS>>и стандартные (которые нестандартные вообще-то) элементы CS>>контроля невозможно — антиалиасинг вместо cleartype на LCD — плохо. AG>Да, тут перестарались.
Это момент принципиальный. Они уперлись рогом в землю и даже шрифты парсят сами, без хинтов. Если бы пользовались стандартной GetGlyphOutline, было бы хоть и не ClearTyp-но, но все же гораздо лучше. И пока в AGG не будет ClearType rendering, так и будет криво.
Я, кстати думаю, как получше прикрутить это дело. Если получится, то не только текст, но и вообще всю графику можно сделать ClearType. Это должен быть breakthrough.
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
Здравствуйте, McSeem2, Вы писали:
MS>Здравствуйте, Denis_TST, Вы писали:
D_T>> Круто! а как сделана печать? тоже через Antigrain? MS>Да. Но методом грубой силы — рендерится огромный битмап и гонится через всю сеть на принтер. Трафик жуткий. Это единственное обстоятельство которое удерживает меня от перехода на ag . Приходиться сидеть на тормозном gdi+ и
с завистью разглядывать скиншоты таких прог как эта
---
Интересно а как сделана перерисовка экрана при изменеии объктов — только часть картинки или все целиком?
И еще : в каталоге с прграмой нашел AntiGrain.NET.dll — это ,я так понимаю, враппер для дотнета.
Его можно где нибудь скачать и использовать в своих проектах?
Здравствуйте, McSeem2, Вы писали:
MS>Здравствуйте, Denis_TST, Вы писали:
MS>Вообще, это интересный вопрос. Я не знаю, как GDI+ печатает. Если, например, нарисовать на принтер что-нибудь с градиентом, да еще и полупрозрачное, как это напечатать? Теоретически, PostScript имеет и градиенты и альфа-канал, но на практике поддерживают ли все это принтеры? Если да, то можно все печатать в компактном векторном виде. Но что если там растровая картинка? Да еще с градиентом прозрачности? Есть у меня некоторое подозрение, что GDI+ тоже все рендерит в памяти и гонит на принтер битмап.
Кажется у Фень Юаня был описан механизм печати в winows. Там каждое задание на принтер это фактически метафайл. При печати
этот метафайл растеризуется но не весь а "плосами" в ширину страницы и посылается на печать. Вроде так...
А у gdi+ есть свой формат метафайлов который поддерживает эти все его градиенты и сглаживание. Возможно там тот же принцип...
D_T>>Интересно а как сделана перерисовка экрана при изменеии объктов — только часть картинки или все целиком? MS>Сдается мне (по некоторым вторичным половым признакам), что все перерисовывается с нуля. Но не уверен. По крайней мере, разные слои вполне можно альфа-блендить.
уже сам нашел — переисовыватся часть экрана
Там в меню Debug есть пункт Salir — он заливает экран одним цветом , и если таскать объекты по экрану
видно что переисовывается ограничивающий прямоугольник
AG>>Максим, меня в AGG не устраивают 3 вещи: AG>>1. Он не принимает на вход аналог gdi hatch brush
MS>Да, закраска сплошным цветом принципиально отличается от какой-либо еще. MS>Для hatch brush надо использовать span_pattern_rgba — простой паттерн без трансфопмаций или span_pattern_filter_rgba span_pattern_resample_rgba — аналог текстурирования с произвольными трансформациями. Примеры — pattern_fill.cpp, pattern_perspective.cpp, pattern_resample.cpp
Да, что-то было, просто хотелось бы иметь уже реализованным, чтобы принимало на вход LOGBRUSH.
AG>>2. Что-то там накрутили с clipping regions. Т.е. как я могу clip rgn, выделенный в HDC, передать в AGG, чтобы он не рисовал по запрещенным участкам? Опять же, лицензия на использование clipping — либы.
MS>GPC надо использовать, если есть насущная необходимость получать данные в векторном представлении. Для чисто визуального отсечения по регионам есть scanline boolean algebra и есть alpha-mask. Примеры — alpha_mask*.cpp и scanline_boolean*.cpp. Визуальный эффект — тот же, работает в разы быстрее и нет ограничений на использование. GPC — удовольствие дорогое, scanline boolean — дешево и сердито.
Вы не ответили на вопрос: как полученный у HDC регион (HRGN) скормить растеризатору? Если бы это был только clipbox, тогда было бы все просто. И даже после того, как написал транслятор из HRGN в формат либы клиппера, как быть с ее лицензией?
AG>>3. Clip работает крайне медленно, если координаты большие. Пример — рисуем линию с x=от -10000 до 10000, clip rect (0,0,5,5). В этом случае на AGG тормоза начинаются просто нереальные, хотя на GDI и GDI+ это вообще никак не влияет, они рисуют эти 5 пикселов без лишних раздумий.
MS>Более того — он и памяти при этом мощно отъест (ну, не так мощно как дот-нет, но все же). MS>Это неизбежно при loosely coupled дизайне. Растеризатор понятия не имеет, что тем есть какие-то окна, в которые надо чего-то рисовать с отсечением. Его задача — выдать набор сканлайнов, которые будут потом использоваться не обязательно для рисования. Соответственно, надо явным образом "объяснить" растеризатору, чтобы он отсекал в векторном виде: ras.clip_box(x1, y1, x2, y2); MS>Но и это еще не все. Если значения координат не вписываются в 24 бита, возникнут глюки из за переполнения. Для устранения этого можно последним элементом конвейера поставить conv_clip_polygon — он работает чуть медленнее, чем встроенный клиппер, но зато обеспечивает честное отсечение при любых масштабах — хоть космических.
ras.clip_box(x1, y1, x2, y2) — это я и вызывал, иначе имеем падение с Access Violation. В том случае мне еще не надо было отсекать регионы.
Т.е. можно включить отсечение регионов и не получить гемора с лицензией? conv_clip_polygon — и решать проблему с лицензией?
MS>И вообще, дизайн таков, что использовать библиотеку непосредственно — это плохая идея. Надо сначала завернуть требуемую функциональность во что-то типа GDI+ного Graphics или Java2D. И использовать уже ее. Почему это не сделать сразу? Да просто потому, что если завернуть всю функциональность, то получится неуклюжий монстр. Надо действовать как-то более избирательно.
Почему бы не иметь неуклюжего монстра размером в 1-1.5 метра, если GDI+ весит столько? В наше время это не размер, и хорошо бы иметь сборки в виде либы и dll, с макросами, определяющими используемые возможности.
А сейчас получается, что с GDI+ на порядок меньше траха, он принимает GDI объекты и его константы на входе, не озадачивается особенно форматом устройства вывода и "космическими координатами". Только вот качество его антиалиасинга не супер
Здравствуйте, McSeem2, Вы писали:
S>Хорошо, колюсь. Вот есть некий Agg2D — довольно примитивный класс, оформленный в стиле класса Graphics. Пользоваться им просто. http://antigrain.com/stuff/Agg2D.zip MS>Чтобы скомпилировать, надо скачать http://antigrain.com/agg23.zip и положить файлы Agg2D* в что-то типа agg23/research/win32/Agg2D/*.* — просто чтобы не перенестраивать пути в проекте.
MS>Есть даже мысль — завести этот проект на РСДН и хозяева эту мысль одобряют. Но честно сказать, я просто боюсь потонуть в рутине. Нужны собутыльники
Уверен что продвижение этого проекта очень бы помогло бы продвижению твоей библиотеки.
Просто вспоминаю себя когда первый раз скачал AGG и пытался нарисовать линию это было не просто!
В ближайший месяц или два должен буду решить некоторые проблемы, а потом может быть запишусь в "собутыльники".
MS>Не ответил. Беда в том, что я понятия не имею, что такое HRGN, как из него вытащить данные и как они вообще представлены. В виде скан-лайнов или в виде полигона? Если первое (есть подозрение, что это так), то можно написать простой класс, который ведет себя как растеризатор (rewind_scanlines/sweep_scanline) и использовать его вместо растеризатора для дальнейших операций. Если это полигон — его надо предварительно растеризовать при помощи того же rasterizer_scanline_aa и потом уже использовать в scanline_boolean.
Т.е. можно поместить в HDC монохромный растр DIB-секции (предварительно забитый нулями), сделать ему BitBlt(....., WHITENESS), и воспользоваться scanline_boolean, применив его как трафаретку? Это интересная мысль, а как насчет дополнительных временных затрат на его создание и затрат памяти? Хотя монохромный растр, по идее, достаточно компактен.
AG>>Почему бы не иметь неуклюжего монстра размером в 1-1.5 метра, если GDI+ весит столько? В наше время это не размер, и хорошо бы иметь сборки в виде либы и dll, с макросами, определяющими используемые возможности. AG>>А сейчас получается, что с GDI+ на порядок меньше траха, он принимает GDI объекты и его константы на входе, не озадачивается особенно форматом устройства вывода и "космическими координатами". Только вот качество его антиалиасинга не супер
MS>Вполне согласен. С точки зрения программиста, которому надо "нарисовать-линию-и-фсе", AGG — это далеко не лучший выбор. Я этого и не скрываю. Теоретически, конечно же, если бы был такой класс типа Graphics — это было бы гораздо более usable. Но здесь уже вступает в силу некая диалектика. Беда в том, как всю эту квачу поддерживать. GDI+ поддерживает толпа голодных индусов. Им бы только на хлеб заработать, а на чем — это совершенно не существенно. Для меня же это существенно. Просто потому, что я не "толпа голодных индусов" и весь этот объем рутинной работы я просто-напросто не потяну в одиночку. При таком подходе очень велик риск попасть в сказку-неотвязку (never ending story) — то есть, когда все силы будут уходить только на поддержку. Я же хочу работать и над новыми алгоритмами, типа ClearType-like rendering. Поэтому и такое отношение. Вполне допускаю, что это не лучшее отношение.
Ну, скажем так, мне надо нарисовать не только линию . В одном проекте, в котором я использовал AGG, было очень много copy-paste разных include, определений структур — а зачем все это? Удобно, когда есть набор шаблонных оберток, а include — одна — максимум 2 штуки.
MS>Хорошо, колюсь. Вот есть некий Agg2D — довольно примитивный класс, оформленный в стиле класса Graphics. Пользоваться им просто. http://antigrain.com/stuff/Agg2D.zip MS>Чтобы скомпилировать, надо скачать http://antigrain.com/agg23.zip и положить файлы Agg2D* в что-то типа agg23/research/win32/Agg2D/*.* — просто чтобы не перенестраивать пути в проекте.
MS>Есть даже мысль — завести этот проект на РСДН и хозяева эту мысль одобряют. Но честно сказать, я просто боюсь потонуть в рутине. Нужны собутыльники
Я бы предложил написать шаблонный класс-обертку, замещающий CDC, или лучше интерфейс вида IDC и обертку к нему — аналог CDC, чтобы легко было в проектах перенаправлять вызовы к GDI на AGG прозрачно для юзера. Т.к. печать еще никто не отменял, IMHO нужно поддерживать полную обратную совместимость с HDC на уровне векторов (для записи метафайла).
Здравствуйте, ArtemGorikov, Вы писали:
AG>Т.е. можно поместить в HDC монохромный растр DIB-секции (предварительно забитый нулями), сделать ему BitBlt(....., WHITENESS), и воспользоваться scanline_boolean, применив его как трафаретку? Это интересная мысль, а как насчет дополнительных временных затрат на его создание и затрат памяти? Хотя монохромный растр, по идее, достаточно компактен.
Насколько я понял, можно вызвать GetRegionData(), нарисовать все эти прямоугольники и использовать буфер в качестве Alpha-mask. Правда в AGG есть только 8-битовая маска, а RGN по сути — монохромный. А монохромную маску я так и не сподобился пока сделать. Можно и через scanline_boolean, но для этого придется написать адаптор — простой растеризатор для прямоугольников (кстати, для полигональных регионов — там получается много-много мелких прямоугольников?). Стоп. А нафига это все? Если регионы используются в качестве маски для сложногго отсечения, то разве на BitBlt (или SetDIBitsToDevice) они не действуют? То есть, рисуем как обычно, но результирующий битмап выводим с регионом. И вообще, для чего эти регионы в данном случае нужны — для "круглых окон"?
AG>Ну, скажем так, мне надо нарисовать не только линию . В одном проекте, в котором я использовал AGG, было очень много copy-paste разных include, определений структур — а зачем все это? Удобно, когда есть набор шаблонных оберток, а include — одна — максимум 2 штуки.
Ну как бы вложенные "#include" пока еще никто не отменял. Кто мешает вместо copy-paste использовать один файл?
AG>Я бы предложил написать шаблонный класс-обертку, замещающий CDC, или лучше интерфейс вида IDC и обертку к нему — аналог CDC, чтобы легко было в проектах перенаправлять вызовы к GDI на AGG прозрачно для юзера. Т.к. печать еще никто не отменял, IMHO нужно поддерживать полную обратную совместимость с HDC на уровне векторов (для записи метафайла).
Вот и надо работать над этой интерфейсной частью. Это тоже большая работа. У меня для этого возможностей пока что нет. Есть заготовка, которую можно развивать/переделывать. Я могу консультировать, но непосредственно за сам внешний интерфейс не возьмусь. К тому же, полная "прозрачная совместимость" — это утопия, либо же это сильно кастрирует возможности вообще.
И это опять же только для виндов. А что делать на X11, MacOS, и прочих?
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
MS>Насколько я понял, можно вызвать GetRegionData(), нарисовать все эти прямоугольники и использовать буфер в качестве Alpha-mask. Правда в AGG есть только 8-битовая маска, а RGN по сути — монохромный. А монохромную маску я так и не сподобился пока сделать. Можно и через scanline_boolean, но для этого придется написать адаптор — простой растеризатор для прямоугольников (кстати, для полигональных регионов — там получается много-много мелких прямоугольников?). Стоп. А нафига это все? Если регионы используются в качестве маски для сложногго отсечения, то разве на BitBlt (или SetDIBitsToDevice) они не действуют? То есть, рисуем как обычно, но результирующий битмап выводим с регионом. И вообще, для чего эти регионы в данном случае нужны — для "круглых окон"?
Когда вызывается серия InvalidateRect/InvalidateRgn , получается результирующий регион (результат операции OR) , который и попадает в HDC на WM_PAINT, когда система отрисовывает окно, либо окно само себя принудительно обновляет через UpdateWindow. Результирующий прямоугольник в PAINTSTRUCT — это на самом деле ограничивающий регион прямоугольник. Т.е., чтобы исключить рисование на запрещенных участках, выделить только rect в растеризатор недостаточно.
MS>Вот и надо работать над этой интерфейсной частью. Это тоже большая работа. У меня для этого возможностей пока что нет. Есть заготовка, которую можно развивать/переделывать. Я могу консультировать, но непосредственно за сам внешний интерфейс не возьмусь. К тому же, полная "прозрачная совместимость" — это утопия, либо же это сильно кастрирует возможности вообще. MS>И это опять же только для виндов. А что делать на X11, MacOS, и прочих?
Ну так речь то пока идет про винду, прозрачная совместимость обеспечивается перегрузкой некоторых методов CDC и отрисовкой на AGG, остальное ничего не нужно трогать. Я таким образом (правда, на шаблонах) перенаправил вызовы на GDI+. Сложность использования AGG заключаются в отсечении и hutchbrush. Сделаю пока отсечение на 8-битной маске, а в будущем, если ты напишешь отсечение на монохромной маске, использую его.
CS>Из черного юмора Губермана: CS>Надпись на могильной плите: "Лежал бы ты, смотрел бы я"
При чем тут черный юмор Губермана? Может, я чего не понимаю, но я всего лишь хотел покритиковать AGG за некоторые грабли, с которыми я лично столкнулся. Я же не сказал, что GDI+ — оч хорошая либа, а AGG — нет? Сейчас я занимаюсь как раз заменой GDI+ на AGG в ком. проекте, т.к. недоволен качеством картинки GDI+.
CS>В том смысле что а) подними проект такого уровня. CS>b) выложи его бесплатно в Open Source CS>c) а потом сядь и слушай фразы "что мне не нравится в твоем проекте" или "слышь, тебе надо сделать так и так и тогда я так и быть начну твою либу использовать она ж ведь бесплатная, да?".
Я сказал "хорошо бы было так и так, тогда бы я смог его заюзать". Так что "Почувствуте разницу" (С) из какой-то рекламы.
CS>Еще раз повторю: критикуя — предлагай. CS>В данном контексте предложение заключается в следующем: CS>идешь на CS>news://gmane.comp.graphics.agg CS>и говоришь : "люди добрые вот мое предложение как сделать вот это и вот это, файлы лежат там-то и там-то". Можно еще сначала спросить а есть ли готовое у кого на эту тему. CS>добрые люди есть — могут поделиться заготовками.
У меня есть свои заготовки. Политика компании не позволяет раздавать исходники сторонним людям.
CS>Опять же, если ты посмотришь в код то ты увидишь что есть там отсечение. CS>В данном конкретном контейнере по всей видимости бага наличесвует.
Я горю от нетерпения посмотреть код Harmonia. К сожалению, в терминале не установлен subversion, поэтому я могу закачать только zip/rar архив. Буду очень признателен, если кинете ссылку для закачки.
CS>(Если бы ты подумал немного то понял что например скроллинг с дочерними конторолами без отсечения не сделать)
Иногда я немного думаю. Когда пишу код. Вообще это высказывание можно принять за хамский разговор. Я знаю, что в вашем коде есть отсечение, но также есть указанный баг. Еще иногда падает демка на вызове диаложек по 4 кнопкам на одной из закладок.
CS>В предлагаемой схеме нет вообще никаких регионов. CS>И что такое "BitBlt с нулевым регионом отсечения"?
Я хотел сказать, что в source dc выделен нулевой регион.
CS>Рисуешь AGG на DDB и делаешь BitBlt. BitBlt саи разберется с rgn.
CS>Использование AlphaBlend — экзотика но может иногда сработать. CS>Русуешь AGG на 32bpp DIB. Заливешь регион отсечения transparent color на этом CS>DIB и делаешь ::AlphaBlend. Выглядит сие действо не очень но иногда the only option.
Думаю, есть другие, более оптимальные пути решения задачи.
CS>Успехов в пути.
Спасибо
CS>ПыСы: Свистни как напишешь чего, а лучше прям сюда выкладывай — обсудим
Написал, если смогу — выложу.
Здравствуйте, Denis_TST, Вы писали:
D_T>Кажется у Фень Юаня был описан механизм печати в winows. Там каждое задание на принтер это фактически метафайл. При печати D_T>этот метафайл растеризуется но не весь а "плосами" в ширину страницы и посылается на печать. Вроде так...
"Полосами" растеризуется только для растровых принтеров (струйники). Большинство (если не все) лазерных принтеров получают страницу в виде PostScript.
D_T>А у gdi+ есть свой формат метафайлов который поддерживает эти все его градиенты и сглаживание. Возможно там тот же принцип...
У GDI+ свой, странный формат метафайлов. Странный потому, что его не может прочесть даже стандартный просмотрщик WinXP.
. Особенно впечатлен двиглом GUI, который весь windowless и поддерживает дофига тем. Почему у меня на машине не пошла- не знаю, у меня еще второй фреймворк стоит, снести его не могу, даже чтобы поставить следующую его бету 
— он заливает экран одним цветом , и если таскать объекты по экрану 
