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 объекты и его константы на входе, не озадачивается особенно форматом устройства вывода и "космическими координатами". Только вот качество его антиалиасинга не супер
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.