The OpenNET Project / Index page

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



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

Оглавление

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

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


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ообщить модератору

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

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




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

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