The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы [ Отслеживать ]

Оглавление

Выпуск почтового клиента Geary 3.34, opennews (??), 22-Сен-19, (0) [смотреть все]

Сообщения [Сортировка по времени | RSS]


20. "Выпуск почтового клиента Geary 3.34"  +2 +/
Сообщение от Аноним (10), 22-Сен-19, 22:30 
Конечно, заниматься этим я не собирался.

Разобрался что это за функция - оказалось, тарам-там-там (!!!), у них есть свой криво-написанный CSS джижок (очень маленькое подмножество), только стилизует не HTML (div, a, IMG), а их виджеты (как раз на фотках тени, скругления и т.п.).

И вот у них там квадратичный алгоритм (!) добавления элементов в этом движке. После 100 элементов уже начинает тормозить.

Я переписал на O(N*log N) - стало в 800 раз быстрее. 100 000 элементов отрисовывал за 0.1 секунду кажется.

Ответить | Правка | К родителю #13 | Наверх | Cообщить модератору

28. "ссылка"  +1 +/
Сообщение от big dick (?), 23-Сен-19, 08:17 
Ссылку на патч, пожалуйста.
Ответить | Правка | Наверх | Cообщить модератору

31. "ссылка"  +2 +/
Сообщение от Аноним (10), 23-Сен-19, 11:01 
Вы правда думаете, что я полезу искать эти никому ненужные наработки только чтобы доказать что-то на форуме с 1.5 калеки?

Если бы от этого что-то изменилось, я бы потратил время и нашёл этот патч.

Я с ними общался напрямую в IRC. ISSUES месяцами висят. Патч они даже не стали смотреть. Поэтому и до создания формального issue дело не дошло.

Потом главный разработчик этого CSS (кажется Matias Clasen) движка перестал отвечать на вопросы, чтобы помочь разобраться с их движком. Видимо, начал ревновать что я полез в их код.

Вы что, типа хотите уличить во лжи?))) Но тут столько подробностей, что проверить несложно.

Ответить | Правка | Наверх | Cообщить модератору

32. "ссылка"  +/
Сообщение от Аноним (10), 23-Сен-19, 11:12 
Вот здесь https://gitlab.gnome.org/GNOME/gtk/blob/master/gtk/gtkcssnode.c
используется связный список.

У вас 1000 элементов. Чтобы добавить элемент в середину, вы пробегаете (начиная с начала) половину списка. И так для всей 1000 элементов. Вот и квадратичный алгоритм.


А надо вместо связного списка https://developer.gnome.org/glib/stable/glib-Doubly-Linked-L... использовать дерево https://developer.gnome.org/glib/stable/glib-Balanced-Binary....
Вот именно это я и сделал.

Ответить | Правка | К родителю #28 | Наверх | Cообщить модератору

38. "ссылка"  –1 +/
Сообщение от big dick (?), 23-Сен-19, 13:41 
Просто интересно.

Я не шарю в асимптотическом анализе алгоритмов, но твой довод выглядит здорово.

Кстати, ты реально думаешь, что рендеринг одновременно 10к item-ов - это хорошая идея? Я думаю именно из-за этого они и не стали отвечать, боясь получить ответ, заведомо стрёмный.

А вообще не разбираюсь в программировании на gtk, и было интересно тебя почитать.

Ответить | Правка | Наверх | Cообщить модератору

40. "ссылка"  +/
Сообщение от Аноним (10), 23-Сен-19, 14:10 
Я выше написал комментарии по отрисовку 10к элементов. Почитай, будет интересно)

По производительности: отрисовка и 10к, и 100к, и даже 1млн на чистом С - это копеечные операции. Ну секунду, ну максимум 10 секунд должно занимать.

Более того, я всех деталей не помню. Но! кажется я предложил им добавить такую поддержку (отрисовку только того, что видно на экране) в GtkFlowBox, притом я сам готов был это сделать, т.к. для меня это был блокер. И...они отказались)))
Лезть в CSS движок - это крайняя мера, от безысходности. Я потратил уже 3 месяца на разработку. И боролся за проект до последнего. Но такое наплевательское отношение во всём. Я же там столкнулся ещё с десятком проблем. Например, они даже не умеют изменять размер виджетов - слайдера.

По поводу правильно ли это: вообще, сначала пишется приложение, его каркас. Ведь это всё время и деньги. Я не могу заниматься такими мелочами в самом начале. А уже потом идёт более детальная оптимизация.

Я ведь не вручную отрисовываю эти элементы. Я кладу их в абстрактный контейнер, который отвечает за отрисовку https://developer.gnome.org/gtk3/stable/GtkFlowBox.html.

И рендерить только то, что попадает на экран - это оптимизация, её можно написать потом, попозже. Более того, это должен поддерживать стандартный GtkFlowBox - это абсолютно базовая и критичная функциональность. С ней столкнется любой, кто отрисовывает длинный список / дерево.

В React Native есть FlatList который рендерит только то, что попадает на экран. И это идёт из коробки.

Ответить | Правка | Наверх | Cообщить модератору

41. "ссылка"  +/
Сообщение от big dick (?), 23-Сен-19, 14:25 
> По производительности: отрисовка и 10к, и 100к, и даже 1млн на чистом С - это копеечные операции. Ну секунду, ну максимум 10 секунд должно занимать.

Грубая неправда. Как я понимаю, даже код на С использует API библиотек, которые рисуют эти 100500 элементов. И эта библиотека не может, ни в каком случае, нарисовать столько элементов быстро.

> В React Native есть FlatList который рендерит только то, что попадает на экран. И это идёт из коробки.

chunking and lazy loading, так победим.

Если серьёзно - что за проект? Pet, за деньги?

Ответить | Правка | Наверх | Cообщить модератору

42. "ссылка"  +1 +/
Сообщение от Аноним (10), 23-Сен-19, 14:48 
Ну как не может? У меня смогла нарисовать, а у них не может? Вы тред читали?

Отрисовка занимает очень мало время даже 100 000 элементов, даже миллиона. Библиотеки отрисовки (это Cairo) вообще этого не замечают. Проблема исключительно в GTK, в их CSS движке.

Ответить | Правка | Наверх | Cообщить модератору

43. "ссылка"  +1 +/
Сообщение от Аноним (10), 23-Сен-19, 14:51 
Свой проект, коммерческий (планировался). Фотоменеджер с искусственным интеллектом а-ля Google Photos.
Ответить | Правка | К родителю #41 | Наверх | Cообщить модератору

53. "ссылка"  +/
Сообщение от VICTOR MALOVemail (?), 23-Сен-19, 17:21 
Вот ссылки на скриншоты профилировщика.
https://drive.google.com/open?id=16ccqcSSdr4p1LYmItqThAOjtEo...

Прошу прощения, я ошибся. Я улучшил производительность конкретного use-case не в 800 раз, а в 6750 раз - с 82 секунд до 0.012 секунд (функция gtk_box_update_child_css_position). А если бы эти клоуны мне помогли, то я бы улучшил и gtk_css_node_propogate_pending_changes.

И тогда бы общая производительность выросла бы в эти самые 6750 раз. С 333 секунд до 0.05 секунд для отрисовки 100 000 элементов.

И Gnome Nautilus тоже перестал бы тормозить =)))

Ответить | Правка | К родителю #41 | Наверх | Cообщить модератору

58. "ссылка"  +/
Сообщение от Фанат ГТК (?), 23-Сен-19, 22:58 
Они серьезно для поиска и формирования набора стилей элемента используют связанный список? Это как-то... Странно! Маразматически странно, хотя алгоритм с деревом среднестатистического разработчика поставит на некоторое время в тупик, но это же основа, которой пользуются сотни тысячи человек. Теперь понятно, в чем основная проблема этого тулкита -- неграмотные люди у руля, понятно, почему шапка продалась...
Ответить | Правка | К родителю #32 | Наверх | Cообщить модератору

59. "ссылка"  +/
Сообщение от Аноним (10), 24-Сен-19, 00:56 
Я сам был шокирован. Как это возможно, им же пользуются сотни тысяч людей?

И люди-то неглупые. Никто в мире не напишет сразу оптимальный CSS движок. И я написал бы не лучше с первого раза. Я думаю большинство его вообще не сможет написать.

Короче, очень токсичное сообщество. Худшее, что я встречал.

И создали они HTML5, только очень плохой ;) Тот же CSS. UI описывается через XML:) Код логики пишется через биндинги на JavaScript или Python

Ответить | Правка | Наверх | Cообщить модератору

60. "ссылка"  +/
Сообщение от Аноним (10), 24-Сен-19, 00:59 
Маразматически - что им это написали, объяснили почему алгоритм квадратичный. Написали патч (потратив кучу времени). Проверили профилировщиком до и после для доказательства.

А они...просто блин в чате мне перестали отвечать)) Поднадоел я им, наверное. Вот это трэш)

Ответить | Правка | К родителю #58 | Наверх | Cообщить модератору

57. "ссылка"  +/
Сообщение от VICTOR MALOVemail (?), 23-Сен-19, 17:33 
https://github.com/likern/gtk-patched/tree/custom-flowbox
Ответить | Правка | К родителю #28 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру