Creative Docs .NET by Pierre Arnaud
От: McSeem2 США http://www.antigrain.com
Дата: 20.09.05 14:10
Оценка: 6 (1)
Pierre Wrote:

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:

http://www.creativedocs.net

It currently runs on Win32 platforms only.

McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
Re: Creative Docs .NET by Pierre Arnaud
От: ArtemGorikov Австралия жж
Дата: 20.09.05 15:02
Оценка:
Здравствуйте, McSeem2, Вы писали:


MS>http://www.creativedocs.net


Судя по описанию на сайте, GUI у софтины крутой. Может быть, я бы тоже подумаю об использовании AGG для рендера GUI, но пока что программа стартует очень медленно, жрет процессорного времени 0..40%, памяти 115 + 140, потом выкидывет исключение и валится . Система Win2003, запущена студия 2003.
Re: Creative Docs .NET by Pierre Arnaud
От: c-smile Канада http://terrainformatica.com
Дата: 20.09.05 15:48
Оценка:
Здравствуйте, 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 — плохо.
Re[2]: Creative Docs .NET by Pierre Arnaud
От: McSeem2 США http://www.antigrain.com
Дата: 20.09.05 16:10
Оценка:
Здравствуйте, c-smile, Вы писали:

CS>Макс там явные проблемы с системными фонтами. Читать на LCD меню

CS>и стандартные (которые нестандартные вообще-то) элементы
CS>контроля невозможно — антиалиасинг вместо cleartype на LCD — плохо.

Честно сказать, я тоже не очень-то понимаю подобного фанатизма. Ну, самому рендерить текст это куда ни шло. Но зачем самому парсить TTF файлы?! Весь текст у него — принципиально без хинтов. Он даже сделал свой растровый глиф-кэш для быстрого рисования с субпиксельным позиционированием. Каждая буква храниться в 4 вариантах, со смещением в 1/4 пиксела по горизонтали, за счет чего получается правильное позиционирование. Я не спорю, это важно для верстки. Но рисовать меню таким способом — это уже перебор.
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
Re[2]: Creative Docs .NET by Pierre Arnaud
От: McSeem2 США http://www.antigrain.com
Дата: 20.09.05 16:21
Оценка:
Здравствуйте, ArtemGorikov, Вы писали:

AG>Судя по описанию на сайте, GUI у софтины крутой. Может быть, я бы тоже подумаю об использовании AGG для рендера GUI, но пока что программа стартует очень медленно, жрет процессорного времени 0..40%, памяти 115 + 140, потом выкидывет исключение и валится . Система Win2003, запущена студия 2003.


Да, памяти жрет как в том дурацком анегдоте — "не знаю, кто там, но сыр любииит!..."
Но у меня на XP пока не падало.
А стартует долго из за того, что они все иконки парсят и рендерят из собственого векторного формата при старте. Причем, основное время — это именно распарсить и разложить по контейнерам. В предыдущей версии их вообще можно было редактировать тем же редактором. Сейчас их запихали куда-то внутрь.
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
Re[3]: Creative Docs .NET by Pierre Arnaud
От: ArtemGorikov Австралия жж
Дата: 20.09.05 16:31
Оценка:
Здравствуйте, McSeem2, Вы писали:


MS>Да, памяти жрет как в том дурацком анегдоте — "не знаю, кто там, но сыр любииит!..."

MS>Но у меня на XP пока не падало.
MS>А стартует долго из за того, что они все иконки парсят и рендерят из собственого векторного формата при старте. Причем, основное время — это именно распарсить и разложить по контейнерам. В предыдущей версии их вообще можно было редактировать тем же редактором. Сейчас их запихали куда-то внутрь.

Запустили на Win2k — пошла. Крутая софтина . Особенно впечатлен двиглом GUI, который весь windowless и поддерживает дофига тем. Почему у меня на машине не пошла- не знаю, у меня еще второй фреймворк стоит, снести его не могу, даже чтобы поставить следующую его бету

В общем, я ожидал от GUI на C# больших тормозов, а оказалось, что все в пределах допустимого, если учесть, что сама отрисовка AGG с антиалиасингом не быстрая. У Авалона появился серьезный конкурент.
Re[2]: Creative Docs .NET by Pierre Arnaud
От: ArtemGorikov Австралия жж
Дата: 20.09.05 16:39
Оценка:
Здравствуйте, c-smile, Вы писали:


CS>Я предлагал Пьеру написать это все на D/Harmonia.

CS>Работало бы в разы быстрее.
CS>Он сказал что мое предложение поступило поздно.

Мне GUI в Creative Docs понравился больше, чем в Harmonia. Скорость сопоставима со скоростью Corel Draw!. Только с памятью надо что-то делать, а то жрет больше студии


CS>Макс там явные проблемы с системными фонтами. Читать на LCD меню

CS>и стандартные (которые нестандартные вообще-то) элементы
CS>контроля невозможно — антиалиасинг вместо cleartype на LCD — плохо.
Да, тут перестарались.
Re[3]: Creative Docs .NET by Pierre Arnaud
От: c-smile Канада http://terrainformatica.com
Дата: 20.09.05 17:39
Оценка:
Здравствуйте, ArtemGorikov, Вы писали:

AG>Здравствуйте, c-smile, Вы писали:



CS>>Я предлагал Пьеру написать это все на D/Harmonia.

CS>>Работало бы в разы быстрее.
CS>>Он сказал что мое предложение поступило поздно.

AG>Мне GUI в Creative Docs понравился больше, чем в Harmonia. Скорость сопоставима со скоростью Corel Draw!. Только с памятью надо что-то делать, а то жрет больше студии


Артем, я так понимаю ты не смотрел внутрь Гармони.
Там есть абстракция themes. То что ты видишь в
demo это тема слепленная на скорую руку чтобы показать
единственное — можно делать свой стиль как систему объектов
Theme/Style.

Что я сделал в Гармони принципиального — отработка в принципе новой для такого
типа frameworks архитектуры распространения событий — event propagation.
Re: Creative Docs .NET by Pierre Arnaud
От: c-smile Канада http://terrainformatica.com
Дата: 20.09.05 17:57
Оценка:
Здравствуйте, 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:

MS>http://www.creativedocs.net

MS>It currently runs on Win32 platforms only.


Честно говоря старая добрая Xara с точки зрения usability
мне нравится в разы больше. У Xara более "спартанский" UI
что (лично мне) позволяет лучше сфокусироваться именно
на предмете рисования.

ИМХО конечно.
Re: Creative Docs .NET by Pierre Arnaud
От: Denis_TST Россия www.transsys.ru
Дата: 20.09.05 18:11
Оценка:
Здравствуйте, 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:

MS>http://www.creativedocs.net

MS>It currently runs on Win32 platforms only.

Круто! а как сделана печать? тоже через Antigrain?
... << RSDN@Home 1.2.0 alpha rev. 599>>
Re[3]: Creative Docs .NET by Pierre Arnaud
От: McSeem2 США http://www.antigrain.com
Дата: 20.09.05 18:16
Оценка:
Здравствуйте, 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
Я жертва цепи несчастных случайностей. Как и все мы.
Re[2]: Creative Docs .NET by Pierre Arnaud
От: McSeem2 США http://www.antigrain.com
Дата: 20.09.05 20:21
Оценка: :))
Здравствуйте, c-smile, Вы писали:

CS>Честно говоря старая добрая Xara с точки зрения usability

CS>мне нравится в разы больше. У Xara более "спартанский" UI
CS>что (лично мне) позволяет лучше сфокусироваться именно
CS>на предмете рисования.

CS>ИМХО конечно.


Xara мне тоже нравится. Но Creative Docs имеет то преимущество, что у него фиксированный layout и нет этих плавающих окон, которые везде мешаются. Но при этом тема клавиатуры совершенно не раскрыта.
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
Re[2]: Creative Docs .NET by Pierre Arnaud
От: McSeem2 США http://www.antigrain.com
Дата: 20.09.05 20:24
Оценка:
Здравствуйте, Denis_TST, Вы писали:

D_T> Круто! а как сделана печать? тоже через Antigrain?


Да. Но методом грубой силы — рендерится огромный битмап и гонится через всю сеть на принтер. Трафик жуткий.
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
Re[3]: Creative Docs .NET by Pierre Arnaud
От: Denis_TST Россия www.transsys.ru
Дата: 20.09.05 21:32
Оценка:
Здравствуйте, McSeem2, Вы писали:

MS>Здравствуйте, Denis_TST, Вы писали:


D_T>> Круто! а как сделана печать? тоже через Antigrain?

MS>Да. Но методом грубой силы — рендерится огромный битмап и гонится через всю сеть на принтер. Трафик жуткий.
Это единственное обстоятельство которое удерживает меня от перехода на ag . Приходиться сидеть на тормозном gdi+ и
с завистью разглядывать скиншоты таких прог как эта
---
Интересно а как сделана перерисовка экрана при изменеии объктов — только часть картинки или все целиком?

И еще : в каталоге с прграмой нашел AntiGrain.NET.dll — это ,я так понимаю, враппер для дотнета.
Его можно где нибудь скачать и использовать в своих проектах?
... << RSDN@Home 1.2.0 alpha rev. 599>>
Re[4]: Creative Docs .NET by Pierre Arnaud
От: McSeem2 США http://www.antigrain.com
Дата: 20.09.05 22:24
Оценка: +1
Здравствуйте, 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
Я жертва цепи несчастных случайностей. Как и все мы.
Re[4]: Creative Docs .NET by Pierre Arnaud
От: ArtemGorikov Австралия жж
Дата: 21.09.05 11:03
Оценка: -1
Здравствуйте, c-smile, Вы писали:


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.
Re[4]: Creative Docs .NET by Pierre Arnaud
От: ArtemGorikov Австралия жж
Дата: 21.09.05 11:21
Оценка: -1
Здравствуйте, McSeem2, Вы писали:


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+ мылит и коряво рисует линии.
Re[5]: Creative Docs .NET by Pierre Arnaud
От: McSeem2 США http://www.antigrain.com
Дата: 21.09.05 14:32
Оценка: 13 (2)
Здравствуйте, ArtemGorikov, Вы писали:

Это уже офтоп, ну да ладно.

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
Я жертва цепи несчастных случайностей. Как и все мы.
Re[5]: Creative Docs .NET by Pierre Arnaud
От: Denis_TST Россия www.transsys.ru
Дата: 21.09.05 16:26
Оценка:
Здравствуйте, McSeem2, Вы писали:

MS>Здравствуйте, Denis_TST, Вы писали:



MS>Вообще, это интересный вопрос. Я не знаю, как GDI+ печатает. Если, например, нарисовать на принтер что-нибудь с градиентом, да еще и полупрозрачное, как это напечатать? Теоретически, PostScript имеет и градиенты и альфа-канал, но на практике поддерживают ли все это принтеры? Если да, то можно все печатать в компактном векторном виде. Но что если там растровая картинка? Да еще с градиентом прозрачности? Есть у меня некоторое подозрение, что GDI+ тоже все рендерит в памяти и гонит на принтер битмап.

Кажется у Фень Юаня был описан механизм печати в winows. Там каждое задание на принтер это фактически метафайл. При печати
этот метафайл растеризуется но не весь а "плосами" в ширину страницы и посылается на печать. Вроде так...
А у gdi+ есть свой формат метафайлов который поддерживает эти все его градиенты и сглаживание. Возможно там тот же принцип...


D_T>>Интересно а как сделана перерисовка экрана при изменеии объктов — только часть картинки или все целиком?

MS>Сдается мне (по некоторым вторичным половым признакам), что все перерисовывается с нуля. Но не уверен. По крайней мере, разные слои вполне можно альфа-блендить.
уже сам нашел — переисовыватся часть экрана
Там в меню Debug есть пункт Salir — он заливает экран одним цветом , и если таскать объекты по экрану
видно что переисовывается ограничивающий прямоугольник
... << RSDN@Home 1.2.0 alpha rev. 599>>
Re[6]: Оффтоп
От: ArtemGorikov Австралия жж
Дата: 21.09.05 17:52
Оценка:
Здравствуйте, McSeem2, Вы писали:


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 объекты и его константы на входе, не озадачивается особенно форматом устройства вывода и "космическими координатами". Только вот качество его антиалиасинга не супер
Re[7]: Оффтоп
От: McSeem2 США http://www.antigrain.com
Дата: 21.09.05 20:10
Оценка: 10 (2)
Здравствуйте, 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
Я жертва цепи несчастных случайностей. Как и все мы.
Re[8]: Оффтоп
От: korzhik Россия  
Дата: 21.09.05 20:26
Оценка:
Здравствуйте, McSeem2, Вы писали:

S>Хорошо, колюсь. Вот есть некий Agg2D — довольно примитивный класс, оформленный в стиле класса Graphics. Пользоваться им просто. http://antigrain.com/stuff/Agg2D.zip

MS>Чтобы скомпилировать, надо скачать http://antigrain.com/agg23.zip и положить файлы Agg2D* в что-то типа agg23/research/win32/Agg2D/*.* — просто чтобы не перенестраивать пути в проекте.

MS>Есть даже мысль — завести этот проект на РСДН и хозяева эту мысль одобряют. Но честно сказать, я просто боюсь потонуть в рутине. Нужны собутыльники


Уверен что продвижение этого проекта очень бы помогло бы продвижению твоей библиотеки.
Просто вспоминаю себя когда первый раз скачал AGG и пытался нарисовать линию это было не просто!

В ближайший месяц или два должен буду решить некоторые проблемы, а потом может быть запишусь в "собутыльники".
Re[8]: Оффтоп
От: ArtemGorikov Австралия жж
Дата: 22.09.05 08:39
Оценка:
Здравствуйте, McSeem2, Вы писали:


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 на уровне векторов (для записи метафайла).
Re[9]: Оффтоп
От: McSeem2 США http://www.antigrain.com
Дата: 22.09.05 15:17
Оценка:
Здравствуйте, 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
Я жертва цепи несчастных случайностей. Как и все мы.
Re[10]: Оффтоп
От: ArtemGorikov Австралия жж
Дата: 22.09.05 17:34
Оценка:
Здравствуйте, McSeem2, Вы писали:


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-битной маске, а в будущем, если ты напишешь отсечение на монохромной маске, использую его.
Re[5]: Creative Docs .NET by Pierre Arnaud
От: c-smile Канада http://terrainformatica.com
Дата: 23.09.05 00:17
Оценка: +1
Здравствуйте, ArtemGorikov, Вы писали:

AG>Здравствуйте, c-smile, Вы писали:



CS>>Артем, я так понимаю ты не смотрел внутрь Гармони.

CS>>Там есть абстракция themes.
AG>Я бы с интересом посмотрел на ее исходники А чем ваша абстракция принципиально отличается от использованной в MS uxtheme.dll?

svn://harmonia.dyndns.org

А то получается как в том анекдоте — "Рембранта не читал но мнение свое имею"


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.

http://www.terrainformatica.com/wiki/pmwiki.php?pagename=Harmonia.Harmonia
четвертый параграф сверху.

"и после некоторого количества гемора" — ???

"использовал и Bjarke в своем DirectUI."

Угу. Я опубликовал Harmonia на WTL newsgroup . Он и воспылал
после того со своим UI (очень личное имхо — ничего хорошего в этот раз у него не получилось)
Re[5]: Creative Docs .NET by Pierre Arnaud
От: c-smile Канада http://terrainformatica.com
Дата: 23.09.05 04:16
Оценка: +1
Здравствуйте, 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 на выбор.
Re[5]: Creative Docs .NET by Pierre Arnaud
От: uw  
Дата: 23.09.05 09:06
Оценка: -1
Здравствуйте, ArtemGorikov, Вы писали:

AG>XML DOM живет в MSXML.dll, не имеющем никакого отношения к .NET. Его часто используют MFC-шники, хотя есть SAX и куча велосипедов, не зависящих от MSXML.dll.


В .NET Framework собственная реализация XML DOM и XML парсера, не имеющая никакого отношения к MSXML.dll

AG>Максим, меня в AGG не устраивают 3 вещи:


Да у тебя "талант" — постоянно путаешь божий дар с яичницей.
Re[6]: Creative Docs .NET by Pierre Arnaud
От: Аноним  
Дата: 23.09.05 09:20
Оценка: -1
Здравствуйте, c-smile, Вы писали:


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.
Re[6]: Creative Docs .NET by Pierre Arnaud
От: ArtemGorikov Австралия жж
Дата: 23.09.05 09:38
Оценка: -1
Здравствуйте, 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 на выбор.

Это высказывание я вообще не понял.
Re[6]: Creative Docs .NET by Pierre Arnaud
От: ArtemGorikov Австралия жж
Дата: 23.09.05 09:50
Оценка: -1
Здравствуйте, 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 Вы считаете божьим даром и что — яичницей
Re[7]: Creative Docs .NET by Pierre Arnaud
От: c-smile Канада http://terrainformatica.com
Дата: 23.09.05 20:14
Оценка: +1 :)
Здравствуйте, 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.

Успехов в пути.

ПыСы: Свистни как напишешь чего, а лучше прям сюда выкладывай — обсудим
Re[7]: Creative Docs .NET by Pierre Arnaud
От: c-smile Канада http://terrainformatica.com
Дата: 23.09.05 20:26
Оценка: :)
Здравствуйте, Аноним, Вы писали:

А>Здравствуйте, c-smile, Вы писали:



CS>>svn://harmonia.dyndns.org

А>К сожалению, у меня в терминале не установлен subversion. А можно закачать просто в виде zip-архива?

Посмотри ниже, добрая душа выкладывала.

CS>>А то получается как в том анекдоте — "Рембранта не читал но мнение свое имею"

А>Рембрант был художником, соответственно картины его не читают, а смотрят.

Да ну!?? Эх, вона как...
Ошибся я. Писателя Рерихом звали...
Re[8]: Creative Docs .NET by Pierre Arnaud
От: McSeem2 США http://www.antigrain.com
Дата: 23.09.05 22:12
Оценка: 3 (1)
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
Я жертва цепи несчастных случайностей. Как и все мы.
Re[8]: Creative Docs .NET by Pierre Arnaud
От: ArtemGorikov Австралия жж
Дата: 24.09.05 10:46
Оценка:
Здравствуйте, c-smile, Вы писали:


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>ПыСы: Свистни как напишешь чего, а лучше прям сюда выкладывай — обсудим

Написал, если смогу — выложу.
Re[6]: Creative Docs .NET by Pierre Arnaud
От: ArtemGorikov Австралия жж
Дата: 26.09.05 07:24
Оценка:
Здравствуйте, Denis_TST, Вы писали:

D_T>Кажется у Фень Юаня был описан механизм печати в winows. Там каждое задание на принтер это фактически метафайл. При печати

D_T>этот метафайл растеризуется но не весь а "плосами" в ширину страницы и посылается на печать. Вроде так...
"Полосами" растеризуется только для растровых принтеров (струйники). Большинство (если не все) лазерных принтеров получают страницу в виде PostScript.

D_T>А у gdi+ есть свой формат метафайлов который поддерживает эти все его градиенты и сглаживание. Возможно там тот же принцип...


У GDI+ свой, странный формат метафайлов. Странный потому, что его не может прочесть даже стандартный просмотрщик WinXP.
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.