Здравствуйте, Аноним, Вы писали:
А>Здравствуйте, kamre, Вы писали:
А>Папрашу претензии озвучить!! Так жаба устроена, что не ясно-то? Хочется мало памяти потреблять? У меня 4Гб. 1,5 и даже 2,5 я спокойно могу отдать очень важной и нужной программе. А у Вас 128Мб на машине? Хочется чтобы в QT было так же удобно работать как и в жабе? Или что?
а для нормального ресайза 3-Way SLI что ли использовать предлагаете?
Решил сравнить Swing и Qt в плане отрисовки окошек на небольшом примере из Qt Examples. Набросал аналогичный код на Java (см. ниже) и получилось у меня вот так:
Сразу же возникает вопрос: почему шрифт в JTextArea какой-то не правильный?
Но самое интересное, что при ресайзе этих окошек Qt все делает просто моментально и плавно, а в Java почему-то все происходит рывками и с заметным шлейфом от перерисовки рамки окна. Вопрос: что же я делаю не так? Или это вообще свойственно для Swing тормозить подобным образом даже для таких простых окошек?
Также глянул на вкладку Performance в Process Explorer для каждого из процессов:
Особенно заметна разница в потреблении памяти — java использует почти в 10 раз больше! Больше 100Мб для окошка, растянутого почти на весь экран, это нормально для Swing? Неужели действительно такая большая разница? Наверняка я что-то делаю не правильно...
Вот мой код на Java:
import static java.awt.GridBagConstraints.BOTH;
import static java.awt.GridBagConstraints.CENTER;
import static java.awt.GridBagConstraints.HORIZONTAL;
import static java.awt.GridBagConstraints.NONE;
import java.awt.Component;
import java.awt.Container;
import java.awt.Dimension;
import java.awt.GridBagConstraints;
import java.awt.GridBagLayout;
import java.awt.Insets;
import java.awt.event.ActionEvent;
import java.awt.event.KeyEvent;
import javax.swing.AbstractAction;
import javax.swing.Box;
import javax.swing.GroupLayout;
import javax.swing.JButton;
import javax.swing.JComboBox;
import javax.swing.JFrame;
import javax.swing.JLabel;
import javax.swing.JMenu;
import javax.swing.JMenuBar;
import javax.swing.JMenuItem;
import javax.swing.JPanel;
import javax.swing.JScrollPane;
import javax.swing.JSpinner;
import javax.swing.JTextArea;
import javax.swing.JTextField;
import javax.swing.SwingUtilities;
import javax.swing.UIManager;
import javax.swing.GroupLayout.ParallelGroup;
import javax.swing.GroupLayout.SequentialGroup;
import javax.swing.border.CompoundBorder;
import javax.swing.border.EmptyBorder;
import javax.swing.border.TitledBorder;
@SuppressWarnings("serial")
public class BasicLayouts extends JFrame {
public BasicLayouts() {
super("Basic layouts");
// create components of window
createMenuBar();
Container horizontalLayout = createHorizontalGroupBox();
Container gridLayout = createGridLayout();
Container formLayout = createFormLayout();
Container textArea = createTextArea();
Container dialogButtons = createDialogButtons();
// set group layout to content pane
Container contentPane = getContentPane();
GroupLayout mainLayout = new GroupLayout(contentPane);
contentPane.setLayout(mainLayout);
mainLayout.setAutoCreateContainerGaps(true);
mainLayout.setAutoCreateGaps(true);
// add components of window to group layout
mainLayout.setHorizontalGroup(mainLayout.createParallelGroup()
.addComponent(horizontalLayout).addComponent(gridLayout).addComponent(
formLayout).addComponent(textArea).addComponent(dialogButtons));
mainLayout.setVerticalGroup(mainLayout.createSequentialGroup()
.addComponent(horizontalLayout).addComponent(gridLayout).addComponent(
formLayout).addComponent(textArea).addComponent(dialogButtons));
//
setDefaultCloseOperation(EXIT_ON_CLOSE);
pack();
setMinimumSize(getSize());
setVisible(true);
}
private void createMenuBar() {
JMenuBar menuBar = new JMenuBar();
JMenu fileMenu = new JMenu("File");
fileMenu.setMnemonic(KeyEvent.VK_F);
JMenuItem exitItem = new JMenuItem(new AbstractAction() {
{
putValue(NAME, "Exit");
putValue(MNEMONIC_KEY, KeyEvent.VK_X);
}
@Override
public void actionPerformed(ActionEvent e) {
System.exit(0);
}
});
fileMenu.add(exitItem);
menuBar.add(fileMenu);
setJMenuBar(menuBar);
}
private Container createHorizontalGroupBox() {
JPanel panel = new JPanel();
GroupLayout groupLayout = new GroupLayout(panel);
groupLayout.setAutoCreateGaps(true);
final int nButtons = 4;
SequentialGroup horizontalGroup = groupLayout.createSequentialGroup();
ParallelGroup verticalGroup = groupLayout.createParallelGroup();
for (int i = 1; i <= nButtons; i++) {
JButton button = new JButton("Button " + i);
horizontalGroup.addComponent(button, GroupLayout.DEFAULT_SIZE,
GroupLayout.DEFAULT_SIZE, Short.MAX_VALUE);
verticalGroup.addComponent(button);
}
groupLayout.setHorizontalGroup(horizontalGroup);
groupLayout.setVerticalGroup(verticalGroup);
panel.setLayout(groupLayout);
Insets insets = new Insets(2, 2, 2, 2);
panel.setBorder(new CompoundBorder(new TitledBorder("Horizontal layout"),
new EmptyBorder(insets)));
return panel;
}
private Container createGridLayout() {
JPanel panel = new JPanel();
panel.setLayout(new GridBagLayout());
JLabel label1st = new JLabel("Line 1:");
JLabel label2nd = new JLabel("Line 2:");
JLabel label3rd = new JLabel("Line 3:");
JTextField textField1st = new JTextField();
JTextField textField2nd = new JTextField();
JTextField textField3rd = new JTextField();
JTextArea textArea = new JTextArea(
"This widget takes up about two thirds of the grid layout.");
textArea.setLineWrap(true);
textArea.setWrapStyleWord(true);
JScrollPane scrollPane = new JScrollPane(textArea);
Insets insets = new Insets(2, 2, 2, 2);
panel.setBorder(new CompoundBorder(new TitledBorder("Grid layout"),
new EmptyBorder(insets)));
Component glue = Box.createGlue();
panel.add(glue, new GridBagConstraints(0, 0, 2, 1, 0.5, 1.0, CENTER, BOTH,
insets, 0, 0));
panel.add(label1st, new GridBagConstraints(0, 1, 1, 1, 0.0, 0.0, CENTER,
NONE, insets, 0, 0));
panel.add(label2nd, new GridBagConstraints(0, 2, 1, 1, 0.0, 0.0, CENTER,
NONE, insets, 0, 0));
panel.add(label3rd, new GridBagConstraints(0, 3, 1, 1, 0.0, 0.0, CENTER,
NONE, insets, 0, 0));
panel.add(textField1st, new GridBagConstraints(1, 1, 1, 1, 0.5, 0.0,
CENTER, HORIZONTAL, insets, 0, 0));
panel.add(textField2nd, new GridBagConstraints(1, 2, 1, 1, 0.5, 0.0,
CENTER, HORIZONTAL, insets, 0, 0));
panel.add(textField3rd, new GridBagConstraints(1, 3, 1, 1, 0.5, 0.0,
CENTER, HORIZONTAL, insets, 0, 0));
panel.add(scrollPane, new GridBagConstraints(2, 0, 1, 4, 1.0, 1.0, CENTER,
BOTH, insets, 0, 0));
Dimension zeroSize = new Dimension(0,
textField1st.getPreferredSize().height);
textField1st.setPreferredSize(zeroSize);
textField2nd.setPreferredSize(zeroSize);
textField3rd.setPreferredSize(zeroSize);
scrollPane.setPreferredSize(zeroSize);
return panel;
}
private Container createFormLayout() {
JPanel panel = new JPanel();
GroupLayout groupLayout = new GroupLayout(panel);
groupLayout.setAutoCreateGaps(true);
JLabel label1st = new JLabel("Line 1:");
JLabel label2nd = new JLabel("Line 2, long text:");
JLabel label3rd = new JLabel("Line 3:");
JTextField textField = new JTextField();
JComboBox comboBox = new JComboBox();
JSpinner spinner = new JSpinner();
groupLayout.setHorizontalGroup(groupLayout.createSequentialGroup()
.addGroup(
groupLayout.createParallelGroup().addComponent(label1st)
.addComponent(label2nd).addComponent(label3rd)).addGroup(
groupLayout.createParallelGroup().addComponent(textField)
.addComponent(comboBox).addComponent(spinner)));
groupLayout.setVerticalGroup(groupLayout.createSequentialGroup().addGroup(
groupLayout.createParallelGroup(GroupLayout.Alignment.BASELINE)
.addComponent(label1st).addComponent(textField)).addGroup(
groupLayout.createParallelGroup(GroupLayout.Alignment.BASELINE)
.addComponent(label2nd).addComponent(comboBox,
GroupLayout.DEFAULT_SIZE, GroupLayout.PREFERRED_SIZE,
GroupLayout.PREFERRED_SIZE)).addGroup(
groupLayout.createParallelGroup(GroupLayout.Alignment.BASELINE)
.addComponent(label3rd).addComponent(spinner)));
panel.setLayout(groupLayout);
Insets insets = new Insets(2, 2, 2, 2);
panel.setBorder(new CompoundBorder(new TitledBorder("Form layout"),
new EmptyBorder(insets)));
return panel;
}
private Container createTextArea() {
JTextArea textArea = new JTextArea(
"This widget takes up all the remaining space "
+ "in the top-level layout.");
textArea.setLineWrap(true);
textArea.setRows(4);
return new JScrollPane(textArea);
}
private Container createDialogButtons() {
JPanel panel = new JPanel();
JButton ok = new JButton("OK");
JButton cancel = new JButton("Cancel");
GroupLayout groupLayout = new GroupLayout(panel);
groupLayout.setAutoCreateGaps(true);
groupLayout.setHorizontalGroup(groupLayout.createSequentialGroup().addGap(
0, 0, Short.MAX_VALUE).addComponent(ok).addComponent(cancel));
groupLayout.setVerticalGroup(groupLayout.createParallelGroup()
.addComponent(ok).addComponent(cancel));
groupLayout.linkSize(ok, cancel);
panel.setLayout(groupLayout);
return panel;
}
public static void main(String[] args) {
try {
UIManager.setLookAndFeel(UIManager.getSystemLookAndFeelClassName());
} catch (Exception e) {
e.printStackTrace();
}
SwingUtilities.invokeLater(new Runnable() {
public void run() {
new BasicLayouts();
}
});
}
}
Здравствуйте, kamre, Вы писали:
C>>А если -Xmx ещё покрутить? K>Да с "-Xmx16m" уже за 70Мб не вылезает "Peak Working Set".
Тогда это какие-то проблемы с внутренностями JDK. Оно куда-то съедает где-то 30Мб.
Можно попробовать ещё отключить двойную буфферизацию.
K>С моей видеокартой по умолчанию включается d3d pipeline.
Похоже как раз из-за этого. Он для всех виджетов делает backing store, а он занимает немало места.
Здравствуйте, denis.zhdanov, Вы писали:
DZ>Здравствуйте, ., Вы писали:
.>>Если я ничего не путаю, то магическое число 100мб — дефолтный размер кучи. И gc начинает свои грязные дела, когда объекты перестают помещаться. .>>Т.е. оно доходит до 100мб в процессе работы и больше не растёт (конечно, если прога больше не просит и утечек памяти нет).
DZ>64 по дефолту
не, там уже сложнее (see Automatic Selection of Collector, Heap Sizes, and Virtual Machine)
правда это не объясняет проблем топик кастера у меня, правда, на его примере меньше — так что думаю таки l&f неклассичный подкачал.
Re: Java Swing по сравнению с Qt
От:
Аноним
Дата:
27.01.09 17:59
Оценка:
Здравствуйте, kamre, Вы писали:
Папрашу претензии озвучить!! Так жаба устроена, что не ясно-то? Хочется мало памяти потреблять? У меня 4Гб. 1,5 и даже 2,5 я спокойно могу отдать очень важной и нужной программе. А у Вас 128Мб на машине? Хочется чтобы в QT было так же удобно работать как и в жабе? Или что?
Здравствуйте, LeonidV, Вы писали:
LV>Здравствуйте, http://dolzhenko.blogspot.com/, Вы писали: HDB>>нет, C++ Qt приложение съело памяти ~10M, Jambi ~37M, Swing ~34M, ни о каких 100М даже и речи быть не может LV>Видать в Windows все может быть. Не понимаю людей, которые по доброй воле на нем сидят.
А я не понимаю людей, которые по доброй воле сидят на линуксе, с его тормозной 2D графикой, корявым рендерингом шрифтов и не возможностью использовать Alt+Shift для переключения раскладки клавиатуры Да и эта тема не для холивара вин-лин...
Здравствуйте, kamre, Вы писали:
K>Решил сравнить Swing и Qt в плане отрисовки окошек на небольшом примере из Qt Examples. Набросал аналогичный код на Java (см. ниже) и получилось у меня вот так:
Какая версия JVM? K>Сразу же возникает вопрос: почему шрифт в JTextArea какой-то не правильный?
В Java давно проблема со шрифтами, так как отрисовка своя собственная даже шрифтов. http://rsdn.ru/forum/message/1580305.1.aspx
K>Но самое интересное, что при ресайзе этих окошек Qt все делает просто моментально и плавно, а в Java почему-то все происходит рывками и с заметным шлейфом от перерисовки рамки окна. Вопрос: что же я делаю не так? Или это вообще свойственно для Swing тормозить подобным образом даже для таких простых окошек?
Там достаточно длинная цепочка вызовов Layout manager. К тому же в client JVM она скорее всего долгое время интерпретируется пока до JIT дело не дойдет.
K>Особенно заметна разница в потреблении памяти — java использует почти в 10 раз больше! Больше 100Мб для окошка, растянутого почти на весь экран, это нормально для Swing? Неужели действительно такая большая разница? Наверняка я что-то делаю не правильно...
JVM не ограничивается одним Swing. Это достаточно толстая такая прослойка в целом.
И, да. UI в Java как хромал так и хромает, хотя уже много делается для того чтобы это исправить. QT, конечно же более выигрышно смотрится.
Для Java кроме Swing существуют и другие решения.
Так вроде бы уже с 1.6.10 отрисовка делается через системные вызовы? Да и на скриншотах видно, что cleartype в java "правильный".
B>Там достаточно длинная цепочка вызовов Layout manager. К тому же в client JVM она скорее всего долгое время интерпретируется пока до JIT дело не дойдет.
Т.е. именно поэтому приложения на Swing тормозят подобным образом? И это никак не исправить?
K>>Особенно заметна разница в потреблении памяти — java использует почти в 10 раз больше! Больше 100Мб для окошка, растянутого почти на весь экран, это нормально для Swing? Неужели действительно такая большая разница? Наверняка я что-то делаю не правильно... B>JVM не ограничивается одним Swing. Это достаточно толстая такая прослойка в целом.
Ну не в 10 же раз... И это еще по сравнению с Qt, которая тащит свои достаточно толстые runtime библиотеки. Изначально при старте Java приложение занимает где-то под 30Мб (как раз весь рантайм нужный загрузился), но зачем оно потом до 100Мб отжирает?
B>И, да. UI в Java как хромал так и хромает, хотя уже много делается для того чтобы это исправить. QT, конечно же более выигрышно смотрится. B>Для Java кроме Swing существуют и другие решения.
Swing и Qt весьма похожи в том, что все компоненты рисуют сами с нуля, а не пользуются системными. Но как-то у Qt это заметно лучше получается: гораздо быстрее и отличий меньше от системного LAF.
Т.е. с кодом на Java у меня более или менее все в порядке и положение уже не улучшить?
K>Так вроде бы уже с 1.6.10 отрисовка делается через системные вызовы? Да и на скриншотах видно, что cleartype в java "правильный".
Можно ссылочку? Я такого не помню.
Здесь только несколько фиксов связаных с рендерингом, которые дают повод для сомнений в нативном рендеринге: http://java.sun.com/javase/6/webnotes/6u10.html
B>>Там достаточно длинная цепочка вызовов Layout manager. К тому же в client JVM она скорее всего долгое время интерпретируется пока до JIT дело не дойдет. K>Т.е. именно поэтому приложения на Swing тормозят подобным образом? И это никак не исправить?
Почему-же. Можно поиграться с настройками JVM. mixed mode, client mode и ключи для JIT.
Можно даже профайлер запустить и посмотреть, вдруг это лечится.
K>Ну не в 10 же раз... И это еще по сравнению с Qt, которая тащит свои достаточно толстые runtime библиотеки. Изначально при старте Java приложение занимает где-то под 30Мб (как раз весь рантайм нужный загрузился), но зачем оно потом до 100Мб отжирает?
И все же JVM не Qt, а Qt не JVM. Поэтому данное сравнение не совсем корректно. А ещё GC. Можно попробовать ограничить размер хипа через -Xmx. Хотя ни к чему хорошему это не приведет. Опять же особо любознательные могут запустить профайлер.
K>Swing и Qt весьма похожи в том, что все компоненты рисуют сами с нуля, а не пользуются системными. Но как-то у Qt это заметно лучше получается: гораздо быстрее и отличий меньше от системного LAF.
Именно поэтому Qt на столько популярен, а Swing совсем нет.
K>Т.е. с кодом на Java у меня более или менее все в порядке и положение уже не улучшить?
На вскидку никаких видимых проблем не обнаружено.
Всё таки — вы сравниваете C++ Qt vs Java Swing...
Java кушает память — да, Свинг удобен своей MVC, после использования его коммерческие гриды для .net кажутся странным произведением...
после кодинга на C++ программы на Java кажуться обжорами и медленными...
B>>В Java давно проблема со шрифтами, так как отрисовка своя собственная даже шрифтов. B>>http://rsdn.ru/forum/message/1580305.1.aspx
K>Так вроде бы уже с 1.6.10 отрисовка делается через системные вызовы? Да и на скриншотах видно, что cleartype в java "правильный".
Поиграйтесь со следующими параметрами http://java.sun.com/j2se/1.5.0/docs/guide/2d/flags.html
Здравствуйте, Blazkowicz, Вы писали:
B>>>В Java давно проблема со шрифтами, так как отрисовка своя собственная даже шрифтов. B>>>http://rsdn.ru/forum/message/1580305.1.aspx
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 совсем нет.
Да, похоже на то...
Re[4]: Java Swing по сравнению с Qt
От:
Аноним
Дата:
26.01.09 17:13
Оценка:
Здравствуйте, zubr, Вы писали:
Z>Всё таки — вы сравниваете C++ Qt vs Java Swing...
Ну да, а что не так в этом сравнении? К тому же есть и Qt Jambi...
Z>Java кушает память — да, Свинг удобен своей MVC, после использования его коммерческие гриды для .net кажутся странным произведением... Z>после кодинга на C++ программы на Java кажуться обжорами и медленными...
А что, 100Мб на такое простое окошко разве не обжорство? И такие жуткие тормоза при ресайзе окна разве нормально?
Здравствуйте, kamre, Вы писали:
K>Сразу же возникает вопрос: почему шрифт в JTextArea какой-то не правильный?
Был заинтригован. В Windows L&F прописан monospaced PLAIN 12, который выглядит как надо. Вероятно он наследовался от JScrollPane, удаление которого решило проблему.
Здравствуйте, Blazkowicz, Вы писали:
B>Здравствуйте, Аноним, Вы писали:
Анонимом я оказался, с другого компа отправлял и что-то с логином перепутал...
А>>И такие жуткие тормоза при ресайзе окна разве нормально? B>Дай бинарник — сравнить.
По сравнению со Swing resize у Qt просто идеальный для этого примера.
Еще заметил, что зависит от темы винды: если выставить у тему Classic, то и Swing начинает нормально работать.
Здравствуйте, kamre, Вы писали:
K>Бинарник для Qt? Вот сюда залил: http://ifolder.ru/10236262 Еще может понадобиться Microsoft Visual C++ 2008 SP1 Redistributable Package, т.к. Qt собрана с помощью MSVC 2008 Express.
K>По сравнению со Swing resize у Qt просто идеальный для этого примера. K>Еще заметил, что зависит от темы винды: если выставить у тему Classic, то и Swing начинает нормально работать.
Никакой особой разницы не заметил на обеих темах. Единственное что у меня LCD матрица довольно тормозная.
Здравствуйте, Blazkowicz, Вы писали:
B>Здравствуйте, kamre, Вы писали:
K>>По сравнению со Swing resize у Qt просто идеальный для этого примера. K>>Еще заметил, что зависит от темы винды: если выставить у тему Classic, то и Swing начинает нормально работать. B>Никакой особой разницы не заметил на обеих темах. Единственное что у меня LCD матрица довольно тормозная.
Ну а разница то между Qt и Swing хорошо заметна?
У меня на Athlon XP 2500+, NVidia 7600GS разница очень заметна. Swing вообще вот так себя ведет:
и нормально отрисовывать окно успевает только когда я мышку останавливаю.
Re[5]: Java Swing по сравнению с Qt
От:
Аноним
Дата:
26.01.09 19:08
Оценка:
Здравствуйте, Аноним, Вы писали:
А>Здравствуйте, zubr, Вы писали:
Z>>Всё таки — вы сравниваете C++ Qt vs Java Swing... А>Ну да, а что не так в этом сравнении? К тому же есть и Qt Jambi...
был бы вообще шоколад сравнить C++ Qt vs Java Swing vs Java Qt Jambi
Z>>Java кушает память — да, Свинг удобен своей MVC, после использования его коммерческие гриды для .net кажутся странным произведением... Z>>после кодинга на C++ программы на Java кажуться обжорами и медленными... А>А что, 100Мб на такое простое окошко разве не обжорство? И такие жуткие тормоза при ресайзе окна разве нормально?
Аноним 788 wrote:
> А что, 100Мб на такое простое окошко разве не обжорство?
Если я ничего не путаю, то магическое число 100мб — дефолтный размер кучи. И gc начинает свои грязные дела, когда объекты перестают помещаться.
Т.е. оно доходит до 100мб в процессе работы и больше не растёт (конечно, если прога больше не просит и утечек памяти нет).
Posted via RSDN NNTP Server 2.1 beta
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ., Вы писали:
.>Если я ничего не путаю, то магическое число 100мб — дефолтный размер кучи. И gc начинает свои грязные дела, когда объекты перестают помещаться. .>Т.е. оно доходит до 100мб в процессе работы и больше не растёт (конечно, если прога больше не просит и утечек памяти нет).
Здравствуйте, kamre, Вы писали:
K>Особенно заметна разница в потреблении памяти — java использует почти в 10 раз больше! Больше 100Мб для окошка, растянутого почти на весь экран, это нормально для Swing? Неужели действительно такая большая разница? Наверняка я что-то делаю не правильно...
Покрути настройки JVM. Даже могу подсказать магическую строку, которую мы используем:
"-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 так, что он будет отдавать свободную память назад системе.
Для такого просто примера можно поменять параметр -Xms32m (минимальный размер кучи) на что-нибудь типа "-Xmx16m".
Вообще, сам по себе SWING не занимает много места в памяти. У нас достаточно сложное приложение со сложными окошками и контролами занимает где-то 12Мб кучи (по данным JConsole). Но у JVM достаточно большие минимальные фиксированные расходы на JIT-компиляцию и всякие свои внутренние дела, так что минимальный размер всей программы получается где-то около 40Мб.
PS: а сейчас стоит посмотреть ещё на QT Jambi — это QT binding для Java. Ооооочень достойная вещь, да ещё и скоро бесплатно будет (в марте).
Здравствуйте, kamre, Вы писали:
K>Ну а разница то между Qt и Swing хорошо заметна?
Нет.
K>У меня на Athlon XP 2500+, NVidia 7600GS разница очень заметна. Swing вообще вот так себя ведет: K>http://pic.ipicture.ru/uploads/090126/6Q2ZV2ETDR.png K>и нормально отрисовывать окно успевает только когда я мышку останавливаю.
Core 2 Duo 2.60GHz, встроенное видео — Intel G965. Подобных эффектов не наблюдаю.
Здравствуйте, 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.
Re[3]: Java Swing по сравнению с Qt
От:
Аноним
Дата:
27.01.09 12:43
Оценка:
K>Это другой LAF (substance?), в нем шрифты свои выставляются. А на Windows LAF именно такой корявый шрифт в JTextArea (завернутый в JScrollPane):
это так в суне решили (типа улучшили) начиная с 5 версии. Как вернуть написано выше
S>>относительно размеров — меряется память для всей виртуальной машины. А она будет большая даже если хеловорльд запускать.
K>Да понятно, что всей виртуальной машины... Просто больше 100Мб на подобном окошке (растянутом почти на весь экран 1680х1050) это как-то уже слишком...
ну тут какбе ничего не сделать. Таков принцип работы виртуальных машин и автосборщика мусора.
Посмотрел демку 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 не тормозит
Здравствуйте, http://dolzhenko.blogspot.com/, Вы писали: HDB>нет, C++ Qt приложение съело памяти ~10M, Jambi ~37M, Swing ~34M, ни о каких 100М даже и речи быть не может
Видать в Windows все может быть. Не понимаю людей, которые по доброй воле на нем сидят.
Здравствуйте, Аноним, Вы писали:
А>Та нет жеж! Я предлагаю выбирать инструмент адекватно задачам. Если задача уместить GUI в минимальный объем памяти и моментально ресайзить окошко даже на дохлом P 166, то выбор — QT. И нечего в этом случае напрягать Swing. А если есть Core 2 Duo, то ЛИЧНО у меня ресайз даже без 3way SLI не тормозит
Здравствуйте, berdachuk, Вы писали:
B>Если вас так беспокоит отрисовка в Swing, то попробуйте SWT библиотеку, особых тормозов не наблюдается, хоть и бывают иногда проблемы. B>Там используется нативный код операционной системы. B>Ну, а по памяти, то нынче это не столь критично, нужен то конечный результат.
А что в SWT есть в качестве замены Java2D для отрисовки векторной графики? swt.graphics как-то не дотягивает по функционалу. И как оно по скорости при работе с swt.graphics.Path и swt.graphics.Transform в сравнении с java.awt.Graphics2D? SWT_AWT вроде бы слишком тормозной, чтобы пользоваться java.awt.Graphics2D из SWT...
Здравствуйте, kamre, Вы писали:
K>А что в SWT есть в качестве замены Java2D для отрисовки векторной графики? swt.graphics как-то не дотягивает по функционалу. И как оно по скорости при работе с swt.graphics.Path и swt.graphics.Transform в сравнении с java.awt.Graphics2D? SWT_AWT вроде бы слишком тормозной, чтобы пользоваться java.awt.Graphics2D из SWT...
Поиск по сайту в дауне. Поэтому копирую из аськи.
Orc, 14:54:16:
Вобщем способ прост, наследуемся от Composit и переопределяем свою void onPaint(GC gc) все
Orc, 14:55:01:
Т.е. как и в WIN32 API, перехват WM_PAINT типа
Orc, 14:56:05:
Т.е. конкретно переопределяешь слушателя:
addPaintListener(new PaintListener() {
public void paintControl(PaintEvent event) {
onPaint(event.gc);
}
});
А дальше все что угодно
Orc, 14:58:09:
Согласен, что может быть сложно. Но для меня, как для сишника и хорошо знающего WIN API, GTK и прочее, зная их узкие места — этот способ выходит проще, чем SWING
Здравствуйте, kamre, Вы писали:
K>А что в SWT есть в качестве замены Java2D для отрисовки векторной графики? swt.graphics как-то не дотягивает по функционалу. И как оно по скорости при работе с swt.graphics.Path и swt.graphics.Transform в сравнении с java.awt.Graphics2D? SWT_AWT вроде бы слишком тормозной, чтобы пользоваться java.awt.Graphics2D из SWT...
Стоит так же отметить такой Framework как GEF. Тоже какое никакое 2D, хотя как он внутрях до него достаёт я не знаю.
Здравствуйте, Blazkowicz, Вы писали:
B>Поиск по сайту в дауне. Поэтому копирую из аськи.
B>
B>Orc, 14:54:16:
B>Вобщем способ прост, наследуемся от Composit и переопределяем свою void onPaint(GC gc) все
B>Orc, 14:55:01:
B>Т.е. как и в WIN32 API, перехват WM_PAINT типа
B>Orc, 14:56:05:
B>Т.е. конкретно переопределяешь слушателя:
B> addPaintListener(new PaintListener() {
B> public void paintControl(PaintEvent event) {
B> onPaint(event.gc);
B> }
B> });
B>А дальше все что угодно
B>Orc, 14:58:09:
B>Согласен, что может быть сложно. Но для меня, как для сишника и хорошо знающего WIN API, GTK и прочее, зная их узкие места — этот способ выходит проще, чем SWING
Нет, это все не то Меня интересует именно API для отрисовки векторной графики. У Qt есть Arthur, у Java — Java2D, у SWT — org.eclipse.swt.graphics. Все функции с int координатами из swt.graphics меня вообще не инетерсуют, а тогда остается только GC, Path и Transformation...
Здравствуйте, kamre, Вы писали:
K>Нет, это все не то Меня интересует именно API для отрисовки векторной графики. У Qt есть Arthur, у Java — Java2D, у SWT — org.eclipse.swt.graphics. Все функции с int координатами из swt.graphics меня вообще не инетерсуют, а тогда остается только GC, Path и Transformation...
Никогда не думал что Java2D на столько ориентирован на векторную графику.
Здравствуйте, kamre, Вы писали:
K>А я не понимаю людей, которые по доброй воле сидят на линуксе, с его тормозной 2D графикой, корявым рендерингом шрифтов и не возможностью использовать Alt+Shift для переключения раскладки клавиатуры Да и эта тема не для холивара вин-лин...
Здравствуйте, kamre, Вы писали:
K>А я не понимаю людей, которые по доброй воле сидят на линуксе, с его тормозной 2D графикой, корявым рендерингом шрифтов и не возможностью использовать Alt+Shift для переключения раскладки клавиатуры Да и эта тема не для холивара вин-лин...
А я не понимаю людей, которые по доброй воле не знают, что в Линуксе этих проблем давно уже нет.
Здравствуйте, Blazkowicz, Вы писали:
K>>Нет, это все не то Меня интересует именно API для отрисовки векторной графики. У Qt есть Arthur, у Java — Java2D, у SWT — org.eclipse.swt.graphics. Все функции с int координатами из swt.graphics меня вообще не инетерсуют, а тогда остается только GC, Path и Transformation...
B>Никогда не думал что Java2D на столько ориентирован на векторную графику.
А о существовании класса java.awt.Graphics2D вы догадывались? А то вот swt.graphics (без Path/Transformation) — это как раз на уровне старого java.awt.Graphics, где все рисуется по координатам пикселей. А Java2D может рисовать с субпиксельной точностью (в double координатах) и с antialiasing.
Здравствуйте, Cyberax, Вы писали:
K>>А я не понимаю людей, которые по доброй воле сидят на линуксе, с его тормозной 2D графикой, корявым рендерингом шрифтов и не возможностью использовать Alt+Shift для переключения раскладки клавиатуры Да и эта тема не для холивара вин-лин... C>А я не понимаю людей, которые по доброй воле не знают, что в Линуксе этих проблем давно уже нет.
Не холивора ради, а для прояснения спорных моментов предлагаю продолжить вот в этой теме
Здравствуйте, kamre, Вы писали:
K>А о существовании класса java.awt.Graphics2D вы догадывались? А то вот swt.graphics (без Path/Transformation) — это как раз на уровне старого java.awt.Graphics, где все рисуется по координатам пикселей.
Просто не находил там ничего особо полезного. Shape and Affine Transform не считаю чем-то особо сложным. Реализация много времени не отымет.
K>А Java2D может рисовать с субпиксельной точностью (в double координатах) и с antialiasing.
Круто. Вот этого не знал.
