LINUX.ORG.RU
ФорумTalks

Завезли ли в Вейланд родовые баги иксов?

 ,


0

1

Как известно, иксы плохо умеют в отладку приложений. Например, остановка полноэкранного приложения приводит к залочиванию всего экрана, выход из которого только по рестарту иксов. Если экранов несколько, то ситуация попроще, но всё равно не дай бог свернуть IDE.

Второе - проблемы с драг&дропом - если отладчик встал посреди драг&дропа, то «отваливается» мышь.

Вообще, alt-tab полноэкранных приложений в иксах уже лет 30 кривой и починить не могут.

Если сменить иксы на вейланд всей этой фигни ведь не будет? Или вагон другой окажется?

★★★★★

Ответ на: комментарий от lenin386

неумение в многопоточность

На стороне клиента или на стороне сервера?

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

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

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

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

lenin386 ★★★★
()

Вообще, alt-tab полноэкранных приложений в иксах уже лет 30 кривой и починить не могут.

У меня не было еще ни одного приложения в гноме, которое нельзя было бы свернуть или альт-табнуться. В т.ч. и полноэкранные игры. В т.ч. и зависшие.

В винде, кстати, с этим очень плохо, часто нельзя прибить полноэкранные приложения и альт-табнуться.

Im_not_a_robot ★★★★★
()

С drag&drop все хорошо - он роняет композитор. Так что первые полгода ты будешь отлаживать именно его.
По остальным пунктам не уверен.

Khnazile ★★★★★
()

В Wayland вряд ли. А вот в конкретную его реализацию - это уже надо смотреть и тестировать.

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

Товарищ, сейчас всё ацке-многопоточное, даже если это не надо. Мужчины требуют, чтобы их ядра, за которые они платили баблосы, были загружэны. Если ядра не загружэны, боссы требуют оптимизировать!

lenin386 ★★★★
()
Последнее исправление: lenin386 (всего исправлений: 1)
Ответ на: комментарий от lenin386

так это Хы однопоточные, а не приложение. а Хам вполне хватает и одного ядра. на одном ядре Хы, на всех остальных - все остальное.

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

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

Ctrl-Alt-F1, ps -A, killall hl2.sh

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

Так многопоточный код не загрузит ядра, а наоборот: было одно ядро, загруженное на 100%, распредилили нагрузку по ядрам, стало 12,5% на каждом ядре.

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

Так композитор вроде как фича Х-ов, в вэйланде другая архитектура

Там монолитная архитектура где в одном процессе работает оконная система, композитор и оконный менеджер. Если в чём-нибудь из этого будет ошибка, вся графика упадёт и все программы с окнами придётся открывать заново. X11 в этом плане более модульный, там оконный менеджер в отдельном процессе.

Гипотетически протокол Wayland не запрещает использовать несколько процессов, но это не стандартизировано и насколько я знаю пока нигде не реализовано.

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

Тема такая: для маложрущих приложений многопоточность вообще - плохо. Т.к. затраты на синхронизацию будет, а скорости работы приложения не прибавится. Кроме того, в целом, одно ядро потребляет меньше TDP, чем несколько.

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

Загрузит. Если на остальных ядрах делать while (1);. Загрузка ядер на 12,5% не устроит боссов. Даже 86% не устроит. Надо соточку. Поэтому, while (1) draw_clock(); Ой. А чё оно падает-то?

lenin386 ★★★★
()
Последнее исправление: lenin386 (всего исправлений: 3)
Ответ на: комментарий от next_time

Проблема с однопоточным кодом даже не в эффективном использовании ядер процессора, а в надёжности работы. В однопоточном коде операция может занимать длительное время и блокировать весь сервер пока операция не завершиться вплоть до зависания. В многопоточном сервере клиенты обрабатываются в разных потоках и зависание обработки одного из клиентов не приводит к глобальному зависанию.

Многопоточная графическая система реализована например в Haiku и Windows.

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

Перезапустить иксы вместо «прибивания» конкретного процесса, потому что это быстрее, и приложения автоперезапустятся, с сохранением несохранённых данных. Я ничего не пропустил?

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

Типичный wayland-сервер состоит из одного лишь композитора, который занимается всем. Возможно, в mir это не так, но я не проверял, т.к. оно не сильно живое.

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

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

ncrmnt ★★★★★
()

в вейлнде вообще нет отдельного понятия «полноэкранное приложение». можно сделать «окно на весь экран без рамок», как и в иксах.

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

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

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

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

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

Как? Вот у меня 4к монитор, я запускаю игру на Фуллхд. Что происходит? -50 fps? Потому, что фуллхд мы выставить не можем, полноэкранного режима же нет.

Вот в игре используется капслок для какой-то фигни. Что происходит, переключение языка, т.к. этот бинд отлавливает ОС?

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

Вот у меня 4к монитор, я запускаю игру на Фуллхд. Что происходит?

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

Вот в игре используется капслок для какой-то фигни. Что происходит, переключение языка, т.к. этот бинд отлавливает ОС?

Захват клавиатуры - совершенно отдельная фича, и да, он поддерживается.

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

потому что отключается compositor fullscreen unredirect. но если окно на полный экран, то в нормальных композиторах unredirect будет работать что в иксах что в вейланде.

eternal_sorrow ★★★★★
()

О нет, теперь проблемы в каждом композиторе свои. Хер разберешься, кто виноват, все кивают пальцами друг на дружку.

shimon ★★★★★
()

Проблем ещё больше. Те которые в иксах уже давно решили там надо решать, зато те которые в иксах не решили даже думать решать не надо, потому что до них ещё не добрались, более критичные баги фиксить надо

peregrine ★★★★★
()

У меня линукс с иксами ещё был, до иксорга. Я описанные проблемы если и видел, то ещё, наверное, в школе. Откуда ты это выкопал?

mrdeath ★★★★★
()

Например, остановка полноэкранного приложения приводит к залочиванию всего экрана

У меня не приводит, часто в игорях такое происходит, спокойно меняю воркспейс.

alt-tab полноэкранных приложений в иксах уже лет 30 кривой и починить не могут.

У меня работает нормально, как приложений которые при alt-tab сворачиваются, так и тех которые остаются в полноэкранном режиме.

shpinog ★★★
()

Не пробовал то, о чём ты говоришь, но в принципе у меня вейланд не вис ни разу. С полноэкранными приложениями только одна особенность была - если открыть игру (factorio) на полный экран, потом переключиться в браузер, открыть там ютуб-видео и тоже на полный экран, потом переключиться назад в игру, то в игре будет 1 FPS. Я так понял, полноэкранные приложения получают какой-то эксклюзивный доступ к железу и, видимо, делиться им не хотят.

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

На самом деле все GUI во всех операционных системах однопоточные. И WinAPI и macOS и Android и iOS и Swing и тд. Всегда у приложения есть main thread, в который посылаются сообщения, если нужно работать с GUI. Это нормально. В GUI слишком много «движущихся частей», зависящих друг от друга, которые адекватно распараллелить просто невозможно, проще заставить программистов использовать один поток.

На практике это не приносит никаких проблем.

Legioner ★★★★★
()
Последнее исправление: Legioner (всего исправлений: 1)
Ответ на: комментарий от lenin386

а откуда ты в этом понимаешь случайно не хочешь сказать?:)

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