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

B>>>В Java давно проблема со шрифтами, так как отрисовка своя собственная даже шрифтов.
B>>>http://rsdn.ru/forum/message/1580305.1.aspx

Автор: Blazkowicz
Дата: 10.01.06

K>>Так вроде бы уже с 1.6.10 отрисовка делается через системные вызовы? Да и на скриншотах видно, что cleartype в java "правильный".
B>Можно ссылочку? Я такого не помню.
B>Здесь только несколько фиксов связаных с рендерингом, которые дают повод для сомнений в нативном рендеринге:
B>http://java.sun.com/javase/6/webnotes/6u10.html
Так как раз по этой ссылке и написано: "6656651 Windows Look and Feel LCD glyph images have some differences from native applications." И теперь в NetBeans и в IDEA (Windows LAF) шрифт выглядит не хуже, чем в Eclipse.

B>>>Там достаточно длинная цепочка вызовов Layout manager. К тому же в client JVM она скорее всего долгое время интерпретируется пока до JIT дело не дойдет.
K>>Т.е. именно поэтому приложения на Swing тормозят подобным образом? И это никак не исправить?
B>Почему-же. Можно поиграться с настройками JVM. mixed mode, client mode и ключи для JIT.
B>Можно даже профайлер запустить и посмотреть, вдруг это лечится.
Неужели рассчет Layout такой ресурсоемкий? Что-то не очень верится. Да и с Metal LAF меньше томозит, хотя пересчет Layout такой же должен быть. И вообще, если еще и

JFrame.setDefaultLookAndFeelDecorated(true);

сделать в начале main, то уже довольно быстро работает с Metal LAF. И кстати объем испольуемой памяти для Metal LAF не растет, так в пределах 35Мб где-то и остается все при изменении размеров окна.

K>>Ну не в 10 же раз... И это еще по сравнению с Qt, которая тащит свои достаточно толстые runtime библиотеки. Изначально при старте Java приложение занимает где-то под 30Мб (как раз весь рантайм нужный загрузился), но зачем оно потом до 100Мб отжирает?
B>И все же JVM не Qt, а Qt не JVM. Поэтому данное сравнение не совсем корректно. А ещё GC. Можно попробовать ограничить размер хипа через -Xmx. Хотя ни к чему хорошему это не приведет. Опять же особо любознательные могут запустить профайлер.
Почему не корректное? Сравниваем отрисовку внутри окна средствами Qt и средствами Swing/Java2D. На остальные не используемые в данный момент части JRE должен быть константный overhead.
Хотя запустить профайлер — интересная идея. Но почему тогда программисты из SUN не запускали профайлер? Или они посчитали, что это нормальное использование памяти?

K>>Swing и Qt весьма похожи в том, что все компоненты рисуют сами с нуля, а не пользуются системными. Но как-то у Qt это заметно лучше получается: гораздо быстрее и отличий меньше от системного LAF.
B>Именно поэтому Qt на столько популярен, а Swing совсем нет.
Да, похоже на то...