Здравствуйте, Blazkowicz, Вы писали:
K>>Сразу же возникает вопрос: почему шрифт в JTextArea какой-то не правильный? B>Был заинтригован. В Windows L&F прописан monospaced PLAIN 12, который выглядит как надо. Вероятно он наследовался от JScrollPane, удаление которого решило проблему.
... сегодня опять мелкий шрифт вернулся. мистика.
Здравствуйте, Blazkowicz, Вы писали:
K>>Ну а разница то между Qt и Swing хорошо заметна? B>Нет.
Вру. В Swing шрифты немного замылены — Java 6 update 10. Может 11й поставить...
Здравствуйте, sss1024, Вы писали:
S>всё нормально там со шрифтами S>просто зачем-то настройки меняют от версии к версии, приходится руками выставлять.
В Windows L&F прописан правильный шрифт. Почему по-умолчанию рендерится другой — загадка.
Re[3]: Java Swing по сравнению с Qt
От:
Аноним
Дата:
27.01.09 10:41
Оценка:
Здравствуйте, Blazkowicz, Вы писали:
B>Здравствуйте, sss1024, Вы писали:
S>>всё нормально там со шрифтами S>>просто зачем-то настройки меняют от версии к версии, приходится руками выставлять. B>В Windows L&F прописан правильный шрифт. Почему по-умолчанию рендерится другой — загадка.
Здравствуйте, Cyberax, Вы писали:
C>Покрути настройки JVM. Даже могу подсказать магическую строку, которую мы используем: C>"-Xms32m -Xmx132m -XX:MinHeapFreeRatio=20 -XX:MaxHeapFreeRatio=30 -XX:NewSize=5m -XX:MaxNewSize=5m -XX:SurvivorRatio=6 -XX:TargetSurvivorRatio=80 -XX:-UseConcMarkSweepGC -XX:-CMSIncrementalMode". Эта строчка для оптимизации расхода памяти, кроме того, она настраивает GC так, что он будет отдавать свободную память назад системе. C>Для такого просто примера можно поменять параметр -Xms32m (минимальный размер кучи) на что-нибудь типа "-Xmx16m".
Никак практически не повлияла магическая строчка.
C>Вообще, сам по себе SWING не занимает много места в памяти. У нас достаточно сложное приложение со сложными окошками и контролами занимает где-то 12Мб кучи (по данным JConsole). Но у JVM достаточно большие минимальные фиксированные расходы на JIT-компиляцию и всякие свои внутренние дела, так что минимальный размер всей программы получается где-то около 40Мб.
Где же они фиксированные в данном случае? При старте занимает где-то 30Мб, вот это как раз и есть то, что положено расходовать JVM. Но при дальнейших действиях с окном (resize/maximize/...) расход памяти больше 100Мб получается. Все это именно для Windows LAF (c стандартной темой Windows XP Blue/Silver/Olive). На Metal LAF такого отжирания не происходит.
Здравствуйте, kamre, Вы писали:
C>>Для такого просто примера можно поменять параметр -Xms32m (минимальный размер кучи) на что-нибудь типа "-Xmx16m". K>Никак практически не повлияла магическая строчка.
А если -Xmx ещё покрутить?
K>Где же они фиксированные в данном случае? При старте занимает где-то 30Мб, вот это как раз и есть то, что положено расходовать JVM. Но при дальнейших действиях с окном (resize/maximize/...) расход памяти больше 100Мб получается. Все это именно для Windows LAF (c стандартной темой Windows XP Blue/Silver/Olive). На Metal LAF такого отжирания не происходит.
Странно. Я такого не вижу. А какая JVM?
Здравствуйте, sss1024, Вы писали:
S>всё нормально там со шрифтами
S>http://molgav.nn.ru/surikov/images/txed.jpg
S>просто зачем-то настройки меняют от версии к версии, приходится руками выставлять. Тоже касается прорисовки окон при перемещении.
Это другой LAF (substance?), в нем шрифты свои выставляются. А на Windows LAF именно такой корявый шрифт в JTextArea (завернутый в JScrollPane):
S>относительно размеров — меряется память для всей виртуальной машины. А она будет большая даже если хеловорльд запускать.
Да понятно, что всей виртуальной машины... Просто больше 100Мб на подобном окошке (растянутом почти на весь экран 1680х1050) это как-то уже слишком...
Видать вот эта секция работает не всегда правильно.
if (useSystemFontSettings) {
MenuFont = getDesktopFontValue("win.menu.font", MenuFont, toolkit);
FixedControlFont = getDesktopFontValue("win.ansiFixed.font",
FixedControlFont, toolkit);
ControlFont = getDesktopFontValue("win.defaultGUI.font",
ControlFont, toolkit);
MessageFont = getDesktopFontValue("win.messagebox.font",
MessageFont, toolkit);
WindowFont = getDesktopFontValue("win.frame.captionFont",
WindowFont, toolkit);
IconFont = getDesktopFontValue("win.icon.font",
IconFont, toolkit);
ToolTipFont = getDesktopFontValue("win.tooltip.font", ToolTipFont,
toolkit);
/* Put the desktop AA settings in the defaults.
* JComponent.setUI() retrieves this and makes it available
* as a client property on the JComponent. Use the same key name
* for both client property and UIDefaults.
* Also need to set up listeners for changes in these settings.
*/
Object aaTextInfo = SwingUtilities2.AATextInfo.getAATextInfo(true);
table.put(SwingUtilities2.AA_TEXT_PROPERTY_KEY, aaTextInfo);
this.aaSettings =
new FontDesktopProperty(SunToolkit.DESKTOPFONTHINTS);
}
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, kamre, Вы писали:
C>>>Для такого просто примера можно поменять параметр -Xms32m (минимальный размер кучи) на что-нибудь типа "-Xmx16m". K>>Никак практически не повлияла магическая строчка. C>А если -Xmx ещё покрутить?
Да с "-Xmx16m" уже за 70Мб не вылезает "Peak Working Set".
K>>Где же они фиксированные в данном случае? При старте занимает где-то 30Мб, вот это как раз и есть то, что положено расходовать JVM. Но при дальнейших действиях с окном (resize/maximize/...) расход памяти больше 100Мб получается. Все это именно для Windows LAF (c стандартной темой Windows XP Blue/Silver/Olive). На Metal LAF такого отжирания не происходит. C>Странно. Я такого не вижу. А какая JVM?
java version "1.6.0_11"
Java(TM) SE Runtime Environment (build 1.6.0_11-b03)
Java HotSpot(TM) Client VM (build 11.0-b16, mixed mode, sharing)
С моей видеокартой по умолчанию включается d3d pipeline.
Здравствуйте, kamre, Вы писали:
C>>А если -Xmx ещё покрутить? K>Да с "-Xmx16m" уже за 70Мб не вылезает "Peak Working Set".
Тогда это какие-то проблемы с внутренностями JDK. Оно куда-то съедает где-то 30Мб.
Можно попробовать ещё отключить двойную буфферизацию.
K>С моей видеокартой по умолчанию включается d3d pipeline.
Похоже как раз из-за этого. Он для всех виджетов делает backing store, а он занимает немало места.
Sapienti sat!
Re[3]: Java Swing по сравнению с Qt
От:
Аноним
Дата:
27.01.09 12:43
Оценка:
K>Это другой LAF (substance?), в нем шрифты свои выставляются. А на Windows LAF именно такой корявый шрифт в JTextArea (завернутый в JScrollPane):
это так в суне решили (типа улучшили) начиная с 5 версии. Как вернуть написано выше
S>>относительно размеров — меряется память для всей виртуальной машины. А она будет большая даже если хеловорльд запускать.
K>Да понятно, что всей виртуальной машины... Просто больше 100Мб на подобном окошке (растянутом почти на весь экран 1680х1050) это как-то уже слишком...
ну тут какбе ничего не сделать. Таков принцип работы виртуальных машин и автосборщика мусора.
Re: Java Swing по сравнению с Qt
От:
Аноним
Дата:
27.01.09 17:59
Оценка:
Здравствуйте, kamre, Вы писали:
Папрашу претензии озвучить!! Так жаба устроена, что не ясно-то? Хочется мало памяти потреблять? У меня 4Гб. 1,5 и даже 2,5 я спокойно могу отдать очень важной и нужной программе. А у Вас 128Мб на машине? Хочется чтобы в QT было так же удобно работать как и в жабе? Или что?
Здравствуйте, Аноним, Вы писали:
А>Здравствуйте, kamre, Вы писали:
А>Папрашу претензии озвучить!! Так жаба устроена, что не ясно-то? Хочется мало памяти потреблять? У меня 4Гб. 1,5 и даже 2,5 я спокойно могу отдать очень важной и нужной программе. А у Вас 128Мб на машине? Хочется чтобы в QT было так же удобно работать как и в жабе? Или что?
а для нормального ресайза 3-Way SLI что ли использовать предлагаете?
Посмотрел демку QT на java — очень интересная тема.
Кто нибудь использовал уже в своей работе на java данную технологию? Вообще скорость работы сразу видна. Хотя в принципе для бизнес приложений она не является каким либо ограничением — там же все тормоза связаны с работой логики.
Re[2]: Java Swing по сравнению с Qt
От:
Аноним
Дата:
28.01.09 08:09
Оценка:
Здравствуйте, dmitry., Вы писали:
D>Посмотрел демку QT на java — очень интересная тема. D>Кто нибудь использовал уже в своей работе на java данную технологию? Вообще скорость работы сразу видна. Хотя в принципе для бизнес приложений она не является каким либо ограничением — там же все тормоза связаны с работой логики.
сравнил поведение схожих приложений на C++ Qt ( код примера basic layouts ) , Java Swing (код приведён автором ветки), и basic layouts перенесённый на Java Qt Jambi.
Каких-либо заметных глазу отличий между приложением на C++ Qt и Java Qt Jambi нет (скорость перерисовки, resize и т.п всё одинаково на сколько могу сравнивать на глаз), Java Swing приложение на Sun JDK 1.6.0_11, на всякий случай запускал с волшебной строкой
сранивать сколько съедают приложения C++/Java не корректно по многим соображениям — и как определить shared память, которую съедают qt библиотеки и т.п
по расходу памяти приложения на Jambi и Swing — примерно одинаково (37M / 34M соот-но)
Если вас так беспокоит отрисовка в Swing, то попробуйте SWT библиотеку, особых тормозов не наблюдается, хоть и бывают иногда проблемы.
Там используется нативный код операционной системы.
Ну, а по памяти, то нынче это не столь критично, нужен то конечный результат.
Здравствуйте, http://dolzhenko.blogspot.com/, Вы писали:
HDB>сравнил поведение схожих приложений на C++ Qt ( код примера basic layouts ) , Java Swing (код приведён автором ветки), и basic layouts перенесённый на Java Qt Jambi. HDB>Каких-либо заметных глазу отличий между приложением на C++ Qt и Java Qt Jambi нет (скорость перерисовки, resize и т.п всё одинаково на сколько могу сравнивать на глаз), ... HDB>по сравнению с Qt отличия есть в стиле отрисовки (ожидаемо), проблем с resize, перетаскиванием окна не замечено.
HDB>os: gentoo gnu/linux HDB>gcc 4.3.2 HDB>qt 4.4.2 HDB>java sun jdk 1.6.0_11 HDB>qt jambi 4.4.3
Так а Look And Feel то какой у Java/Swing? Если Metal (Ocean), то и у меня нет к нему претензий. Основные проблемы именно под Windows LAF с Windows XP темой (не Classic). Ну или с Substance LAF — такие же проблемы.
HDB>сранивать сколько съедают приложения C++/Java не корректно по многим соображениям — и как определить shared память, которую съедают qt библиотеки и т.п HDB>по расходу памяти приложения на Jambi и Swing — примерно одинаково (37M / 34M соот-но)
Определить shared память легко:
Да и сравнивать вполне можно с учетом на overhead для jvm в размере 20-30Мб. Это было бы вполне приемлемо. А вот отжирание больше 100Мб (на нетривиальном LAF) как-то очень не хорошо смотрится...
Здравствуйте, kamre, Вы писали:
K>Так а Look And Feel то какой у Java/Swing? Если Metal (Ocean), то и у меня нет к нему претензий. Основные проблемы именно под Windows LAF с Windows XP темой (не Classic). Ну или с Substance LAF — такие же проблемы.
с Substance LAF чуть-чуть (самую малость) медленее resize из большого размера в маленькое (больше тормозов не замечено). Памяти съедает ~45M
Windows LAF и Windows XP не могу проверить
K>Определить shared память легко: K>
это у тебя венда — я же написал os: gentoo gnu/linux K>Да и сравнивать вполне можно с учетом на overhead для jvm в размере 20-30Мб. Это было бы вполне приемлемо. А вот отжирание больше 100Мб (на нетривиальном LAF) как-то очень не хорошо смотрится...
нет, C++ Qt приложение съело памяти ~10M, Jambi ~37M, Swing ~34M, ни о каких 100М даже и речи быть не может
Re[3]: Java Swing по сравнению с Qt
От:
Аноним
Дата:
28.01.09 18:01
Оценка:
Здравствуйте, thevery, Вы писали:
T>Здравствуйте, Аноним, Вы писали:
А>>Здравствуйте, kamre, Вы писали:
А>>Папрашу претензии озвучить!! Так жаба устроена, что не ясно-то? Хочется мало памяти потреблять? У меня 4Гб. 1,5 и даже 2,5 я спокойно могу отдать очень важной и нужной программе. А у Вас 128Мб на машине? Хочется чтобы в QT было так же удобно работать как и в жабе? Или что?
T>а для нормального ресайза 3-Way SLI что ли использовать предлагаете?
Та нет жеж! Я предлагаю выбирать инструмент адекватно задачам. Если задача уместить GUI в минимальный объем памяти и моментально ресайзить окошко даже на дохлом P 166, то выбор — QT. И нечего в этом случае напрягать Swing. А если есть Core 2 Duo, то ЛИЧНО у меня ресайз даже без 3way SLI не тормозит
