The OpenNET Project / Index page

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



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

Оглавление

Оценка влияния оптимизаций в GNOME 46 на эффективность работы эмуляторов терминала, opennews (??), 08-Апр-24, (0) [смотреть все]

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


45. "Оценка влияния оптимизаций в GNOME 46 на эффективность работ..."  +/
Сообщение от анон (?), 08-Апр-24, 20:15 
А можно мне оконный менеджер, который будет рисовать не медленней, чем NT 4.0?(
Ответить | Правка | Наверх | Cообщить модератору

47. "Оценка влияния оптимизаций в GNOME 46 на эффективность работ..."  +/
Сообщение от Аноним (40), 08-Апр-24, 20:24 
Для этого надо графический интерфейс встроить прям в ядро, как в NT 4.0, тогда задержки на переключение контекста сн зятся до минимума и будет быстро
Ответить | Правка | Наверх | Cообщить модератору

55. "Оценка влияния оптимизаций в GNOME 46 на эффективность работ..."  +2 +/
Сообщение от Tita_M (ok), 08-Апр-24, 20:46 
Я вас уверяю, что это не так. Я в свое время когда-то давно загружал линукс с третьим КДЕ и ВЕСА драйвером на ноутбуке с коре дуо и джефорсом 9400, так вот ГУИ был ОЧЕНЬ И ОЧЕНЬ отзывчивым, такой же если не лучше чем у винды старых версий. Я до этого плевался на не отзывчивость ГУИ линуксов и я так же думал, что у линукса никогда не будет отзывчивого интерфейса из-за граф. сервера работающего в пространстве пользователя, но этот случай, а так же другой показал для меня, что тормоза ГУИ в линуксе это из-за ошибок и недоработках в граф. стеке, менеджере памяти и МТРР/ПАТ в ядре.
Ответить | Правка | Наверх | Cообщить модератору

58. "Оценка влияния оптимизаций в GNOME 46 на эффективность работ..."  +/
Сообщение от Аноним (40), 08-Апр-24, 21:22 
Ну сейчас переключение видеорежимов в ядре, стало лучше и быстрее
Ответить | Правка | Наверх | Cообщить модератору

80. "Оценка влияния оптимизаций в GNOME 46 на эффективность работ..."  +2 +/
Сообщение от Макар Чудра (?), 08-Апр-24, 22:41 
> на ноутбуке с коре дуо и джефорсом 9400

Тут многие и сейчас сидят на железе тех лет.

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

132. "Оценка влияния оптимизаций в GNOME 46 на эффективность работ..."  +/
Сообщение от Аноним (130), 09-Апр-24, 15:28 
Ничего себе железо. Этого типа должно не хвататть для отрисоски GUI?
Ответить | Правка | К родителю #55 | Наверх | Cообщить модератору

140. "Оценка влияния оптимизаций в GNOME 46 на эффективность работ..."  +/
Сообщение от Tita_M (ok), 09-Апр-24, 17:36 
И тем не менее, я видел отзывы людей у которых топовое современное железо, а ГУИ не отзывчивый и тормозной, что на интеле, что на амд, что на нвидии.
Дополнительно приведу ещё один мой пример: очень старый, проездом, двух ядерный нетбук с атомом вместо процессора, на котором федора толи 35, толи 36 с гномом хорошо работала - не было такого, чтобы скорость ГУИ вызывала отвращение.
Еще один пример: мой текущий компьютер с Атлоном 5350 и видеокартой RX550 и ГНУ/Линукс Минт толи 20.3, толи 21 версии - ГУИ отзывчивее на дискретной видеокарте, чем на встроенной. При этом на винде 10 разницы между ними нет.
Ответить | Правка | Наверх | Cообщить модератору

92. "Оценка влияния оптимизаций в GNOME 46 на эффективность работ..."  +/
Сообщение от cheburnator9000 (ok), 09-Апр-24, 00:52 
И сейчас можно сделать быстрый gui с рендерингом на vulkan/opengl, проблема в том что все новомодные графические вещи GTK4/QML просто обвешаны мегабайтами анимаций, шейдерами, тенями, сглаживанием и постпроцессингом. ImGui например очень быстрый.
Ответить | Правка | К родителю #47 | Наверх | Cообщить модератору

93. "Оценка влияния оптимизаций в GNOME 46 на эффективность работ..."  +/
Сообщение от Аноним (-), 09-Апр-24, 03:21 
> все новомодные графические вещи GTK4/QML просто обвешаны мегабайтами анимаций, шейдерами, тенями, сглаживанием и постпроцессингом.

vulkan/opengl легко могут крутить шейдерами мегабайты анимаций, рисовать тени, сглаживать, и выполнять постпроцессинг. Проблема с gtk/qt в том, что они были зачаты в ту эпоху, когда программисты мерялись тем, кто сможет развесистее иерархию классов запилить, а основным мерилом успешности было "повторное использование кода". Тогда они "повторное использование" понимали в том смысле, что если где-то строка кода написана, то лучше написать 100 строк кода абстракций, чтобы ту строку кода использовать из другого контекста, чем скопипастить эту строку кода в другой контекст.

Это ООП головного мозга, которое приводит к появлению в рантайме объектов, кустистость которых на порядок больше, чем кустистость иерархий классов, в результате банальная попытка обойти объект приводит к тому, что кеши начинают дымиться.

Есть известная мудрость: индайрекция может решить любую проблему программирования, кроме проблемы слишком большого количества уровней индайрекции. (Сорри за "индайрекция", я не знаю как её принято переводить на русский). gtk/qt следуя тому ООП из 90-х, накручивают уровни индайрекции десятилетиями. Это не сегодня началось, 20 лет назад я ковырялся в gtk, пытаясь понять как он работает, но там невозможно доковыряться до дна, лезешь вглубь через бесконечные уровни индайрекции, и к тому моменту когда находишь интересующий тебя кусок кода, ты уже не можешь вспомнить, как ты сюда попал и почему этот кусок кода тебе был интересен. Почему вообще gtk тебе был интересен.

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

95. "Оценка влияния оптимизаций в GNOME 46 на эффективность работ..."  +/
Сообщение от cheburnator9000 (ok), 09-Апр-24, 03:35 
Без ООП проблематично писать более менее вменяемый GUI. Golang биндинг к GTK4 что весь на кодогенерации сделан и там сам автор во многих местах затрудняется давать полные ответы как сделать работу с таблицей или более менее кастомизировать выпадающий список правильно, там везде выходит лапша по виду паскаля или баша, что в итоге у меня вызвало отрыжку. Примерно такие же проблемы и у GTKMM который находится только в режиме поддержки работы, но никак не развивается. Я лично жду carbon lang, но нутром чую что ждать придется еще лет 10. Я уже давно лично убедился что проблема С++ которая отворачивает от него разработчиков это необходимость писать header файлы.
Ответить | Правка | Наверх | Cообщить модератору

104. "Оценка влияния оптимизаций в GNOME 46 на эффективность работ..."  +3 +/
Сообщение от Макар Чудра (?), 09-Апр-24, 05:34 
> Я лично жду carbon lang

Только не забудь потом пожаловаться, что документации нет, сообщество маленькое и библиотек не хватает.

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

123. "Оценка влияния оптимизаций в GNOME 46 на эффективность работ..."  +/
Сообщение от Аноним (-), 09-Апр-24, 11:40 
> Без ООП проблематично писать более менее вменяемый GUI.

Если под ООП понимать развесистую иерархию классов, то нет, нет никаких проблем писать вменяемый гуй без развесистых иерархий. Если же, допустим, использование интерфейсов называть "ООП", то тогда да, без таких штук сложно обойтись.

> Golang биндинг к GTK4
> GTKMM

Бинды по-любому выносят наружу всю сложность низлежащего ООП. И они никак не помогают производительности, потому что идиотские структуры данных ООП кода никуда не деваются.

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

129. "Оценка влияния оптимизаций в GNOME 46 на эффективность работ..."  +/
Сообщение от Аноним (-), 09-Апр-24, 13:49 
> Я лично жду carbon lang, но нутром чую что ждать придется еще лет 10.

Я бы не ждал)
Т.к carbon-lang#project-status
Carbon Language is currently an experimental project. There is no working compiler or toolchain.
Это конечно исправимо (время + деньги), но в данный момент ситуация такова.

А если глянуть их README.md на github com/carbon-language/carbon-lang
Existing modern languages already provide an excellent developer experience: Go, Swift, Kotlin, Rust, and many more. Developers that can use one of these existing languages should.

Т.е создатели карбона сами советуют использовать другие языки где можно, а вот где совсем "не можна" - то там использовать его.


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

54. "Оценка влияния оптимизаций в GNOME 46 на эффективность работ..."  +1 +/
Сообщение от Аноним (52), 08-Апр-24, 20:45 
icewm
Ответить | Правка | К родителю #45 | Наверх | Cообщить модератору

102. "Оценка влияния оптимизаций в GNOME 46 на эффективность работ..."  –1 +/
Сообщение от Макар Чудра (?), 09-Апр-24, 05:09 
> icewm

Когда у тебя калькулятор мощнее, чем комп, но ты все равно хочешь оконный менеджер.

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

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

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




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

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