Здравствуйте, <Аноним>, Вы писали:
А>(Whistler)
А>Я извиняюсь еще раз. Перегнул палку, обещаю впредь больше не беспредельничать.
Во. Это слова "не мальчика, но мужа".
ЗХ>>Есть мнение, что попав в новое место, не стоит сразу же демонстрировать понты. Можно оказаться в глупом положении (например, начать учить жизни эксперта в обсуждаемой теме, что и произошло в данном случае).
А>Ваше мнение ошибочно, я на форуме с 2002 года.
Я подразумевал, что Вы ничего не знали о квалификации собеседника. Под "новым местом" подразумевался не RSDN вообще, а философские дискуссии в юзабилити — в частности.
А>И не озадачен целью кидать понты, так как не считаю себя самым умным — иначе меня бы сдесь небыло.
Вот и я ж о том По исходному Вашему сообщению складывалось другое впечатление, на что я и указал.
ЗЫ: ходатайствую к модератору о назначении инцидента исчерпанным.
Здравствуйте, McSeem2, Вы писали:
MS>SVG — генерируется элементарно, но почти ничем не отображается (Adobe SVG не в счет — это такая дырища в security, что лучше не ставить).
FF 1.5 умеет
... << RSDN@Home 1.2.0 alpha rev. 615 on Windows XP 5.1.2600.131072>>
Здравствуйте, GlebZ, Вы писали:
GZ>Я бы сказал так. Если человеческий глаз не будет отличать линию нарисованную одним пикселем, и двумя пикселями, то это начало новой эпохи.
На VGA PDA что то близкое наблюдается.
... << RSDN@Home 1.2.0 alpha rev. 615 on Windows XP 5.1.2600.131072>>
Здравствуйте, McSeem2, Вы писали:
MS>Это не так просто как кажется. Вот скажи, много ли сейчас осталось матричных иголочных принтеров? Лазерники-струйники с их 600 или 1200 dpi давно победили. Почему? Потому что "так красивше". Экстраполируя, могу предположить (гипотетически), что если ты пару месяцев поработаешь с полноценной экранной графикой в 600dpi, ты будешь воспринимать современные мониторы 1280x1024 как "полный ацтой" и скажешь "что это за издевательство над зрением?!" Разве не так?
Тут есть еще одна проблема.
Предположим, что у тебя разрешение 8000x6000. Минимальная частота развертки, моргания от которой абсолютно не заметно глазом — более 200 Гц (!!!, а не 100Гц, как думают некоторые). Насколько я понял, частота развертки стоит раньше по приоритетам?
Теперь попытайся спроектировать либо цифровую либо аналоговую систему передачи данных на монитор с такими параметрами.
Успехов.
ЗЫ.
Телевидение высокой четкости имет параметры всего лишь в 2 раза превышающие параметры обычного телевидения, я те примерно таковы:
512 строк для яркостной информации, полоса пропускания соответствует примерно 800 точкам. Для информации о цвете — по вертикали в 2 раза худшие, по горизонтали — в 5-6.
------------
Ругать MS за шрифты вообще смешно. Когда графические интерфейсы завоевывали популярность разниа в стоимости 14" и 15" мониторов была чуть ли не в 2 раза. 19" мониторы стоили целое состояние. MS элементарно собрали требования к актуальным характеристикам своего времени и воплотили их.
------------
Кстати, сама архитектура Windows никак не ограничивает собственные механизмы рендеринга шрифтов. Бери какой-нить рендерер и рендери сам.
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, GlebZ, Вы писали:
GZ>>Я бы сказал так. Если человеческий глаз не будет отличать линию нарисованную одним пикселем, и двумя пикселями, то это начало новой эпохи.
AVK>На VGA PDA что то близкое наблюдается.
Я читал как-то по VGA КПК адобовские документы. Буквы там кривые. У меня (не VGA) кривее кривых.
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, GlebZ, Вы писали:
AVK>>>На VGA PDA что то близкое наблюдается. GZ>>Я читал как-то по VGA КПК адобовские документы.
AVK>Запустил, посмотрел. Кривизны особой не наблюдаю.
Нее, особая кривизна это у меня . Буквы разные по размеру даже в одном слове. Я специально смотрел у друзей на VGA, как бы значительно лучше, но все равно присутствует. Пока не присмотришся не увидишь.
С уважением, Gleb.
ЗЫ Это Adobe Reader 2.0 for Pocket PC.
Здравствуйте, vdimas, Вы писали:
V>Предположим, что у тебя разрешение 8000x6000. Минимальная частота развертки, моргания от которой абсолютно не заметно глазом — более 200 Гц (!!!, а не 100Гц, как думают некоторые). Насколько я понял, частота развертки стоит раньше по приоритетам?
Интересно, откуда эти басни про 200 герц? Кому нужна такая частота? Я долгое время жил на CRT 75 герц. Это чуть маловато, но уже приемлемо. На практике 100 герц — вполне достаточно. Это для CRT. Все LCD по цифровому DVI работают на 60 герцах. За счет инерционности LCD, ни малейшего мерцания просто не существует. Возможно, что эти байки идут от думеров-квакеров, которым подавай 200 FPS? Но там и не надо никаких 8000x6000.
Шизнутые аудиофилы якобы слышат разницу в звуке, когда заменяют провод от усилителя к розетке специальным "аудиофильским" за 100 баксов. 200 герц развертки — это примерно из той же оперы.
V>Теперь попытайся спроектировать либо цифровую либо аналоговую систему передачи данных на монитор с такими параметрами.
Можно представить себе следующую схему (я, кстати говоря, еще лет 15 назад о такой мечтал). У нас есть светодиодная матрица 8000x6000. Под каждым пикселом находится маленький процессор и сотня байт памяти. Этот процессор умеет выполнять операцию AlphaBlend. В продвинутых случаях — остальные color compositing операции. Управляются эти процессоры строчно-столбцовым способом. Типа "открыть порт для передачи данных по всей строке номер 1343 — передать данные в колонку 2345". Таким образом мы засветили один пиксел. Закраска прямоугольника 1000x1000 при этом требует не миллион итераций, а всего-навсего 1000+1000. Anti-aliasing при таком разрешении нам не нужен и это сильно упрощает дело. Кроме того, каждый пиксел может сам себе быть альфа-маской и/или z-буфером.
V>Ругать MS за шрифты вообще смешно. Когда графические интерфейсы завоевывали популярность разниа в стоимости 14" и 15" мониторов была чуть ли не в 2 раза. 19" мониторы стоили целое состояние. MS элементарно собрали требования к актуальным характеристикам своего времени и воплотили их.
Хинты TrueType были актуальны во времена 16 цветов, когда ни о каком сглаживании не было и речи. Как только появилось сглаживание, "агрессивность" хинтов можно было бы сразу поубавить в угоду возможности свободного масштабирования. Кстати говоря, даже для чисто черно-белого рисования вполне достаточно Type I. Берем тот же Acrobat и выключаем сглаживание — текст выглядит нормально. Возможно, несколько хуже, чем TrueType без сглаживания, но вполне приемлемо. Но с появлением ClearType, агрессивность хинтов только возросла. В ClearType — вообще можно сказать, что линии в буквах приколачиваются гвоздями. Раз уж я завел об этом речь, ClearType — это вещь в себе. Это не технология рендеринга, ClearType жестко завязан на сами шрифты. В составе словаря MultiLex есть шрифт PhoneticTM, сделанный по старым правилам. Вот он: http://antigrain.com/stuff/PHONTM__.TTF Так вот, WinXP отказывается рисовать этот шрифт с ClearType как ни крути, хотя с обчным grayscale сглаживанием — рисуется. Следовательно, не каждый шрифт поддерживает "ClearType-ность". Получается, что "хотите ClearType — пользуйтесь нашими шрифтами". Я считаю правила такой игры нечестными — это та же профанация.
V>Кстати, сама архитектура Windows никак не ограничивает собственные механизмы рендеринга шрифтов. Бери какой-нить рендерер и рендери сам.
Адоба именно так и делает. Но ведь массовое сознание определяется именно тем, что предоставлено в виде базовых средств, разве не так? И это очень большая ответственность на самом деле. Настолько большая, что никакие прибыли не могут служить оправданием подобной профанации.
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
Здравствуйте, AndrewVK, Вы писали:
MS>>SVG — генерируется элементарно, но почти ничем не отображается (Adobe SVG не в счет — это такая дырища в security, что лучше не ставить).
AVK>FF 1.5 умеет
Поставил, посмотрел. "Полный аццтой". Паттерны не рисует вообще, маркеры — очень криво. С производительностью — просто беда. SVG-файл, размером в 700K рендерился 10 секунд (чертеж, состоящий в основном из одних линий и текста). При этом отъел более 20 мег памяти (почти тридцатикратный перерасход!). Я умею парсить и рисовать этот файл менее чем за секунду с памятью меньше мега.
Ждем XAML, может он скажет веское слово. Хотя надежды мало — очень уж там все навороченное.
Вообще, мне очень не нравится эта тенденция — типа, "вот у нас векторная графика". Но на практике это только размахивание флагом. Как только попросишь нарисовать что-то серьезное, так сразу и кирдык.
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
Ну, когда true type появлялся, негласно признавалось, что он не супер, postscript лучше. Просто тогда Adobe кормилась за счет postscript и не дала бы использовать его и элементы его технологии в виндоус. Шрифтовые дела уже много лет оттачивались на тот момент, Postcript был близок к оптимуму. MS именно придумывала что-то радикально отличное postscript, т.е. фактически от оптимума. Винды еще тащат груз, который был внесен в доисторическую эпоху какими-то недалекими разработчиками. Кому-то когда-то показалось умным мерить UI-объекты Windows в dlu — dialog units (это 1/4 системного шрифта по горизонтали и 1/8 по вертикали). Кто-то поумничал, и вот теперь мы так живем.
Здравствуйте, McSeem2, Вы писали:
MS>Ждем XAML, может он скажет веское слово.
Не жди. XAML это не формат векторной графики. Это вобще, по большому счету, формат сериализации почти произвольных объектов.
MS> Хотя надежды мало — очень уж там все навороченное.
Скорее наоборот — там слишком все примитивно.
MS>Вообще, мне очень не нравится эта тенденция — типа, "вот у нас векторная графика". Но на практике это только размахивание флагом. Как только попросишь нарисовать что-то серьезное, так сразу и кирдык.
В случае XAML все возможности по рисованию на 100% определяются набором реализаций dependency object.
Здравствуйте, AndrewVK, Вы писали:
AVK>Не жди. XAML это не формат векторной графики. Это вобще, по большому счету, формат сериализации почти произвольных объектов.
Как так? Они выдают его за некое "всеобщее щасте" — замена HTML+PDF+Flash в одном флаконе.
Using the XAML file format, organizations will no longer be required to support multiple languages, such as HTML, Flash and PDF. The marriage of XAML and WPF allow for 2D and 3D imaging, animation, audio, video, multipage fixed format and flow format documents. XAML and WPF delivers quick and economical 2D and 3D vector based application and web user interfaces. The XAML file format works great in delivering revolutionary web sites and can also be used in .NET Applications.
AVK>Скорее наоборот — там слишком все примитивно.
Что имеется в виду под "примитивно"? Возможна ли хотя бы замена растровых иконок векторными XAML-файлами (произвольно масштабируемыми)?
Кстати, я уже спрашивал — где бы взять более-менее полную спецификацию XAML, хотя бы драфт? Может это я такой неврубастый, но что-то не находится.
MS>>Вообще, мне очень не нравится эта тенденция — типа, "вот у нас векторная графика". Но на практике это только размахивание флагом. Как только попросишь нарисовать что-то серьезное, так сразу и кирдык.
AVK>В случае XAML все возможности по рисованию на 100% определяются набором реализаций dependency object.
Можно об этом поподробнее? Или скажем так — может оно нарисовать файл с векторной 2D графикой, объемом в 30 мег и при этом не требовать пары гиг памяти?
Вообще, сдается мне, что в случае с SVG FireFox основное время тратится не на рендеринг как таковой, а на сканирование DOM-контейнера, с распарсиванием строк на лету. Просто я знаю, что в качестве backend там используется Cairographics, а он достаточно шустрый, хоть и примитивный (мой основной конкурент). Но если так, то это полный маздай. Рендеринг — по идее самая вычислительно дорогая операция, но просто не отсвечивает среди этого XML-DOM хлама.
У меня — свой псевдо-DOM, в бинарном виде. И он работает на порядок быстрее и ест на порядок меньше памяти, чем любой традиционный XML-DOM.
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
Здравствуйте, McSeem2, Вы писали:
AVK>>Не жди. XAML это не формат векторной графики. Это вобще, по большому счету, формат сериализации почти произвольных объектов.
MS>Как так?
А вот так
MS>The marriage of XAML and WPF allow for 2D and 3D imaging, animation, audio, video, multipage fixed format and flow format documents. XAML and WPF delivers quick and economical 2D and 3D vector based application and web user interfaces.
Вот так — XAML и WPF. XAML это формат сериализации, в WPF есть набор классов, реализующих векторную графику. Можешь написать свой вариант — будет XAML and AGG.
AVK>>Скорее наоборот — там слишком все примитивно.
MS>Что имеется в виду под "примитивно"?
То, что хотелось бы несколько более гибкие возможности. В частности ограничивать scope attached свойств или возможность управления маппингом классов на теги.
MS> Возможна ли хотя бы замена растровых иконок векторными XAML-файлами (произвольно масштабируемыми)?
В XAML нет понятия иконки.
MS>Кстати, я уже спрашивал — где бы взять более-менее полную спецификацию XAML, хотя бы драфт? Может это я такой неврубастый, но что-то не находится.
Скачиваешь WinFX SDK, ставишь. В хелпе получаешь несколько статей по структуре и принципам организации XAML и class reference по WPF.
AVK>>В случае XAML все возможности по рисованию на 100% определяются набором реализаций dependency object.
MS>Можно об этом поподробнее? Или скажем так — может оно нарисовать файл с векторной 2D графикой, объемом в 30 мег и при этом не требовать пары гиг памяти?
XAML не может ничего рисовать. Что касаемо конкретных классов WPF — не знаю, не пробовал.
MS>Вообще, сдается мне, что в случае с SVG FireFox основное время тратится не на рендеринг как таковой, а на сканирование DOM-контейнера, с распарсиванием строк на лету.
Ну это вряд ли. Парсинг XML на современных процессорах это ничтожно мало, даже если его через задницу делать. Скорее всего проблема в позиционировании и рассчете координат.
MS>У меня — свой псевдо-DOM, в бинарном виде. И он работает на порядок быстрее и ест на порядок меньше памяти, чем любой традиционный XML-DOM.
XAML десериализует прямо в отрисовывающие компоненты.
Здравствуйте, AndrewVK, Вы писали:
MS>>Кстати, я уже спрашивал — где бы взять более-менее полную спецификацию XAML, хотя бы драфт? Может это я такой неврубастый, но что-то не находится.
AVK>Скачиваешь WinFX SDK, ставишь. В хелпе получаешь несколько статей по структуре и принципам организации XAML и class reference по WPF. AVK>XAML не может ничего рисовать. Что касаемо конкретных классов WPF — не знаю, не пробовал.
Спасибо за информацию. Но все-таки, документ-то существует в природе вообще? Для PDF — есть, для SVG — есть, для Flash-SWF — есть. А для XAML?
MS> Возможна ли хотя бы замена растровых иконок векторными XAML-файлами (произвольно масштабируемыми)? AVK>В XAML нет понятия иконки.
Я говорю вот о чем: Есть у нас на десктопе иконка, скажем "My Computer" и прочие. Сейчас они банально растровые. Возможна ли в будущем замена этого растрового безобразия на векторые XAML-файлы с возможностью произвольного масштабирования в зависимости от DPI монитора?
MS>>Вообще, сдается мне, что в случае с SVG FireFox основное время тратится не на рендеринг как таковой, а на сканирование DOM-контейнера, с распарсиванием строк на лету.
AVK>Ну это вряд ли. Парсинг XML на современных процессорах это ничтожно мало, даже если его через задницу делать. Скорее всего проблема в позиционировании и рассчете координат.
Все числовые значения у меня хранятся в виде float/double. В стантартной схеме XML-DOM мы вынуждены хранить все значения в строках, поскольку этот DOM ничего не знает о сущности данных. Простое сканирование (traverse) этого DOM (а он раздувается в памяти до 200-400 мег) уже занимает порядка 10 секунд. А при этом нам приходится еще парсить строки и превращать их в числовые значения. Так что собственно рисование — это 10-15% всего времени. Это полный маздай. Доложно быть 90%. В общем, модель хранения данных в виде XML DOM не является жизнеспособной для графики, но пока что все имплементации SVG используют именно ее — Adobe SVG, KSVG (кстати, в KSVG используется AGG), FireFox. Именно поэтому у меня есть сомнения в жизнеспособности SVG вообще. Наворотили монстра, которого никто не может толком имплементировать. Вот Макромедию я очень уважаю — взяли и сделали стандарт де-факто, без лишних ковыряний в носу. Но модель данных там очень уж нетривиальная — что для генерации, что для рисования.
AVK>XAML десериализует прямо в отрисовывающие компоненты.
Что это означает на практике? Генерируется код MSIL? Сколько памяти будут занимать, скажем 10000 окружностей?
В любом существующем SVG — это ж... полная. Десятикратный и более перерасход (ну, кроме моего, который пока что в стадии эмбриона). Как с этим обстоят дела в XAML/WPF? Какие-то меня гложут сомнения по поводу эффективности модели данных.
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
Здравствуйте, McSeem2, Вы писали:
MS>Что это означает на практике? Генерируется код MSIL? Сколько памяти будут занимать, скажем 10000 окружностей? MS>В любом существующем SVG — это ж... полная. Десятикратный и более перерасход (ну, кроме моего, который пока что в стадии эмбриона). Как с этим обстоят дела в XAML/WPF? Какие-то меня гложут сомнения по поводу эффективности модели данных.
The Xar file format, previously known as the Flare file format, is an ultra-compact, open, vector graphic format. It is also the native graphics format for Xara X application (and also its predecessors such as CorelXARA).
The document below describes the format in detail and provides information for third parties interested in converting to or from this graphics format.
Why another vector graphics format? The Xar file format is not new. It dates back nearly ten years and so it predates more recent formats such as SVG. It is not designed to compete with SVG, but Xar files are considerably simpler to understand (the SVG spec is 700 pages) and, more compact (often 10:1). However the primary reason for the existence of the open file format specification is to enable third parties to read and write the Xara X native files.
Здравствуйте, McSeem2, Вы писали:
AVK>>XAML не может ничего рисовать. Что касаемо конкретных классов WPF — не знаю, не пробовал.
MS>Спасибо за информацию. Но все-таки, документ-то существует в природе вообще? Для PDF — есть, для SVG — есть, для Flash-SWF — есть. А для XAML?
Документ о чем?
MS>> Возможна ли хотя бы замена растровых иконок векторными XAML-файлами (произвольно масштабируемыми)? AVK>>В XAML нет понятия иконки.
MS>Я говорю вот о чем: Есть у нас на десктопе иконка, скажем "My Computer" и прочие. Сейчас они банально растровые. Возможна ли в будущем замена этого растрового безобразия на векторые XAML-файлы с возможностью произвольного масштабирования в зависимости от DPI монитора?
А при чем тут XAML? В Vista можно будет векторные иконки делать. Про формат ничего не знаю.
AVK>>Ну это вряд ли. Парсинг XML на современных процессорах это ничтожно мало, даже если его через задницу делать. Скорее всего проблема в позиционировании и рассчете координат.
MS>Я работаю над проектом Renesis http://gosvg.net. И моя практика показывает, что распарсить 30 мег XML на моем древнем P4-1.9 занимает примерно 16 секунд (это с Expat, MS-XML, Xerces — немного быстрее). А нарисовать всю сцену — около 3 секунд:
Утянуть такой XML где нибудь можно?
MS>Все числовые значения у меня хранятся в виде float/double. В стантартной схеме XML-DOM мы вынуждены хранить все значения в строках, поскольку этот DOM ничего не знает о сущности данных.
А зачем вобще DOM? Он большие объемы не любит. Такие вещи нужно напрямую с потока обрабатывать.
MS>В общем, модель хранения данных в виде XML DOM не является жизнеспособной для графики,
Графика тут не при чем. Проблема в объемах. До 5 мег где то, на современных машинах вполне приемлемо. Если больше — DOM не подходит.
AVK>>XAML десериализует прямо в отрисовывающие компоненты.
MS>Что это означает на практике?
Это означает как минимум никакого DOM, все парсится прямо в целевую модель. Кроме того, для хранения, передачи и интерпретации чаще используется не XAML, а BAML (B — binary).
MS> Генерируется код MSIL?
В ранних реализациях генерировался. В теперешних нет, используется BAML, который затем интерпретируется.
MS> Сколько памяти будут занимать, скажем 10000 окружностей?
ХЗ. Если время будет попробую провести эксперимент.
MS>В любом существующем SVG — это ж... полная. Десятикратный и более перерасход (ну, кроме моего, который пока что в стадии эмбриона).
Оптимизированные версии DOM имеют коэффициент в районе 7. Но, в любом случае, хранить в DOM десятки мег XML плохая идея.
MS> Как с этим обстоят дела в XAML/WPF? Какие-то меня гложут сомнения по поводу эффективности модели данных.
В XAML нет модели данных как таковой — модель определяется поставщиком реализаций.
Здравствуйте, AndrewVK, Вы писали:
MS>>Спасибо за информацию. Но все-таки, документ-то существует в природе вообще? Для PDF — есть, для SVG — есть, для Flash-SWF — есть. А для XAML?
AVK>Документ о чем?
Спецификация XAML+WPF. Что-то аналогичное SVG: http://www.w3.org/TR/SVG11/
Грубо говоря, как там квадратики рисовать, градиенты задавать, паттерны всякие. Но еще раз повторюсь, мне бы хотелось посмотреть именно спецификацию, примеры мне мало интересны.
AVK>Утянуть такой XML где нибудь можно? http://antigrain.com/esv/arbeitskopie.zip
Файл — жутко неоптимальный. Это он специально такой
Еще маленький примерчик, http://antigrain.com/esv/recursive_pattern.svg
Валит все SVG рендереры, которые яко бы умеют рисовать паттерны. Можно нечто подобное сделать на XAML?
AVK>А зачем вобще DOM? Он большие объемы не любит. Такие вещи нужно напрямую с потока обрабатывать.
В принципе у меня так и делается. Но данные все равно надо где-то хранить, в каком-нибудь виде. Причем, весь файл. Если бы не было ссылок (причем, ссылки вперед — нормальное явление в XML), то можно было бы вообще обойтись SAX-парсером, который сразу бы растеризовал данные и требовал O(1) памяти. Но это было бы медленнее чем с неким промежуточным компактным контейнером. Фактически, контейнер у меня — это тот же XML (сплошной поток в памяти), но в бинарном виде. Поскольку он все знает про SVG, то "бинаризация" не представляет никакой проблемы. И при отрисовке этот поток "проигрывается" тоже в SAX-режиме (там еще присутствует ссылочный индекс для быстрой навигации, но это уже не важно).
AVK>В ранних реализациях генерировался. В теперешних нет, используется BAML, который затем интерпретируется. MS>> Сколько памяти будут занимать, скажем 10000 окружностей? AVK>ХЗ. Если время будет попробую провести эксперимент.
Было бы замечательно. И сколько времени оно будет рисоваться.
MS>> Как с этим обстоят дела в XAML/WPF? Какие-то меня гложут сомнения по поводу эффективности модели данных. AVK>В XAML нет модели данных как таковой — модель определяется поставщиком реализаций.
В вопросе был XAML/WPF, а не просто XAML. WPF, как я понимаю, и есть некая реализация.
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
Ellipse Class
[This topic is pre-release documentation and is subject to change in future releases. Blank topics are included as placeholders.]
Draws an ellipse.
Namespace: System.Windows.Shapes
Assembly: PresentationFramework (in presentationframework.dll)
Syntax
Visual Basic (Declaration)
Public NotInheritable Class Ellipse
Inherits Shape
Visual Basic (Usage)
C#
public sealed class Ellipse : Shape
C++
public ref class Ellipse sealed : public Shape
J#
public final class Ellipse extends Shape
JScript
public final class Ellipse extends Shape
"XAML"
<Ellipse .../>
Example
This example shows how to draw ellipses and circles using the Ellipse element. To draw an ellipse, create an Ellipse element and specify its Width and Height. Use its Fill property to specify the Brush used to paint its interior. Use its Stroke property to specify the Brush used to paint its outline. The StrokeThickness property specifies the thickness of the outline. To draw a circle, make the Ellipse element's Width and Height equal to each other.
In the following example, four Ellipse elements are drawn within a Canvas.
"XAML"
<Canvas Height="200" Width="200">
<!-- Draws an oval with a blue interior. -->
<Ellipse
Width="100"
Height="50"
Fill="Blue"
Canvas.Left="10"
Canvas.Top="25" />
<!-- Draws an oval with a blue interior and a black outline. -->
<Ellipse
Width="100"
Height="50"
Fill="Blue"
Stroke="Black"
StrokeThickness="4"
Canvas.Left="10"
Canvas.Top="100"/>
<!-- Draws a circle with a blue interior. -->
<Ellipse
Width="50"
Height="50"
Fill="Blue"
Canvas.Left="135"
Canvas.Top="25"/>
<!-- Draws a circle with a black outline. -->
<Ellipse
Width="50"
Height="50"
Stroke="Black"
StrokeThickness="4"
Canvas.Left="135"
Canvas.Top="100" />
</Canvas>
Although a Canvas is used to contain the ellipses in this example, ellipse elements (and all the other shape elements) may be used with any Panel or Control that supports non-text content.
This example is part of a larger sample; for the complete sample, see Shape Elements Sample.
More Code
Paint an Area with a Solid Color This example shows several ways to use the SolidColorBrush class to paint an area with a solid color.
Thread Safety
Any public static (Shared in Visual Basic) members of this type are thread safe. Any instance members are not guaranteed to be thread safe.
А чего там должно быть нарисовано? Опера выводит просто черный круг в синеньком квадратике, а других вьюверов у меня под рукой нет.
MS>Валит все SVG рендереры, которые яко бы умеют рисовать паттерны. Можно нечто подобное сделать на XAML?
На XAML можно, на WPF ХЗ.
MS>В принципе у меня так и делается. Но данные все равно надо где-то хранить, в каком-нибудь виде.
Ну так и хранить в том виде, который нужен для отрисовки. XAML именно так и работает.
MS> Причем, весь файл. Если бы не было ссылок (причем, ссылки вперед — нормальное явление в XML), то можно было бы вообще обойтись SAX-парсером, который сразу бы растеризовал данные и требовал O(1) памяти. Но это было бы медленнее чем с неким промежуточным компактным контейнером. Фактически, контейнер у меня — это тот же XML (сплошной поток в памяти), но в бинарном виде. Поскольку он все знает про SVG, то "бинаризация" не представляет никакой проблемы.
Ну абсолютно логичное решение. Непонятно зачем делать иначе.
MS>Было бы замечательно.
Только текущему WinFX нужен beta 2, а у меня стоит RC. Жду когда с релизами утрясется.
AVK>>В XAML нет модели данных как таковой — модель определяется поставщиком реализаций.
MS>В вопросе был XAML/WPF, а не просто XAML. WPF, как я понимаю, и есть некая реализация.
Спасибо, Андрей. Подход c документацией у них конечно несколько своеобразный, но тоже имеющий право на жизнь.
MS>>http://antigrain.com/esv/arbeitskopie.zip MS>>Файл — жутко неоптимальный. Это он специально такой
AVK>Попозже отпишу
Ждемс. Можешь его сконвертить в XAML и попробовать нарисовать? Жутко интересно. Просто у меня сейчас нет возможности все эти беты и SDK ставить.
MS>>Еще маленький примерчик, http://antigrain.com/esv/recursive_pattern.svg
AVK>А чего там должно быть нарисовано? Опера выводит просто черный круг в синеньком квадратике, а других вьюверов у меня под рукой нет.
Ну значит, опера не обрабатывает паттерны вообще. Я помню чуть мозг сломал, пока разобрался со всеми этими трансформациями.
Должен быть красивый "фрактал": http://antigrain.com/esv/recursive_pattern.png
MS>> Причем, весь файл. Если бы не было ссылок (причем, ссылки вперед — нормальное явление в XML), то можно было бы вообще обойтись SAX-парсером, который сразу бы растеризовал данные и требовал O(1) памяти. Но это было бы медленнее чем с неким промежуточным компактным контейнером. Фактически, контейнер у меня — это тот же XML (сплошной поток в памяти), но в бинарном виде. Поскольку он все знает про SVG, то "бинаризация" не представляет никакой проблемы.
AVK>Ну абсолютно логичное решение. Непонятно зачем делать иначе.
Ну не совсем, на самом деле. Например, SVG — это XML. И в спецификации заявлено, что там может присутствовать возможность XSLT трансляции. Причем, конечный результат этой трансляции — не другой сгенерированный файл, а непосредственно нарисованная картинка. И все это должно делаться на лету. Если пользоваться стандартным DOM, транслятор у нас уже есть. И мы просто напускаем его на исходный DOM после загрузки, после чего рисуем. Но это жутко неэффективно. А если у нас свой велосипед в бинарном представлении, то получается, что надо и транслятор самим писать. Жуть! Либо же отказаться от поддержки XSLT вообще. Apache Xalan вроде бы как позволяет выполнять трансляцию в потоке, но как я слабо себе представляю, как такое возможно.
Ну и есть некоторые другие "мелочи", неявно предполагающие использование натурального XML DOM. Вообще, там много нелепостей нагорожено.
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
Выводы:
1) Тот парсер, что ты глядел, никуда не годится. Нетовский управляется с твоим файлом на сопоставимой машине на порядок быстрее.
2) DOM в 5 раз быстрее последовательного парсинга, что вполне ожидаемо.
3) Последовательное чтение в специализированную модель заметно быстрее DOM, даже при том что в тесте float-переменные в спец. модели парсились. Ну и 2.5 секунды на 30М файл на весьма средненькой машинке вполне приемлемо, не находишь?
По поводу памяти ничего сказать не могу, в дотнете это не так то просто померять.
MS>Можешь его сконвертить в XAML и попробовать нарисовать?
Не, на это нужно массу времени. В ближайшее время вряд ли. Но рассчитывать на то, что ранние беты WPF что то из себя представляют в плане производительности не стоит.
MS>Ну не совсем, на самом деле. Например, SVG — это XML. И в спецификации заявлено, что там может присутствовать возможность XSLT трансляции.
Ну тогда при первом сканировании, если встретится такая бякость, то кусок для преобразований грузить таки в DOM. Причем этот DOM может быть оптимизирован под задачи XSTL-трансформации. Например в том же тесте:
XPathDocument read: 2188ms
Видишь, вполне приемлемо. Ну а результат трансформации без преобразования к тексту напрямую конвертируем в нашу модель.
MS> Причем, конечный результат этой трансляции — не другой сгенерированный файл, а непосредственно нарисованная картинка. И все это должно делаться на лету. Если пользоваться стандартным DOM, транслятор у нас уже есть. И мы просто напускаем его на исходный DOM после загрузки, после чего рисуем. Но это жутко неэффективно. А если у нас свой велосипед в бинарном представлении, то получается, что надо и транслятор самим писать.
В дотнете трансформер умеет работать по любому иерархическому источнику данных, лишь бы для него была реализация XPathNavigator (иерархический ДКА — курсор). Другое дело что исходные данные могут быть произвольным xml, а не svg, а в этом случае все равно кроме DOM ты ничего лучше не придумаешь.
По исходному Вашему сообщению складывалось другое впечатление, на что я и указал.
