Board.KolibriOS.org

Подниму-ка эту засохшую тему...

В текущем ядре фон отрисовывается полностью, даже когда изменился маленький кусок в 1х1 пикселей. Автор первоначальной реализации не стал особо париться над эффективностью, как и во многих других случаях. Отрисовкой фона занимается ядро. Обычно фон отрисовывается после убиения потока с окном.

У меня появились идеи:
1) Восстанавливать фон под собой может и само приложение при вызове функции -1. В таком случае мы получаем мгновенный отклик после закрытия окна. Однако что делать с "пристреливаемыми" приложениями не совсем ясно.
2) Восстанавливать фон может по прежнему само ядро, но с анализом данных окон убиваемых приложений. В этом случае есть не стыковки в виде необходимости синхронизации, чтобы никто не изменил данные координат восстанавливаемого прямоугольника, до завершения восстановления. Как вариант создать очередь сообщений.
3) Комбинация двух вариантов. Как всегда сложно и муторно.

Ваши мнения товарищи разработчики?

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

Нет приложение по прежнему не будет знать, о том надо фон восстанавливать или не надо - это не головная боль прикладного программиста. Ядро будет все само учитывать и делать - приложение ведь вызывает функции ядра. В том числе и функцию -1.

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

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

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

TASKDATA.state = 3 ; terminate this program

Однако в случае суицида код функции -1 не позволяет приложению выполняться далее окуклившись в замкнутый цикл, пока его не пристрелят. По этому оно может до вызова -1 завершить все свои мелкие и крупные дела и с чистой совестью вызвать -1. Это самый безопасный способ убиения невинного приложения.

4) убрать этот функционал из ядра. Пусть фоновую картинку рисует специальное приложение.

Serge
Я конечно уважаю твое мнение и заинтересованность, но давай вспомним как мы 1,5 года назад обсуждали и 2,5 года назад обсуждали и где сейчас поезд?

Я не хочу еще 1,5-2 года ждать, чтобы в очередной раз сказать "Я конечно уважаю твое мнение и заинтересованность, но давай вспомним как мы..."

Я уже попробовал сделать сначала как ты предлагал, но вышло плохо. Я не говорю, что я зря потратил время - наоборот я лучше разобрался с тем как функционирует видеоподсистема. Однако мое личное мнение относительно текущего вопроса такое как я изложил. Дело не в том что это твоя идея, а в том что я не уверен что она ускорит функционирование системы и при этом она сожрет "лишнюю" память равную размеру текущего LFB. А вот что я предложил не сожрет ничего лишнего.

Mario
Лишняя память - это несерьёзно. Её сейчас даже в eBox навалом.
На системах с акселерацией картинка вообще может в видеопамяти сидеть безвылазно.
Из ядра убирается необязательная функциональность.
Код объединяется с ICON и позволяет создавать эффекты затенения, прозрачности и т.д. и отказаться от системы каждая иконка - поток.

Не хочешь чтобы перерисовывалось всё - делай тайловую систему. Задача непростая, но решаемая. Профит всей системе будет. Большой.

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

Mario
А потом будут претензии "мой код выкинули" и "ты хочешь всё переписать" ? Это не к тебе конкретно, но прецеденты были.

Serge
Ну... это уже совсем какой то детский сад. Если кто то напишет более эффективный код чем тот который был, не важно чей был предыдущий код. Мы же вроде взрослые люди.

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

Mario
Увы, не все.

Mario
А пошто токмо -1 ?
Есть еще функции свертки и перемещеня окна, там тоже фон перерисовывать надо.

Serge
Если
- ядро рисует окно,
- ядро перемещает окно,
- ядро сворачивает/восстанавливает окно,
- ядро отслеживает принадлежность каждой видимой точки экрана конкретному окну,

то с какого привета НЕ_ЯДРО должно перерисовывать самый нижний видимый слой??

Артем, а ведь ты хорошо меня дополнил - слона то я и не заметил.
Да, надо учитывать все варианты.

art_zh
Тогда с какого привета ядру не рисовать иконки и меню ? Кнопки ведь рисует ? Функционал ядра можно расширять бесконечно. Ville туда 3D API вписал.

Проблема вся идёт от того что у нас никогда не было единого десктопа. Иконки - одна программа, панель - вторая, меню на правой кнопке - третья. А фоновую картинку рисует ядро, потому что больше некому. Оконная система не позволяет. А если позволить, то всё складывается в одно приложение. Всего то надо дать приложению возможность рисовать в слот 1. В Менуэт этого нет и все привыкли, что так и должно быть. Потому и 20+ потоков ICON, выкручиваемся как можем. Сделай такую отрисовку и необходимость рисовать фон из ядра становится неочевидной.
Оптимизация ? Здесь у ядра преимущество, если нет тайловой архитектуры. Но под одним окном может быть ещё N других и всё это надо учитывать. Малой кровью свести сложное отсечение к набору прямоугольников "чтобы ни одного лишнего пикселя" не получится. А если определять один ограничивающий прямоугольник в котором менялось содержимое экрана (а это действительно будет очень полезной оптимизацией), то его координаты дексктоп приложение может у ядра получить.