Здравствуйте, c-smile, Вы писали:
CS>А зачем нужна в UI x64 версия? Кроме того что это сразу увеличит требуемые потребности в памяти?
Дело не в количестве памяти, а в том, что невозможно использовать 32-битную длл-ку в x64 приложении.
А специфика моего проекта как раз в том, что приходится работать в настоящем x64 режиме.
К тому же создание x64 длл-ки из 32-битных исходников дело абсолютно плевое. Обычно изменений никаких не требуется. Если у Вас возникнут затруднения я с удовольствием помогу
Здравствуйте, YuriKobets, Вы писали:
YK>Здравствуйте, c-smile, Вы писали:
CS>>А зачем нужна в UI x64 версия? Кроме того что это сразу увеличит требуемые потребности в памяти?
YK>Дело не в количестве памяти, а в том, что невозможно использовать 32-битную длл-ку в x64 приложении. YK>А специфика моего проекта как раз в том, что приходится работать в настоящем x64 режиме.
YK>К тому же создание x64 длл-ки из 32-битных исходников дело абсолютно плевое. Обычно изменений никаких не требуется. Если у Вас возникнут затруднения я с удовольствием помогу
Затруднения сугубо организационные. Я собираю сейчас это дело в VS6 и в VS2005 собираю Mobile версию. Есть еще GCС для Линукс версии.
Просто время нужно чтобы все это организовать и вставить в билд процесс. Плюс машина отдельная для win64. Плюс тесты.
Не обещаю строго но постараюсь сделать на той неделе или двух.
FM>>>Your application shall include link to Terra Informatica site in "About" dialog or similar place in your application. Text of the link: This Application (or Component) uses HTMLayout Component, copyright Terra Informatica Software, Inc. (http://terrainformatica.com).
O>>А как приобрести версию, которая не имеет этого требования? Но сорцы не нужны и бешенные деньги платить за них тоже не хочется.
CS>Кстати Source Code License не освобождает от этого тоже. Copyright я не продаю. CS>В продуктах Symantec например в readme ссылки на нас есть.
Readme и About — совершенно разные по "крутости" требования. Не знаю, есть ли у нас readme, но думаю туда попихать проблем нет.
CS>Мне интересна мотивация "версию, которая не имеет этого требования". Без всякой задней мысли спрашиваю — действительно интересно почему это может быть нужно.
Да всё просто В About просто некуда впихивать. Если бы как у Adobe было 150 ссылок на всяких товарищей, то и без проблем. А так у нас пока просто нет ни одного такого поставщика библиотек, которого бы надо было бы анонсировать.
CS>Я в состоянии понять практически любые доводы. Поэтому если мне объяснят — я могу чего-то такое придумать в плане лицензии.
Если readme.txt входит в список "similar place in your application", то я выясню.
Только одно но... Ошибочно показывает анимированные гифы По-крайней мере один... Если надо экземплярчик — вышлю на мыло. У меня такое ощущение, что кадры прозрачные и фон не очищается перед отрисовкой кадра. Остальные вопросы напишу в форум.
Здравствуйте, adontz, Вы писали:
A>Здравствуйте, c-smile, Вы писали:
CS>>Мне интересна мотивация "версию, которая не имеет этого требования". Без всякой задней мысли спрашиваю — действительно интересно почему это может быть нужно. CS>>Я в состоянии понять практически любые доводы. Поэтому если мне объяснят — я могу чего-то такое придумать в плане лицензии.
A>Создать впечатление целостности продукта, а не сборной солянки. Для кого-то продукт вида "мы скрестили крокодила с леопардом, поглядите какой вышел зверюга" представляет меньший интерес, чем "мы своими руками вырастили суслика".
Я не понимаю практическую ценность этого. Конечному пользователю *абсолютно* все равно из каких DLL оно у тебя сделано. Важно лишь есть ли та или иная функция или нет и как именно она сделана. Проверенно на user base BlockNote.
"Создать впечатление целостности продукта" — у кого надо создать такое впечатление?
A>Потому что 3rd party компоненты, даже если они доступны в исходниках это как правило зависимость от других. Исходники нужны чтобы легче что-то отладить, уточнить вопросы не достаточно раскрытые в документации, но я себе слабо представляю что кто-то купит исходники HTMLayout и будет массово исправлять в них ошибки. Соответсвенно если есть приложение основанное на HTMLayout и в нём есть глюк, то работа стоит, все ждут пока ты снизойдёшь этот глюк исправить. В принципе опытному программисту понятно, что даже в CRT бывают глюки и сторонний компонент это ещё не конец света, но кому-то может быть не так понятно. Лично я сталкивался.
Проверенно следующее:
1) мы исправляем свои баги в 10-15 раз быстрее чем кто-бы то ни было со стороны.
2) среднее время баго фикса в htmlayout: критического 1 день, функионального — 3 дня. Можно посмотреть по логам и по форуму.
3) Feature request если он обоснован и нет разумного обходного пути — примерно неделя.
Если мне кто-нибудь назовет продукт соизмеримой сложности обладающий схожей динамикой поддержки — буду признателен.
Претензию "ждут пока ты снизойдёшь этот глюк исправить" — не принимаю как не соответствующую действительности.
Единственная причина возможной задержки — мы заняты решением проблем за которые заплачены деньги — эти люди в нас вложились — мы им обязаны.
Се ля ви.
И вообще про "Снизойдешь..." — иногда приходят люди заранее настроенные на то что к ним будут "снисходить" но это проблема уже не наша ибо мы не "снисходим" — мы просто работаем — ни времени, ни желания, ни потребности на снисходительный выпендреж просто нет — не тот случай.
"Исходники нужны чтобы легче что-то отладить, уточнить вопросы не достаточно раскрытые в документации"
Теоретически да — в реале очень сложно. Проверено неоднократно — слабо помогает.
*Гораздо* эффективнее 1) спросить на форуме. 2) подготовить воспроизводимый unit test для проблемной ситуации. Фикс в этом случае дело часа в рабочие часы Western Paсific.
Я лично сомневаюсь что наличие исходников скажем FF кому-то сильно помогло решить проблемы с ним связанные.
htmlayout конечно значительно копактнее: 64,630 строк кода — против 2,172,520 в FF, но тем не менее.
A>P.S. Кстати, когда первый раз увидел HTMLayout, то был настроен по отношению к нему крайне негативно. Скажу и причину (может поможет?) — грязновато написанные (скажем прямо, не вылизанные) заголовочные файлы из SDK. В Си++ API я помню мне даже какую-то мелочь исправлять пришлось. В глубине души я был глубоко уверен что внутри тоже самое. Я не могу ни подтвердить ни опровергнуть это. Более того, уже давно пользуюсь HTMLayout и вроде всё нормально ( почти ), но осадочек остался. И если бы мне пару лет тому назад сказали — у нас программка, а для рендеринга HTML мы используем замечательную библиотеку HTMLayout, я бы поглядел исходники из SDK и вынес бы вердикт — переписать. Поэтому и Infragistics в своё время под моим чутким руководством была заменёна на DevExpress. Просто аккуратнее написана та часть кода, которую я мог увидеть. Для меня это очень важный критерий. Скорее всего я не одинок, хотя и не претендую на принадлежность большинству.
"грязновато написанные (скажем прямо, не вылизанные) заголовочные файлы из SDK."
Официальные заголовочные файлы — это те которые содержат объявления внешних функций — это то за что мы отвечаем.
С++ wrappers это сугубо примеры как это *может* быть обернуто в C++. Изначально предполагалось что это просто примеры. К ним так и следует относиться.
Практика показала что народ делает свои версии оных — больше удовлетворяющих корпоративным стандартам и культуре.
Судить о sorce code Windows по скажем исходникам WTL — это абсолютно бесперспективное занятие.
Составить мнение о sorce code htmlayout можно в принципе по Harmonia. Идеи и имплементация близка.
В htmlayout больше "шума" ибо изначальные спеки HTML и особенно CSS достаточно скажем неоднозначны сами по себе.
Но претензию принимаю — приведение типов надо делать явно — это как я понимаю и есть суть высказывания "грязновато написанные".
Здравствуйте, orangy, Вы писали:
O>Здравствуйте, c-smile, Вы писали:
FM>>>>
FM>>>>Your application shall include link to Terra Informatica site in "About" dialog or similar place in your application. Text of the link: This Application (or Component) uses HTMLayout Component, copyright Terra Informatica Software, Inc. (http://terrainformatica.com).
O>>>А как приобрести версию, которая не имеет этого требования? Но сорцы не нужны и бешенные деньги платить за них тоже не хочется.
CS>>Кстати Source Code License не освобождает от этого тоже. Copyright я не продаю. CS>>В продуктах Symantec например в readme ссылки на нас есть. O>Readme и About — совершенно разные по "крутости" требования. Не знаю, есть ли у нас readme, но думаю туда попихать проблем нет.
Юридически (и мне лично) все равно где оно окажется — в Readme или About — где-то должно быть в оффициальной дистрибуции. Иначе считается что вы заявляете свой copyright.
CS>>Мне интересна мотивация "версию, которая не имеет этого требования". Без всякой задней мысли спрашиваю — действительно интересно почему это может быть нужно. O>Да всё просто В About просто некуда впихивать. Если бы как у Adobe было 150 ссылок на всяких товарищей, то и без проблем. А так у нас пока просто нет ни одного такого поставщика библиотек, которого бы надо было бы анонсировать.
А как вы обходитесь с например Sun Java VM и пр. Просто инетересно...
CS>>Я в состоянии понять практически любые доводы. Поэтому если мне объяснят — я могу чего-то такое придумать в плане лицензии. O>Если readme.txt входит в список "similar place in your application", то я выясню.
O>Только одно но... Ошибочно показывает анимированные гифы По-крайней мере один... Если надо экземплярчик — вышлю на мыло. У меня такое ощущение, что кадры прозрачные и фон не очищается перед отрисовкой кадра. Остальные вопросы напишу в форум.
Были проблемы с aGIF но сейчас bug tracking пуст на эту тему.
На aGIF нет четкой спецификации — она размазана по многим источникам часть из которых уже недоступна формально — например Netscape GIF extensions. AOL убила сайт http://developer.netscape.com/
Поэтому возможны разные интерпретации. Давай конкретный пример — будем разбираться.
Здравствуйте, c-smile, Вы писали:
A>>Создать впечатление целостности продукта, а не сборной солянки. CS>Я не понимаю практическую ценность этого.
Практической нет, есть маркетологическая. Тебя никогда не удивляло почему Pure C# Library нередко продаются горадо лучше, чем интеропы к качественным библиотекам? Что за вообще массовый идиотизм с этим "Pure C#"? Как будто на шарпе алгоритмы имеют другую асимптотику или файлы быстрее читаются
CS>"Создать впечатление целостности продукта" — у кого надо создать такое впечатление?
У потребителя. Думаю тут имеет место специфика библиотек не присущая приложениям.
CS>1) мы исправляем свои баги в 10-15 раз быстрее чем кто-бы то ни было со стороны.
Это естественно, это же ваш код Более того, вы это сделаете корректнее.
CS>2) среднее время баго фикса в htmlayout: критического 1 день, функионального — 3 дня. Можно посмотреть по логам и по форуму.
Нууу... и что ты скажешь кастомеру? Поглядите в форум и логи? Да, ты там исправил какие-то ошибки за один день, а сколько не исправил и промолчал? Было бы желание придраться, а повод всегда можно найти.
CS>Если мне кто-нибудь назовет продукт соизмеримой сложности обладающий схожей динамикой поддержки — буду признателен. CS>Претензию "ждут пока ты снизойдёшь этот глюк исправить" — не принимаю как не соответствующую действительности.
Тебе, конечно, респект огромный, но никто динамику именно HTMLayout изучать не будет. Судят о сторонних компонентах вообще. И средняя динамика не один и даже не три дня.
CS>И вообще про "Снизойдешь..." — иногда приходят люди заранее настроенные на то что к ним будут "снисходить" но это проблема уже не наша ибо мы не "снисходим" — мы просто работаем — ни времени, ни желания, ни потребности на снисходительный выпендреж просто нет — не тот случай.
Эта... ты не горячись так, я же не от своего имени, я гипотетически
CS>"Исходники нужны чтобы легче что-то отладить, уточнить вопросы не достаточно раскрытые в документации"
CS>Теоретически да — в реале очень сложно. Проверено неоднократно — слабо помогает. CS>*Гораздо* эффективнее 1) спросить на форуме. 2) подготовить воспроизводимый unit test для проблемной ситуации. Фикс в этом случае дело часа в рабочие часы Western Paсific.
Типичный пример — некорректны значения параметров. Всегда лучше иметь нормальный стек и увидеть какой именно параметр вызвал глюк. Хотя не спорю, применимость не очень широка. И да, документация лучше, но твой форум не очень обширен и документация, скажем прямо, далеко не все вопросы обсасывает. То есть конечно можно как я, исходить из принципа — "если есть неоднозначность, то разрешаем её по пути, по которому пошёл бы умный человек", но увы и ах, это опять таки применимо только к HTMLayout и мало к чему ещё.
CS>Я лично сомневаюсь что наличие исходников скажем FF кому-то сильно помогло решить проблемы с ним связанные.
Не путай приложения и библиотеки, очень разные подходы.
CS>"грязновато написанные (скажем прямо, не вылизанные) заголовочные файлы из SDK."
CS>Официальные заголовочные файлы — это те которые содержат объявления внешних функций — это то за что мы отвечаем.
Нет, ту какое дело. Ты исходишь из предпосылки что если они синтаксически и семантически корректны, то ты своё дело сделал. А неплохо бы написать к каждой функции комментарии, возможные значения параметров, зависимости (в функции А используем дескрипот возвращаемый функцией Б). Ну мне просто лень шерстить по форуму из-за элементарных вопросов.
CS>С++ wrappers это сугубо примеры как это *может* быть обернуто в C++. Изначально предполагалось что это просто примеры. К ним так и следует относиться.
Нет такого явного позиционирования. Да даже если бы и было, всё равно баги лучше исправить.
CS>Практика показала что народ делает свои версии оных — больше удовлетворяющих корпоративным стандартам и культуре.
До этого ещё надо дорасти. А когда мне нужен sandbox, чисто поглядеть что это вообше, и вдруг выясняется что ты забыл у функции описанной в заголовочном файле добавить модификатор inline и теперь у меня ошибка компоновки... становится очень лень идти дальше. Вот просто лень. Обычный кодер скорее отпишется что у библиотеки некорректный SDK и лучше дальше использовать IWebBrowser, чем полезет править твой код.
CS>Судить о sorce code Windows по скажем исходникам WTL — это абсолютно бесперспективное занятие.
WTL нет, а ATL/MFC/VC СRT?
CS>Составить мнение о sorce code htmlayout можно в принципе по Harmonia. Идеи и имплементация близка. CS>В htmlayout больше "шума" ибо изначальные спеки HTML и особенно CSS достаточно скажем неоднозначны сами по себе.
Чуйдесно, но это ИМХО наивно говорить человеку — "Если хотите увидеть качество кода HTMLayout, то фиг вам, зато я вам покажу гармонию ". SDK это всё что у тебя есть.
CS>Но претензию принимаю — приведение типов надо делать явно — это как я понимаю и есть суть высказывания "грязновато написанные".
Не только, смешение стилей именования, в разных местах разные сокрашения, то he, то hElement. У меня старой версии не особо осталось, я вообще уже под .Net интероп написал (Кстати старый дурак, обещал показать и всё никак руки не дошли. Он по ходу Pure C#, ЛОЛ ) в хидеры уже давно не сморю.
Такая небрежность меня настораживает, ибо SDK это лицо проекта. Встречают-то по одёжке.
Здравствуйте, c-smile, Вы писали:
CS>Юридически (и мне лично) все равно где оно окажется — в Readme или About — где-то должно быть в оффициальной дистрибуции. Иначе считается что вы заявляете свой copyright.
Я правильно понимаю, что упоминание должно
а) устанавливаться вместе с той версией продукта, которая использует (вызывает) код в HTMLayout
б) быть доступным для пользователя с точки зрения прочтения заданного текста
?
CS>А как вы обходитесь с например Sun Java VM и пр. Просто инетересно...
Не знаю.
O>>Только одно но... Ошибочно показывает анимированные гифы По-крайней мере один... Если надо экземплярчик — вышлю на мыло. У меня такое ощущение, что кадры прозрачные и фон не очищается перед отрисовкой кадра. Остальные вопросы напишу в форум.
CS>Были проблемы с aGIF но сейчас bug tracking пуст на эту тему. <...> CS>Поэтому возможны разные интерпретации. Давай конкретный пример — будем разбираться.
Дальше — в форумах HTMLayout.NET, ок?
Здравствуйте, orangy, Вы писали:
O>Здравствуйте, c-smile, Вы писали:
CS>>Юридически (и мне лично) все равно где оно окажется — в Readme или About — где-то должно быть в оффициальной дистрибуции. Иначе считается что вы заявляете свой copyright. O>Я правильно понимаю, что упоминание должно O>а) устанавливаться вместе с той версией продукта, которая использует (вызывает) код в HTMLayout
Да.
O>б) быть доступным для пользователя с точки зрения прочтения заданного текста O>?
Можно сказать и так.
CS>>А как вы обходитесь с например Sun Java VM и пр. Просто инетересно... O>Не знаю.
O>>>Только одно но... Ошибочно показывает анимированные гифы По-крайней мере один... Если надо экземплярчик — вышлю на мыло. У меня такое ощущение, что кадры прозрачные и фон не очищается перед отрисовкой кадра. Остальные вопросы напишу в форум.
CS>>Были проблемы с aGIF но сейчас bug tracking пуст на эту тему. <...> CS>>Поэтому возможны разные интерпретации. Давай конкретный пример — будем разбираться. O>Дальше — в форумах HTMLayout.NET, ок?
Здравствуйте, c-smile, Вы писали: CS>Не OpenSource по причинам сугубо прагматическим. CS>1) В случае замкнутого компонента никому они по большому счету особо не нужны. Хороший API — да нужен. CS>2) Инвесторы не любят связываться с open source — очень много уходит денег на адвокатов и прочая. CS>3) В такой модели у меня исходники покупают даже китайцы.
Понял.
Тогда еще вопрос:
— какие планы по linux-версии? ожидается или нет?
Не то чтобы она была нужна "технически" но ее существование весьма нужно "комерчески" —
на тендерах в госконторах, продукт не умеющий отображаться под linux в несколько проигрышном положении.
Здравствуйте, Alex EXO, Вы писали:
AE>Здравствуйте, c-smile, Вы писали: CS>>Не OpenSource по причинам сугубо прагматическим. CS>>1) В случае замкнутого компонента никому они по большому счету особо не нужны. Хороший API — да нужен. CS>>2) Инвесторы не любят связываться с open source — очень много уходит денег на адвокатов и прочая. CS>>3) В такой модели у меня исходники покупают даже китайцы.
AE>Понял. AE>Тогда еще вопрос: AE>- какие планы по linux-версии? ожидается или нет?
AE>Не то чтобы она была нужна "технически" но ее существование весьма нужно "комерчески" - AE>на тендерах в госконторах, продукт не умеющий отображаться под linux в несколько проигрышном положении.
На Linux будет точно Sciter, во всяком случае tiscript там уже работает и примерно 65% остального кода готова.
Во всяком случае htmlayout и sciter уже работают под wine как мне сказали.
Здравствуйте, adontz, Вы писали:
A>Практической нет, есть маркетологическая. Тебя никогда не удивляло почему Pure C# Library нередко продаются горадо лучше, чем интеропы к качественным библиотекам?
Потому что они 100% verifiable. A>Что за вообще массовый идиотизм с этим "Pure C#"? Как будто на шарпе алгоритмы имеют другую асимптотику или файлы быстрее читаются
Другую. Алгоритмы на шарпе имеют асимптотику никогда не подвергаться buffer overrun. При вылете из них исключения текст ошибки + call stack значительно быстрее читаются, чем бинарные дампы.
A>У потребителя. Думаю тут имеет место специфика библиотек не присущая приложениям.
Ага. То-то я посмотрю все потребители так и ломанулись стирать IE, посмотрев на список официальных заимствований в About.
Как правило, озабоченность возникает у покупателей эксклюзивной лицензии, т.к. их напрягает перспектива получить нелегальный продукт только от того, что его разработчик не озаботился соблюдением ограничений 3rd-party license.
Например, некоторые вендоры включают требование упомянуть powered by только в бесплатных лицензиях, снабженных иногда и другими ограничениями.
Но этот момент относительно легко исправим грамотным маркетингом. пишешь Based on industry-proven solution from c-smile на коробке, а в License.txt пишешь, что
This product contains portions of code copyrighted from c-smile under terms of the ... license agreement.
1.2.0 alpha rev. 655
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
S>Как правило, озабоченность возникает у покупателей эксклюзивной лицензии, т.к. их напрягает перспектива получить нелегальный продукт только от того, что его разработчик не озаботился соблюдением ограничений 3rd-party license. S>Например, некоторые вендоры включают требование упомянуть powered by только в бесплатных лицензиях, снабженных иногда и другими ограничениями.
S>Но этот момент относительно легко исправим грамотным маркетингом. пишешь Based on industry-proven solution from c-smile на коробке, а в License.txt пишешь, что S>
This product contains portions of code copyrighted from c-smile under terms of the ... license agreement.
Здравствуйте, Sinclair, Вы писали:
A>>Практической нет, есть маркетологическая. Тебя никогда не удивляло почему Pure C# Library нередко продаются горадо лучше, чем интеропы к качественным библиотекам? S>Потому что они 100% verifiable. A>>Что за вообще массовый идиотизм с этим "Pure C#"? Как будто на шарпе алгоритмы имеют другую асимптотику или файлы быстрее читаются S>Другую. Алгоритмы на шарпе имеют асимптотику никогда не подвергаться buffer overrun. При вылете из них исключения текст ошибки + call stack значительно быстрее читаются, чем бинарные дампы.
Честно говоря я не вижу большой разницы увидет ли конечный пользователь "читаемый stack trace" или "Access Violation at...". В любом случае имеет место падение приложения. Мне например для вычислений интероп над GMP гораздо ближе чем велосипед на C#. Кроме того сам тезис про "читаемый stack trace" в корне ошибочен. Стек трейсу .Net до unmanaged dumps ещё ползти и ползти. Ты например можешь из этого stack trace выдрать не только список функций, но и конкретные значения параметров? То-то же.
A>>У потребителя. Думаю тут имеет место специфика библиотек не присущая приложениям. S>Ага. То-то я посмотрю все потребители так и ломанулись стирать IE, посмотрев на список официальных заимствований в About.
Некорректный пример. Тут выбор уже сделан и вопрос стоит о перевыборах. А для этого текущий выбор должен существенно неудовлетворять. Вобщем мимо кассы пример.
Здравствуйте, c-smile, Вы писали:
CS>Вот первые результаты рендеринга htmlite (windowless htmlayout) на DirectX surface (3D): CS>Это пока рендеринг в режиме "html texture" поэтому качество линий и фонтов не блещет: CS>http://www.terrainformatica.com/htmlayout/images/dx-htmlite-test.jpg
Наша контора как раз занимается внедрением высококачественного рендерера для 2D с максимальной поддержкой HW (для DirectX, OpenGL, etc) http://www.scaleform.com/
Основное направление — это UI для геймеров. Ну и соответственно как главная идея — высокоэффективный и качественный векторный rendering back-end: http://www.rsdn.ru/Forum/Message.aspx?mid=1908969&only=1
Здравствуйте, McSeem2, Вы писали:
MS>Наша контора как раз занимается внедрением высококачественного рендерера для 2D с максимальной поддержкой HW (для DirectX, OpenGL, etc) http://www.scaleform.com/ MS>Основное направление — это UI для геймеров. Ну и соответственно как главная идея — высокоэффективный и качественный векторный rendering back-end: http://www.rsdn.ru/Forum/Message.aspx?mid=1908969&only=1
Здравствуйте, korzhik, Вы писали:
K>с AGG сравнивали? K>понятно что будет быстрее, но интересно насколько?
Иногда даже медленнее, все это сильно зависит. Если полигон состоит из 100 точек и занимает пол экрана, то порубать его на треугольники и рисовать через DirectX будет в десятки раз быстрее. Но если в нем 10000 точек и при этом он занимает 20x20 пикселов, то чисто софтварная сканлайн растеризация становится в десятки раз быстрее. В идеале нужна комбинация тесселяции и растеризации с неким интеллектом по оценке вычислительной сложности.
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
Здравствуйте, McSeem2, Вы писали:
MS>Здравствуйте, korzhik, Вы писали:
K>>с AGG сравнивали? K>>понятно что будет быстрее, но интересно насколько?
MS>Иногда даже медленнее, все это сильно зависит. Если полигон состоит из 100 точек и занимает пол экрана, то порубать его на треугольники и рисовать через DirectX будет в десятки раз быстрее. Но если в нем 10000 точек и при этом он занимает 20x20 пикселов, то чисто софтварная сканлайн растеризация становится в десятки раз быстрее. В идеале нужна комбинация тесселяции и растеризации с неким интеллектом по оценке вычислительной сложности.
Максим, ещё вопрос: если можно, в двух словах, объясни пожалуйста, почему вы отказались от пиксельных шейдеров. Ведь на них можно вести расчёты (http://www.gpgpu.org/) или для данной задачи это не катит?
Здравствуйте, korzhik, Вы писали:
K>Максим, ещё вопрос: если можно, в двух словах, объясни пожалуйста, почему вы отказались от пиксельных шейдеров. Ведь на них можно вести расчёты (http://www.gpgpu.org/) или для данной задачи это не катит?
Совсем не отказались. Просто нашлось решение без них. Во-первых, шейдеры надо экономить, в идеале вообще оставить в монопольное владение гейм-девелоперам. Во-вторых, на новых графических мобильных чипах от, скажем, PowerVR, шейдерами еще и не пахнет, хотя треугольники с интерполяцией рисуются быстро.
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
Здравствуйте, YuriKobets, Вы писали:
YK>Здравствуйте, c-smile, Вы писали:
CS>>А зачем нужна в UI x64 версия? Кроме того что это сразу увеличит требуемые потребности в памяти?
YK>Дело не в количестве памяти, а в том, что невозможно использовать 32-битную длл-ку в x64 приложении. YK>А специфика моего проекта как раз в том, что приходится работать в настоящем x64 режиме.
YK>К тому же создание x64 длл-ки из 32-битных исходников дело абсолютно плевое. Обычно изменений никаких не требуется. Если у Вас возникнут затруднения я с удовольствием помогу
В About просто некуда впихивать. Если бы как у Adobe было 150 ссылок на всяких товарищей, то и без проблем. А так у нас пока просто нет ни одного такого поставщика библиотек, которого бы надо было бы анонсировать. 
По-крайней мере один... Если надо экземплярчик — вышлю на мыло. У меня такое ощущение, что кадры прозрачные и фон не очищается перед отрисовкой кадра. Остальные вопросы напишу в форум.
), но осадочек остался. И если бы мне пару лет тому назад сказали — у нас программка, а для рендеринга HTML мы используем замечательную библиотеку HTMLayout, я бы поглядел исходники из SDK и вынес бы вердикт — переписать. Поэтому и Infragistics в своё время под моим чутким руководством была заменёна на DevExpress. Просто аккуратнее написана та часть кода, которую я мог увидеть. Для меня это очень важный критерий. Скорее всего я не одинок, хотя и не претендую на принадлежность большинству.
1.2.0 alpha rev. 655
