Board.KolibriOS.org

eBox-3300MX (Vortex86MX)
Бывшее стандартное trunk ядро, ревизии 2426, VESA:

Spoiler:

1.png (5.52 KiB)

Viewed 7110 times

Ядро с неморгающим курсором, ревизии 2453, VESA:

Spoiler:

2.png (5.38 KiB)

Viewed 7110 times

Шестеренки 32/30 попугаев соответственно.
Максимальное отставание около 22%. Некоторые параметры стали быстрее.

Это радостные новости. Догнать и перегнать!

Было бы замечательно, если бы ты выложил сравнительные тесты на своем компе.

Мой старый тест


И два новых, ядро 2454

SVN r. 2455 Некоторое едва заметное увеличение скорости отрисовки.

Словил я этот баг!
Всё просто. Поменяй фоновую картинку
Лично я делал так:
1. запустил систему.
2. в эолайте на картинке разрешением больше экрана ctrl+d
После этого закрываешь окно - курсор исчезает, двигаешь - появляется. Сделал размер окна меньше - остался артефакт.

Размер какого окна, какого приложения? Еолайт? Надо описывать все до последнего пука пользователя.

Было уже однажды в истории Колибри:

- А вспомнил! Может быть потому - Я когда мышку двигаю всегда шифт на клавиатуре зажимаю.
- Зачем?
- Не знаю, как то так исторически сложилось...

Да любого окна. Пока писал этот пост мог бы уже 100...

здесь я реши останосться (реально так и было) и САМ пошёл в Кьему, сделал на рабочий стол background.gif не плиткой, а растянул на весь экран. Изменил размер Эолайта, баг проявился.

Марат, мог бы и сам проверить за то время, что писал пост.

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

А вот насчет моргания курсора так и не понял.

З.Ы. Не надо думать что я ленивый. Однако неточности в описании действий вводят в ступор. Ты пойми, что твоя информация в голове подтверждена зрительной и механической частью запоминания, а мне ты скидываешь исключительно дельту в виде текстового описания. Тут как с книгой - чем меньше деталей, тем более разные картинки видят писатель и читатель. Все зависит от накопленного жизненного опыта или вообще его отсутствия в некоторых вещах.

З.З.Ы. Я проверял ранее с растяжкой картинки, но она была маленькая, меньше экрана. Всех вариантов на свете не предусмотришь.

Размер изображения значения не имеет.

Ядрена кочержика! Вот не было же. Точно помню что две-три ревизии назад не было.

Leency wrote:Словил я этот баг!
Всё просто. Поменяй фоновую картинку
Лично я делал так:
1. запустил систему.
2. в эолайте на картинке разрешением больше экрана ctrl+d
После этого закрываешь окно - курсор исчезает, двигаешь - появляется. Сделал размер окна меньше - остался артефакт.

Исправлено в SVN r. 2459

SVN r. 2463 исправление вывода лишних 2-х точек для схлопнутого окна (rolledup), для истинных дизайнеров и ценителей чувства прекрасного к коим я сам не отношусь.
SVN r. 2464 исправление для фоновой картинки в режиме черепицы. Новый способ считывания пикселя (4 байта за раз в один заход, вместо 3 раз по 1 байту в старом варианте) приводил к вылету в некоторых случаях (например, PIC4). Сделал выделение памяти с запасом (выравнивание на границу 4 Кб). Все равно при выделении памяти она физически выделяется страницами не менее 4 Кб, так что физически расхода памяти лишнего нет.

Mario wrote:Все равно при выделении памяти она физически выделяется страницами не менее 4 Кб, так что физически расхода памяти лишнего нет.

Теоретически может быть ситуация где идет расход лишних 4 кб. Например если требуемый объем памяти кратен 4-м кб, тогда inc eax делать не нужно. Когда хоябы один из младших 12 битов регистра eax не равен 0, тогда выполняемые действия нужны.
Это так просто придирки, ничего против не имею.

Они не являются лишними в любом случае - ты прочти комментарий: либо 4Кб выделить (если запросить 1 байт, то все равно 4 Кб будет выделено), либо получить исключение page fault в ядре (считывание залазит за границу выделенной памяти), со всеми вытекающими последствиями.

А так да я совершенно согласен - жутчайший перерасход памяти в целых 50% случаев.