Здравствуйте, VladD2, Вы писали:
VD>А загрузка ускорилась?
Да, почти как 2008 стало.
VD>Кстати, закинь (если есть такая возможность) мысль, о том, что МС сам подрывает доверие к WPF поставляя в составе виндовс сильно деоптимизированные 3D-дрова. Давиче мне один товарищ жаловался на неприемлемую производительность прокрутки в 2010-ой студии. После некоторого разбирательства и скачивания дров для видюхи с сайта Интела все вроде бы как нормализовалось.
Хорошо, постараюсь.
VD>Понятно, что в одночасье МС не начнет поставлять в составе виндовс быстрые дрова, но хотя бы написать в блогах и рейдми об этом надо.
Да мы вроде и пишем: http://beta.blogs.msdn.com/ddperf/default.aspx
Надо больше писать, я знаю Можешь кстати на этот блог сам написать, это один из главных чуваков по VS performance (David Berg), его смотрят внимательно. Тебя даже больше слушать будут, чем если я изнутри жаловаться буду.
Здравствуйте, VladD2, Вы писали:
VD>Можно ли как-то улучшить отображение шрифтов в WPF?
VD>Пытаюсь прикрутить к интеграции Nemerle с VS 2008 хинты на основе WPF.
VD>При отображении шрифтов тех же размеров, что в обычных хинтах текст читается очень плохо. Даже увеличенный шрифт (Arial 14) выглядит не очень здорово (и при этом занимает намного больше места на экране). Все смазано и причем весьма криво.
Влад, не занимайся ерундой. htmlayout или sciter твой UI на ура нарисует.
И справильными шрифтами учитывающими предпочтения юзера.
Re[2]: [WPF] Можно ли улучшить отображение шрифтов?
Здравствуйте, c-smile, Вы писали:
CS>Влад, не занимайся ерундой. htmlayout или sciter твой UI на ура нарисует. CS>И справильными шрифтами учитывающими предпочтения юзера.
Или хотя бы возьми свой собственный Rsdn.Editor, который такое тоже отлично нарисует.
Re[2]: [WPF] Можно ли улучшить отображение шрифтов?
Здравствуйте, c-smile, Вы писали:
CS>Влад, не занимайся ерундой. htmlayout или sciter твой UI на ура нарисует. CS>И справильными шрифтами учитывающими предпочтения юзера.
качество отображения стал приемлемым. Правда шрифты чуть увеличены, но так как хинт стал многоуровневым, то это не является проблемой.
Так что единственная проблема — это тормоза при первом показе.
При этом то что ты предлагаешь — это нэйтив-длл-и для который еще придется писать обертки и реализовывать функциональность многоуровневости для хинтов (вряд ли она там есть по умолчанию). Так что объем работы получается внушительным, а выходы сомнительны. В общем, легаси код. Вот так вот быстро, оказывается, им можно обжиться .
К тому же для управляемого прилоежения наверно лучше будет использовать управляемый-аналог (например, предложенный здесь
Так что огромное спасибо за ссылки, но пока попробуем обойтись WPF-ом. Тем более, что это полезно на будущее. Все равно следующая студия будет иметь на 90% управляемый-АПИ
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[3]: [WPF] Можно ли улучшить отображение шрифтов?
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, c-smile, Вы писали:
CS>>Влад, не занимайся ерундой. htmlayout или sciter твой UI на ура нарисует. CS>>И справильными шрифтами учитывающими предпочтения юзера.
VD>Благодаря этому совету
качество отображения стал приемлемым. Правда шрифты чуть увеличены, но так как хинт стал многоуровневым, то это не является проблемой.
Какая-то кофейная гущща, право слово. И забавный способ определения значения points:
var fontSize = 10.0d * (96d / 72d); // 10 points
это еще чего такое?
VD>Так что единственная проблема — это тормоза при первом показе.
Мда... студия и так не шеволится нонче... А тут ты еще со своим WPF...
VD>При этом то что ты предлагаешь — это нэйтив-длл-и для который еще придется писать обертки и реализовывать функциональность многоуровневости для хинтов (вряд ли она там есть по умолчанию). Так что объем работы получается внушительным, а выходы сомнительны. В общем, легаси код. Вот так вот быстро, оказывается, им можно обжиться .
Это какое-то заблуждение у тебя. В ситуациях когда есть managed/non-managed код (а в UI это всегда так)
выигрывать будет решение у которого меньшее количество переходов (вызовов) managed -> non-managed код.
В случае с htmlayout ты оперируешь десятком вызовов высокоуровневых методов. Вместо потока вызовов CreateBrush, FillRect и пр.
Каждый такой вызов как я понимаю чего-то да стоит.
Re[4]: [WPF] Можно ли улучшить отображение шрифтов?
Здравствуйте, c-smile, Вы писали:
CS>Здравствуйте, VladD2, Вы писали:
VD>>Здравствуйте, c-smile, Вы писали:
CS>>>Влад, не занимайся ерундой. htmlayout или sciter твой UI на ура нарисует. CS>>>И справильными шрифтами учитывающими предпочтения юзера.
VD>>Благодаря этому совету
качество отображения стал приемлемым. Правда шрифты чуть увеличены, но так как хинт стал многоуровневым, то это не является проблемой.
CS>Какая-то кофейная гущща, право слово. И забавный способ определения значения points: CS>
Здравствуйте, Sinix, Вы писали:
VD>>Тем более, что это полезно на будущее. Все равно следующая студия будет иметь на 90% управляемый-АПИ
S>А можно пруфлинк? Обычно рядом с такими заявлениями лежит ещё много новостей по роадмапу — они-то меня и интересуют.
Да это и не заявление в общем-то. Все кому надо об этом уже давно знают. Тут рядом Кирил Осенков был. Он может по части ссылок будет более качественным источником. А вообще, кому надо может просто воспользоваться гуглем. Например, VS 2010 WPF.
В VS 2010 управляемым станет почти половина GUI. Ну, и главное управляемым станет редактор кода.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[4]: [WPF] Можно ли улучшить отображение шрифтов?
На самом деле самым важным здесь является именно подбор шрифта. Он меньше обычных, то что его можно задавать большим кеглем, что приводит к улучшению качества отображения. Ну, и возможно он просто чем-то лучше подходит для WPF. Повозившись с моноширными шрифтами я сделал вывод, что лучше всего на экране выглядит Consolas (шрифт идущий в поставке с VS).
VD>>Так что единственная проблема — это тормоза при первом показе.
CS>Мда... студия и так не шеволится нонче... А тут ты еще со своим WPF...
Говорят VS 2010 beta 2 работает уже на уровне 2008-ой. Меня это устроило бы (правда верится в это с трудом).
В общем-то все новые версии студии, по крайней мере те в которых были серьезные новшества, работали чуть медленнее предыдущих. Но как-то со временем железо их догоняло и они работали совершенно приемлемо. Думаю, так будет и с этой версией.
А WPF... Дык не перевели бы на него студию, то он так и прозябал бы в черт знает каком состоянии еще долгие годы. А так, доведут до ума технологию, плюс IDE будет намного более расширяемой. Уже приводили пример плагинов которые превращали DOC-коментарии в эдакие навороченные балуны с удобным форматированием и хорошо читаемым текстом.
VD>>При этом то что ты предлагаешь — это нэйтив-длл-и для который еще придется писать обертки и реализовывать функциональность многоуровневости для хинтов (вряд ли она там есть по умолчанию). Так что объем работы получается внушительным, а выходы сомнительны. В общем, легаси код. Вот так вот быстро, оказывается, им можно обжиться .
CS>Мммм... а это вот Nabu.Forms.Html из http://code.google.com/p/nabu-library/ чем не устраивает-то? CS>Или вот это вот: http://code.google.com/p/expemerent/
А черт его знает. Я об их существовании только от тебя узнал. Причем в этот всем еще разобраться нужно.
VD>>К тому же для управляемого прилоежения наверно лучше будет использовать управляемый-аналог (например, предложенный здесь
). Но и с ним, думаю, придется повозиться.
CS>Это какое-то заблуждение у тебя. В ситуациях когда есть managed/non-managed код (а в UI это всегда так) CS>выигрывать будет решение у которого меньшее количество переходов (вызовов) managed -> non-managed код. CS>В случае с htmlayout ты оперируешь десятком вызовов высокоуровневых методов. Вместо потока вызовов CreateBrush, FillRect и пр.
Заблуждение скорее у тебя. Ты очень странно смотришь на выигрыш. Для меня выигрыш не упирается в быстродействие. Быстродействие, конечно, должно быть приемлемым. Но не более того. Кроме того очень важны такие аспекты, как устойчивость, легкость отладки и возможность модификации под свои нужды. Они у управляемого-решения с открытым кодом по любому лучше.
Собственно все пойманные проблемы с WPF-ным контролом были во круг интеропа. Окно студии ведь нэйтивное пока, а стло быть подключиться к нему можно только через перехват очереди окна. Ну, и там без ошибок не обошлось. А результат — вместо исключений переодически вся студия сворачивалась без единого звука. Хорошо что хоть интероп в дотнете написан так, что в присутствии отладчика он выполняет ряд расширенных проверок которые таки выявляют проблемы. Ну, а нэйтив баги без отладчика поймать будет очень сложно. Учитывая, что использование должно быть не очень стандартным (вложенные хинты я досего времени вообще нигде не видел), вероятность их вылезания весьма высока. Так что менеджед-код написанный на коленке может, по совокупности, причин оказаться более приемлемым.
CS>Каждый такой вызов как я понимаю чего-то да стоит.
Фигню он стоит. К тому же управляемое-решение рисует все через дотнетные интрфейсы. Интероп идет не при каждом вызове методов. Вместо этого сначала все вызовы записываются во внуренее представление, а потом накатываются (если я не ошибась). Так что там намного больше зависит от наличия акселерации отрисовки. Когда-то давно она была очень слабенькой для многих видюх. Как сейчас дела обстоят я не знаю. Но по любому для хнинта это не очень актуально. Он ведь весьма статический. Нарисовался и забылся.
Я тебе о другом говорю. Лично мне проще разобраться с менеджед решением, но даже за него браться не очень хочется, так как это время на изучение, на создание самого контрола. Ведь WPF-ное решение, хотя и не лишено недостатков, но он же ведь работает. И работает, в общем, приемлемо. Если бы у меня был штат программистов и много денег, я бы посадил по программисту за каждую альтернативу и приказал им написать по реализации хинта на каждом из API. Ну, а потом выбрал бы лучшего или просто сделал бы их сменяемыми (интерфейс ведь весьма прост).
Вот если бы кто нибудь (например, ты) помог бы реализовать альтернативную версию, то я с удовольствием подключил бы ее и опробовал. Но самому мне этим заниматься просто не когда. Моя основная задача — это доделать интеграцию немерла со студией. WPF-хнит написал один добрый человек (capgoat). Если бы не он, я бы еще очень долго не взялся бы за это дело. Зато теперь хинты в немерловой интеграции куруче паравоза. Отдыхают не только студия, но и разные РеШарперы.
Здравствуйте, VladD2, Вы писали:
CS>>Мда... студия и так не шеволится нонче... А тут ты еще со своим WPF... VD>Говорят VS 2010 beta 2 работает уже на уровне 2008-ой. Меня это устроило бы (правда верится в это с трудом).
Верится с трудом, но оно таки так и есть — по моему субъективному опыту. Пока что столкнулся только с одним обидным тормозом — окно Add reference почему-то очень медленно отрисовывает список сборок. В остальном Студия работает либо не медленнее, либо заметно быстрее.
CS>>Это какое-то заблуждение у тебя. В ситуациях когда есть managed/non-managed код (а в UI это всегда так) CS>>выигрывать будет решение у которого меньшее количество переходов (вызовов) managed -> non-managed код. CS>>В случае с htmlayout ты оперируешь десятком вызовов высокоуровневых методов. Вместо потока вызовов CreateBrush, FillRect и пр. CS>>Каждый такой вызов как я понимаю чего-то да стоит.
VD>Заблуждение скорее у тебя.
Согласен. В коде на WPF вообще не будет GDI-шных CreateBrush'ей и FillRect'ов. Там аппаратно ускоряемый DirectDraw.
VD>Ты очень странно смотришь на выигрыш. Для меня выигрыш не упирается в быстродействие. Быстродействие, конечно, должно быть приемлемым. Но не более того. Кроме того очень важны такие аспекты, как устойчивость, легкость отладки и возможность модификации под свои нужды. Они у управляемого-решения с открытым кодом по любому лучше.
В этом аспекте тоже согласен. Код на WPF легче писать/поддерживать, чем код на WinForms/WinApi.
Глаза у меня добрые, но рубашка — смирительная!
Re[4]: [WPF] Можно ли улучшить отображение шрифтов?
Вряд ли. Там предлагается не пользоваться XAML-ом. В хинте и так его почти нет (только базовая часть). А тормоза явно связаны с загрузкой PresentationFramework.Aero.dll.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
VD>Да это и не заявление в общем-то. Все кому надо об этом уже давно знают.
Спс. Про это в курсе. Но окромя UI в студии есть дофига и больше кода, не имеющего managed api — типа SCC, или работающего ч/з ком врапперы (shell, envDTE). Переписывание — очень много-много работы.
Что-то я сомневаюсь что в этом релизе они успеют
Re[6]: [WPF] Можно ли улучшить отображение шрифтов?
Здравствуйте, Sinix, Вы писали:
S>Спс. Про это в курсе. Но окромя UI в студии есть дофига и больше кода, не имеющего managed api — типа SCC, или работающего ч/з ком врапперы (shell, envDTE). Переписывание — очень много-много работы.
Я не говрил, что все переписано. Но IDE — это и есть на 90% UI. SCC это не так много кода и он далеко не всем нужен. Мне, например, не нужен.
S>Что-то я сомневаюсь что в этом релизе они успеют
Никто и не планировал все переписать. Переписан GUI включая редактор кода, тулбары и т.п. По крайней мере в 1-й бете так было.
Дерево проектов, насколько мене известно, осталось неуправляемым.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[7]: [WPF] Можно ли улучшить отображение шрифтов?
Здравствуйте, VladD2, Вы писали:
VD>Я не говрил, что все переписано.
Все равно следующая студия будет иметь на 90% управляемый-АПИ
Всё ясно, не так вас понял
VD>Но IDE — это и есть на 90% UI.
Повторюсь, UI — далеко не весь апи.
VD>SCC это не так много кода и он далеко не всем нужен. Мне, например, не нужен.
Мне тоже. Но вот перспектива "поменяем апи — проблемы у всех разработчиков дополнений" меня абсолютно не втыкает. Очевидно, не втыкает и VSX Team — в EnvDTE не так уж и много изменений.
P.S. А вообще надо уже собраться и поставить... время-время
Re[8]: [WPF] Можно ли улучшить отображение шрифтов?
Здравствуйте, Sinix, Вы писали:
S>Но вот перспектива "поменяем апи — проблемы у всех разработчиков дополнений" меня абсолютно не втыкает. Очевидно, не втыкает и VSX Team — в EnvDTE не так уж и много изменений.
На сколько я понимаю сап по себе API (как публичный интерфейс) пытаются сохранить для обеспечения совместимости с предыдущими вресиями. Но полной совместимости нет. Тот же ДжетБрэйнс довольно много сил тратит на интеграцию с новой версией.
К слову, в старом АПИ было попросту много не документированного. В новой оно становится документированным, но при этом полностью другим. Примером тому может служить АПИ по работе со смарт-тегами.
S>P.S. А вообще надо уже собраться и поставить... время-время
Согласен. Бэту 1 я поставил и посмотрел, а на вторую как-то времени не хватает. Старею, видимо .
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Можешь кстати на этот блог сам написать, это один из главных чуваков по VS performance (David Berg), его смотрят внимательно. Тебя даже больше слушать будут, чем если я изнутри жаловаться буду.
.
