Ревизия 3936

Applications development, KoOS API questions

POLL Оставить как есть или добавить фикс отменяющий 3936 ?

Total votes: 6
Как есть
33%
2
Ревертнуть
67%
4

  • А там нет просто ошибки off-by-one?
  • nina wrote:А там нет просто ошибки off-by-one?
    Где-то есть и ее возможно исправить, а вот производительность нет.
    Из хаоса в космос
  • А, тем более тогда надо откатывать, имхо.
  • Leency wrote:уменьшение производительности на 25-40%
    Потому что появились дополнительные проверки.
    А без них снова будет
    0CodErr wrote:при перемещении окна Calc, не выходящего за пределы окна KPack, также перерисовывается Debugger, окно которого находится ниже окна KPack
    Иными словами, снова будет происходить совершенно ненужная(а как же производительность?) перерисовка.
    Ну а MGB — синтетический бенчмарк, другого результата и не могло быть.

    Я считаю, что баг исправлять нужно(что и было сделано).
    Возможно, есть способ немного оптимизировать код дополнительных проверок.
    Тот баг http://board.kolibrios.org/viewtopic.ph ... 096#p72096 исправлять тоже нужно.
    Поэтому данный опрос немного странный.
    Вам какой баг оставить: тот или этот? Выбирайте. :lol:

    Leency, ты исправил SysFn73:Blit http://board.kolibrios.org/viewtopic.ph ... 110#p72110 но баг там появился вследствии "Small optimization", то есть ты ухудшил производительность, но, однако же теперь стало работать правильно.
    Быстрый, но работающий неправильно код — это хуже, чем более медленный, но работающий правильно.
  • Если бы падение производительности было 5-15% одно дело, но 25-40% совершенно другое.
    Из хаоса в космос
  • Leency wrote:5-15% одно дело, но 25-40% совершенно другое.
    :lol: Совершенно не имеет значения.
    Посмотри-ка, сколько дополнительных проверок происходит до вызова real put_pixel function http://websvn.kolibrios.org/filedetails ... 3#line-865 может и их надо убрать?

    Я не голосовал, так как опрос глупый по своей сути.
  • Немного демагогии...
    Просадка производительности выглядит серьёзно, вероятно имеет место плохая архитектура, поэтому проверки столько съели. Опять же если окон будет много, все они будут перерисовываться, в некотором случае - всё может вывернуться наоборот. И мы получим не прирост, а просадку (после отката). Всё зависит от общей реализации.

    По хорошему нужно разобраться в архитектуре, откатить и наложить хороший патч (значительно лучший, чтобы обычные просадки были не больше 3%, а остальное не изменилось). Если желающих нет, то лучше не трогать.

    Leency, протестируй с несколькими окнами, если перерисовку (баг, показанный 0CodErr) и падения производительности не видно, то по-моему откат лучшее решение. Это позволит начать движение к переделке.
  • Ок, мои доводы: падение производительности влияет на все без исключения программы.
    А выигрыш, т.е отсутствие перерисовки, будет в очень небольшом проценте случаев, вдумайтесь: когда есть три программы и самая верхняя передвигается в пределах средней. Это не стоит 25-40%.

    Кстати, перерисовку MTDBG из первого поста я исправил давным давно.
    Attachments
    scr.png
    scr.png (31.31 KiB)
    Viewed 13338 times
    Last edited by Leency on Wed Oct 17, 2018 11:07 pm, edited 1 time in total.
    Из хаоса в космос
  • Фикс 3936 абсолютно к месту. Он решает определённую проблему, которая вполне очевидна. Но надо исправить проблему с 1px. А цифры бенчмарка совершенно логично свидетельствую о том, что добавились доп. проверки. Но из этих цифр не очень понятно на сколько реально замедлилась работа по отрисовке GUI.
  • Фикс поидее должнен был затронуть только момент после передвижения окна, почему он повлиял на рисование в самом окне не понятно.
    Из хаоса в космос
  • Leency wrote:Кстати, перерисовку MTDBG из первого поста я исправил давным давно.
    Это вообще не имеет отношения к теме.
    Приложение получает сообщение "надо перерисоваться", и затем вызывается процедура перерисовки(BeginDraw, EndDraw, DrawWindow, DrawButton, DrawText, и вызовы других системных функций, если они используются).
    Или логика у вас, у художников: если не мерцает, то и ресурсы не расходуются? :mrgreen:
    Ресурсы расходуются независимо от того, заметил ты это или нет.
    Leency wrote:почему он повлиял на рисование в самом окне не понятно
    Во время рисования точки проверяется, какому окну она принадлежит(_WinMapAddress).
    Возможно, эту проверку можно оптимизировать.
    Но это странно, что необходимость этой проверки ещё вызывает у кого-то вопросы.
  • Нужно вернуть производительность и по возможности найти более элегантное решение бага. Тем более, Leency, только ты окна попиксельно двигаешь :).
  • popovpa, "вернуть производительность" и "пофиксить баг" в данном случае взаимоисключающие вещи.

    Оба бага — плохо. И тот и другой нужно фиксить.
    Потеря производительности — тоже плохо, нужно по возможности оптимизировать дополнительные проверки.

    Я не знаю, следишь ли ты за проектом и насколько именно.
    Но вот тебе ещё пример http://websvn.kolibrios.org/filedetails ... 4#line-308
    Просто твои мысли по этому поводу? Правильная работа или быстрая работа? Что лучше?
    Ну этот http://websvn.kolibrios.org/filedetails ... 3#line-865 ты выше видел, наверное.
    А ещё есть переключение контекста, однозадачная ОС могла быть ещё быстрее.
    Есть вещи, которые так или иначе отъедают ресурсы, но это нужные вещи!

    А данный опрос не имеет никакой силы.
    Глупо спрашивать, нужно ли было фиксить баг или стоит вернуть баг на место.
    Ведь и так понятно, что любые баги нужно фиксить. И совершенно неважно, что там наголосуют художники со школьниками.

    Я со всей ответственностью заявляю, что в случае возврата к багу, откачу обратно.
    Я не собираюсь учитывать мнение некомпетентных людей.
    Вообще я как-то уже предлагал сделать ответственных людей за коммиты, а не коммитить всем подряд, я бы предложил, например, таких людей: CleverMouse, Serge, hidnplayr, dunkaist.

    А кое-кого следовало вообще забанить.
    Модератор кое-что потёр уже, но archive.is всё помнит http://archive.is/eW7Uq

    Ну, в общем, без администрации тут явно не обойтись.
    Очень странно, что админы до сих пор не вмешиваются.
    Я же со своей стороны будут делать так, как считаю правильным.
    Баги в любом случае нужно фиксить.
    Уж если админы скажут, что баги это норм, зато быстро — ну ок, продолжайте закапывать проект и дальше, а пока что я спокойно молчать не буду.
  • 0CodErr wrote:popovpa, "вернуть производительность" и "пофиксить баг" в данном случае взаимоисключающие вещи.

    Оба бага — плохо. И тот и другой нужно фиксить.
    Потеря производительности — тоже плохо, нужно по возможности оптимизировать дополнительные проверки.

    Я не знаю, следишь ли ты за проектом и насколько именно.
    Но вот тебе ещё пример http://websvn.kolibrios.org/filedetails ... 4#line-308
    Просто твои мысли по этому поводу? Правильная работа или быстрая работа? Что лучше?
    Ну этот http://websvn.kolibrios.org/filedetails ... 3#line-865 ты выше видел, наверное.
    А ещё есть переключение контекста, однозадачная ОС могла быть ещё быстрее.
    Есть вещи которые так или иначе отъедают ресурсы, но это нужные вещи!

    А данный опрос не имеет никакой силы.
    Глупо спрашивать, нужно ли было фиксить баг или стоит вернуть баг на место.
    Ведь и так понятно, что любые баги нужно фиксить. И совершенно неважно, что там наголосуют художники со школьниками.

    Я со всей ответственностью заявляю, что в случае возврата к багу, откачу обратно.
    Я не собираюсь учитывать мнение некомпетентных людей.
    Вообще я как-то уже предлагал сделать ответственных людей за коммиты, а не коммитить всем подряд, я бы предложил, например, таких людей: CleverMouse, Serge, hidnplayr, dunkaist.

    А кое-кого следовало вообще забанить.
    Модератор кое-что потёр уже, но archive.is всё помнит http://archive.is/eW7Uq

    Ну, в общем, без администрации тут явно не обойтись.
    Очень странно, что админы до сих пор не вмешиваются.
    Я же со своей стороны будут делать так, как считаю правильным.
    Баги в любом случае нужно фиксить.
    Уж если админы скажут, что баги это норм, зато быстро — ну ок, продолжайте закапывать проект и дальше, а пока что я спокойно молчать не буду.
    Фиксить то можно по разному.
    1. Впендюрить первое попавшееся решение. Как раз что ты предлагаешь.
    2. Оценить влияние на остальное окружение и действовать дальше:
    2.1 Забить
    2.2 Сделать воркэраунд
    2.3 Задокументировать
    2.4. Проработать в рабочем порядке и выбрать оптимальный результат.

    Поскольку этот баг никому не мешал, спешка ни к чему.

    У меня вот, кнопка закрытия окна, если находится над иконками десктопа,перестают работать. Возможно, это связано
  • Who is online

    Users browsing this forum: No registered users and 3 guests