LINUX.ORG.RU
ФорумTalks

gtk за глобальное потепление!

 ,


0

3

Возьмём такой обычный файловый менеджер как spacefm. На самом деле, тред вовсе не про ФМ, а про ФГМ разработчиков тулкита, но надо ж на ком-то ставить опыты.

Так вот. Открываем в нём две панели. И пробуем мышкой или хоткеем переключать фокус ввода между этими панелями.

2.5-гигагерцового процессора не хватает чтобы мгновенно обновить картинку в окне и поставить курсор с одной панели на другую. Реально не хватает. Между нажатием мыши и перерисовкой окна проходит ощутимая задержка, примерно в 1/3..1/2 секунды. Разница отчетливо заметна, если попробовать просто потыкать мышкой в пункты одной и той же панели: в этом случае всё происходит действительно мгновенно.

Те же самые инновационные технологии можно наблюдать и в tuxcmd, например. И вообще где угодно, где используются стандартные компоненты ListView или TreeView. Не обязательно даже переключаться между двумя TreeView, сойдёт и переключение между TreeView и строкой адреса, например. Тормоза те же самые.

Теперь запустим этот же spacefm с gtkparasite, включим показ обновлений окна и таки да, убедимся, что творится полное говно: при потере или получении фокуса TreeView перерисовывается весь полностью. Вернее, в данном случае перерисовываются аккурат два TreeView.

Ночь. Улица. Фонарь. Аптека. Развернутый на весь экран файловый менеджер. Процессор, судодорожно перемалывающий десятки мегабайт битмапов, чтобы в конечном счёте пользователь увидел перемещение маленькой синенькой рамочки из одного угла в другой. Идиотизм.

Да и черт бы с ним, если бы он перерисовывался полностью, но быстро. Но зачем же так дико тупить?

Кстати, чтобы улучшить климат на планете, gtk еще и перерисовывает все виджеты при входе/выходе мыши в их границы. Даже если они ни в малейшей степени не нуждаются в перерисовке. То есть понятно: это всё ради возможности ставить темы оформления на тулкит, универсальный подход и все такое. Не понятно только, почему универсальный подход всегда получается через жопу.

А теперь о вещах, которые реализованы правильно:

andromeda — первый попавшийся под руку ФМ на Qt, чтоб проверить как аналог TreeView работает в Qt. Отлично работает, никаких лагов.

gnome-commander. Эти ребята реализовали собственный виджет для панелей, и поэтому тоже не участвуют по всемирном движении за повышение температуры атмосферы.

Ну и total commander в винде, разумеется. Но об этом нельзя говорить вслух, ведь все же знают, что распрекрасный линукс рулит, а винда и все приложени для неё — сосут.

★★

Последнее исправление: geekless (всего исправлений: 2)

а я юзаю mc который зачастую перерисовывает всю консоль

Deleted
()

А давайте все виджеты рисовать в текстурки на видеокарте и просто натягивать их на треугольники на экране.

PolarFox ★★★★★
()

Заплакал.

Deleted
()
Ответ на: комментарий от GateKeeper

Десктоп на кисточках от недофотошопа! Welcome to bright future!

// Кстати, фотошоп же вроде использует собственный тулкит, а не стандартные контроллы винды. И почему-то я уверен, что там всё сделано правильным образом...

geekless ★★
() автор топика
Ответ на: комментарий от PolarFox

давно мечтаю об этом :)

только сначала этот тулкит от блендера оторвать надо

Stil ★★★★★
()

Из-за этого его перестал использовать. Тормоза ужасные. Такое ощущение что сами разработчики пользуются чем-то другим, и это относится не только к spacefm(оно вроде на gtk3 переползает, не?).

ritsufag ★★★★★
()

Ну так России выгодно глобальное потепление: вечная мерзлота спадёт и больше территории для комфортного проживания, правда насчёт поднявшегося уровня мирового океана неизвестно, и про беженцев с прибрежных государств :)

zaramoth
()

В gtk-devel-list@ время от времени возникает вопрос про оптимизацию дерева, но пока воз и ныне там.

akk ★★★★★
()

Собственно, оно:

static gint
gtk_tree_view_focus_out (GtkWidget     *widget,
			 GdkEventFocus *event)
{
  GtkTreeView *tree_view;

  tree_view = GTK_TREE_VIEW (widget);

  gtk_widget_queue_draw (widget);

  /* destroy interactive search dialog */
  if (tree_view->priv->search_window)
    gtk_tree_view_search_dialog_hide (tree_view->priv->search_window, tree_view);

  return FALSE;
}



static void
gtk_tree_view_state_changed (GtkWidget      *widget,
		 	     GtkStateType    previous_state)
{
  GtkTreeView *tree_view = GTK_TREE_VIEW (widget);

  if (gtk_widget_get_realized (widget))
    {
      gdk_window_set_back_pixmap (widget->window, NULL, FALSE);
      gdk_window_set_background (tree_view->priv->bin_window, &widget->style->base[widget->state]);
    }

  gtk_widget_queue_draw (widget);
}

А про то, через какие дали выполняется сама перерисовка, лучше вообще не вспоминать...

geekless ★★
() автор топика

да много что еще тормозит

ибо от красноглазия все

kto_tama ★★★★★
()
Ответ на: комментарий от cruxish

А смысл? Тут патч только постить надо. И то даю не больше 10% вероятности, что его бы приняли в gtk3 и не больше 1% — в gtk2.

geekless ★★
() автор топика

Реально не хватает. Между нажатием мыши и перерисовкой окна проходит ощутимая задержка, примерно в 1/3..1/2 секунды. Разница отчетливо заметна, если попробовать просто потыкать мышкой в пункты одной и той же панели: в этом случае всё происходит действительно мгновенно.

Проверил, не повторяется. Решил по другому проверить, открыл top, потом в spacefm зажал tab - задержки никакой не наблюдаю (за секунду фокус переходит между деревом и обоими списками раз 10-15), но процессор действительно до 90% поднимается.

NVIDIA, GTK+ 2.24.13.

cruxish ★★★★
()
Ответ на: комментарий от vasily_pupkin

Кайра тут ни при чем. Это само гэтэка так отжигает.

geekless ★★
() автор топика
Ответ на: комментарий от geekless

А смысл?

Напомнить о баге. Хуже не будет точно.

cruxish ★★★★
()

gtktreeview ужасно — более тормозного и бажного компонента gtk трудно найти (вместе со всеми его cellrenderers). его собственная тормознутость и кривость умножается на тормознутость cairo, pango, и отсутствие времени на оптимизацию у разработчиков. странно что никто еще не сделал альтернативный tree/list view, в рамках какого-нибудь libegg.

waker ★★★★★
()
Ответ на: комментарий от geekless

Но интерфей начинает тормозить, когда пускаешь на видеокарту нагрузку.

Subsanek
()

первый попавшийся под руку ФМ на Qt, чтоб проверить как аналог TreeView работает в Qt. Отлично работает, никаких лагов.

Зато у меня в дельфине значки «танцуют», если окно максимизировать (ну или обратно): сначала выстраиваются моментально в новое расположение, потом через полсекунды ещё раз перемещаются на новое местоположение. Хотя в дельфине, кажется, как раз собственная отрисовка значков, не стандартная Qt'шная

kss ★★★★★
()
Ответ на: комментарий от geekless

Кстати, фотошоп же вроде использует собственный тулкит, а не стандартные контроллы винды. И почему-то я уверен, что там всё сделано правильным образом...

Вот поэтому Седжвик ездит на БМВ, а разработчики гимпа на корейских драндулетах :3

Кстати, кто не в курсе:

1. 	gimp
	
(1) a derrogatory term for someone that is disabled or has a medicial problem that results in physical impairment.

(2) An insult implying that someone is incompetent, stupid, etc. Can also be used to imply that the person is uncool or can't/won't do what everyone else is doing.

(3) A sex slave or submissive, usually male, as popularlized by the movie Pulp Fiction.

http://www.urbandictionary.com/define.php?term=gimp

Чего вы хотите-то от него? :3

Ok
()

Даже для меня, былого фанатика gtk, сабж RIP. Оно все хуже и больше тормозит.

Присоединяюсь к советам о E17, Elementary (их тулкит) был довольно быстр, когда я его дергал в свое время. Только вот сырое оно все и свистопердящее.

buddhist ★★★★★
()
Ответ на: комментарий от geekless

Нет подходящего приложения.

Будь мужиком - напиши

annulen ★★★★★
()
Ответ на: комментарий от PolarFox

Если бы они рисовали их так, оно бы как раз не тормозило :-)

KivApple ★★★★★
()
Ответ на: комментарий от akk

Many of the ideas below address shortcomings in GtkTreeView, unfortunately, often long-standing shortcomings. Resolving these shortcomings requires time, time that I unfortunately did not have available in the last few years.

Мда, печально.

geekless ★★
() автор топика

Так вот. Открываем в нём две панели. И пробуем мышкой или хоткеем переключать фокус ввода между этими панелями.

Директория с 10К файлами, 2.0Ghz процессор, всё работает идеально

derlafff ★★★★★
()
Ответ на: комментарий от derlafff

А вот в при создании в этой директории еще 100000-10000 файлов он начал тупить зверски, лол.

При этом в Thunar всё нормально, так что spacefm-проблемы

derlafff ★★★★★
()
Ответ на: комментарий от derlafff

Директория с 10К файлами, 2.0Ghz процессор, всё работает идеально

Я где-то говорил, что есть зависимость от числа файлов?

geekless ★★
() автор топика
Ответ на: комментарий от geekless

Нет. Но у меня просто так не тормозило, я решил небольную нагрузку создать

derlafff ★★★★★
()
Ответ на: комментарий от Subsanek

Мне казалось в таких делах нужно на видеокарту смотреть, а не процессор.

Если отрисовка неоптимально, то тут не видеокарта и не процессор, а программист виноват.

alman ★★★
()
Ответ на: комментарий от geekless

Ок. Тогда скажи, доктор, что советуешь - Qt, мак, венду? Или только вдоль? Я серьезно.

ArtKun ★★★★★
()
Последнее исправление: ArtKun (всего исправлений: 1)

А чего, собственно, ждать от людей, которые вывод gcc смотрят в консоли через less (вместо среды, которая сама сопоставит ошибки и строки исходного кода), у них на профайлер банально времени не хватит. Плюс заблуждение, что производительность на простейших или искуственных задачах будет равна производительности на реальных.

Тем временем эвристику распределения памяти в драйверах 15 лет подгоняли под игры, а игры - под драйвера. И сейчас хорошая игра с отсечением лишних вершин кучей способов, кешированием и LOD уделает гткашное дерево по скорости несмотря на наличие в 100 раз большего количества графики.

quiet_readonly ★★★★
()

Всё правильно, gtk дерьмецо, а qt - прекрасен.

И теперь понятно, почему в кедах тормозит в первую очередь gtk софт.

Не понятно только, почему универсальный подход всегда получается через жопу.

Жопа же универсальный интерфейс, который используется при универсальном подходе. Т.е. через жопу можно делать всё, кроме кушать.

ekzotech ★★★★
()
Ответ на: комментарий от thunar

эти времена прошли, теперь он Gonome ToolKit со всемы вытекающими

1. Опечатка забавная, теряюсь в догадках - ты лишнюю букву написал, или одну недописал?

2. «со всеми вытекающими» - да! Трижды да! Наследственность еще никому не удавалось победить, тем более просто сменой имени.

GateKeeper ★★
()
Ответ на: комментарий от sergej

Сам факт перерисовывания всего окна является багом реализации (если не архитектуры). Независимо от производительности темы.

Тема Clearlooks, кстати.

geekless ★★
() автор топика
Ответ на: комментарий от geekless

Открой Synaptic Package Manager (если используешь), наведи мышь на разделитель «окон», нажми LMB и интенсивно поперемещай разделитель не отпуская LMB.

Понаблюдай на загрузку ЦПУ.

Тоже самое (загрузка ЦПУ) происходит и с Thunar-ом.

Boboms ★★
()
Ответ на: комментарий от waker

странно что никто еще не сделал альтернативный tree/list view, в рамках какого-нибудь libegg.

Зачем, его же в 3.8 вообще выпилили вроде.

jackill ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.