В текущей реализации ф.50 редкостный кусок дерьма. Я несколько раз предлагал её выкинуть. IMHO лучше откатить назад.

Вот уже второй... у вас есть что сказать кроме - "Эта окошко реализация мне не нравится!"

Посмотрел я код ф.50 и ничего криминального кроме одного IMUL не увидел. Стоит принять во внимание что в Icon отрисовывает только 52*52 окно. Я достаточно легко могу доказать замерами, что в результате применения ф.50 скорость вывода именно в этом случае возросла.

И вообще не вижу вины за ф.50 - код вызывается перед отрисовкой окна и всего лишь более хитро заполняет область WinMap. Вместо прямоугольника заполняется произвольная область. Я еще понимаю в чем претензии Артема (ему тайловую графику надо), но Сергей ты то на чем строишь свои суждения?

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

Если уж на то пошло, то вернуть вывод без ф.50 дело 5 минут, но пока вы мне не покажите реализацию работающего кода отсечки на тайлах в ядре trunk я не стану этого делать. Извиняйте парни, но в данном конкретном случае вы не правы.

Mario
Ты видно невнимательно смотрел. Просмотри код window._.set_screen пока не увидишь read_process_memory.

Если уж на то пошло, то говном является read_process_memory и map_memEx, которые вызываются в цикле. Если для целей playnote и debug это можно стерпеть, то в данном случае согласен что не оптимально. Посмотрю что можно придумать в этом случае.

Чтобы было от чего плясать я допилил MGB с ф.50 На моем самом тугом, при тестировании неморгающего курсора, Roverbook U800 я получил падение: 20% на окнах, 6% на отрисовке прямоугольников, 9% на отрисовке картинок. Все остальные параметры не изменились, разница в пределах погрешности измерения.
На Dell Inspiron я получил падение: 12% на окнах, остальные параметры не изменились, разница в пределах погрешности измерения.
На eBox-3300MX (Vortex86MX) я получил падение: 18% на окнах, остальные параметры не изменились, разница в пределах погрешности измерения.

А чтобы доказать свою правоту относительно реализации Icon с ф.50, вот два варианта: В обоих случаях каждая иконка отрисовывается по 100 раз за вызов, иначе сложно замерить. Даже на моем тормозном Roverbook 800 приложение Icon задействующее ф.50 отрисовывается в 1,5-2 раза быстрее согласно показателям замеров на BOARD. Снижение производительности из-за использования ф.50 (до 20% согласно предыдущим замерам) отлично компенсируется в 2 раза меньшим количеством расчета точек.

Черт! Я потратил почти полдня чтобы доказать очевидную вещь. Спрашивается нафига мне это надо?

А еще ты потратил 2 дня чтобы на полмиллисекунды ускорить отрисовку иконок.
(при том что отрисовка и так происходит очень быстро. и очень редко.)

И теперь злишься на то, что тебе сообщили какова цена этого непринципиального ускорения.
Дело не в том, что кому-то не нравится мутная 50-я, а в том что после твоих трудов праведных эту фиговину из ядра теперь и убрать никак нельзя будет.
Разве что вносить Иконменеджер целиком в ядро?

Так-так, давай уточним детали.
1. Я оптимизировал Icon и я добился поставленной цели.
2. Может быть когда и если я сделаю более оптимальную отрисовку фона (или какой еще человек), то твои слова:

art_zh wrote:А еще ты потратил 2 дня чтобы на полмиллисекунды ускорить отрисовку иконок.

будут правдой, но пока это не так. При отрисовке фона каждый раз перерисовываются все иконки. Для пользователя это не заметно, потому что они пишутся поверх такого же, если иконка не попала, но реальное время кушает. Так что смело умножаем на количество иконок время экономии одной иконки.
3. Я уже сказал - покажите мне тайловый механизм отрисовки и я без промедление удалю вызов ф.50.
4. Злюсь я потому что вы призываете потерпеть сейчас, ради светлого будущего. Мне же приходится доказывать, что я не верблюд. В то время как можно сейчас пользоваться ф.50, а потом удалить. Напомню - за все время ее существования была написана всего одна программа демонстрации этого режима.

Всю эту доказательную базу пришлось подводить, чтобы доказать вам что развитие по п.4 нисколько не мешает вам. Вы главное сделайте сначала! Так ведь наверное проще объявить, что вот потому что Марат злодей у нас не появилось того то и того то. Я же доказываю что препятствие выдуманное и существует оно исключительно в голове возражающих.

З.Ы. На самом деле я потратил два дня на то чтобы вычистить исходники и сократить занимаемую память. Добавление же ф.50 заняло от силы полчаса. А вот с вами я уже второй день спорю. Как тут не обозлиться.

Mario
Ты лучше посчитай сколько времени теперь занимает пересчёт оконной карты. read_process_memory очень специфическая функция и необходима только для отладчика, а за все остальные применения надо давать по рукам.

Казнить, нельзя помиловать!

Запусти Fplay в qemu и поставь на паузу. Теперь попробуй изменить размер окна мышкой. Разница очень заметна.

Разница некоторая есть, но в обоих случаях таскание окна FPLAY нагружает процессор на 100%.
Ладно убедил - уберу ф.50. Кто я такой чтобы переть против здравого смысла подкрепленного пистолетом.

SVN r. 2476
1) Убрал вызов ф.50 - я надеюсь теперь как минимум двое будут спать крепким сном праведника выполнившего долг.
2) Увеличил скорость за счет использования ф.15.6 и ф.15.7, вместо более медленной ф.39.2.
3) Уменьшил память занимаемую программой за счет точного выделения ф.68.12 и возврата ф.68.13. С текущими иконками программа в памяти занимает 140 Кб.

Ладно, можешь иконки в меню не делать, но то, что я нажимаю в промежукте между иконкой и её надписью и это не запускает программу - реально напрягает. Ведь понятное дело, я хотел не стол в этом "странном" месте потыкать а программу запустить!