View Issue Details

IDProjectCategoryView StatusLast Update
0003213Far ManagerEditorpublic2016-04-21 08:17
ReportershmuelAssigned Tozg 
PrioritynormalSeverityminorReproducibilityalways
Status closedResolutionfixed 
Platformx86OSWindowsOS VersionXP SP3
Product Version3.0 
Target VersionFixed in Version3.0 
Summary0003213: Время перерисовки редактора почему-то становится пропорционально размеру файла
DescriptionОпыты должны проводиться в отсутствии раскрашивающих плагинов и скриптов. В идеале - Фар с чистым профилем, единственным плагином LuaMacro и тестовым скриптом.

В исходном состоянии эффект не наблюдается, то-есть время перерисовки (верхнего) экрана редактора не зависит от размера файла. При моей установке это примерно 0.35 - 0.45 msec.

Однако стоит всего один раз вызвать ECTL_ADDCOLOR и/или ECTL_DELCOLOR, как время перерисовки того же (верхнего) экрана редактора становится пропорциональным размеру файла (или количеству строк - не проверял). Например, на тестовом файле размером 37 MB, время перерисовки верхнего экрана увеличивается до 34.4 msec, на файле 74 MB - до 68.6 msec.

Приложен тестовый файл размером 37 MB.
Steps To ReproduceMacro {
  description="Увеличение времени перерисовки экрана редактора";
  area="Editor"; key="F1";
  action=function()
    local N = 10
    local t1 = far.FarClock()
    for k=1,N do editor.Redraw() end
    t1 = far.FarClock() - t1
    editor.AddColor(nil, 1, 1, 16, 0, 0xF0)
    editor.DelColor(nil, 1, 1)
    local t2 = far.FarClock()
    for k=1,N do editor.Redraw() end
    t2 = far.FarClock() - t2
    far.Show(t1/N,t2/N)
  end;
}
-- Любую одну из строк AddColor/DelColor можно закомментировать - эффект остаётся.
TagsNo tags attached.
Build4629

Activities

shmuel

2016-04-10 23:40

developer  

changelog.7z (260,790 bytes)

zg

2016-04-14 00:27

developer   bugnote:0014450

4621.

shmuel

2016-04-14 09:21

developer   bugnote:0014451

Спасибо.

shmuel

2016-04-14 18:40

developer   bugnote:0014458

К сожалению, данное исправление не снимает пропорциональную зависимость времени перерисовки от размера файла во всех случаях. Ниже приведен тест-кейс, для которого времена перерисовки в билде 4621 остались примерно такими же, как и до него.

Macro {
  description="Увеличение времени перерисовки экрана редактора";
  area="Editor"; key="F3";
  action=function()
    local N = 10
    local t1 = far.FarClock()
    for k=1,N do
      editor.AddColor(nil,1,1,16,"ECF_AUTODELETE",0xF0)
      editor.Redraw()
    end
    t1 = far.FarClock() - t1
    far.Show(t1/N)
  end;
}
-- Вместо "ECF_AUTODELETE" можно поставить и 0, это мало влияет на время перерисовки.

zg

2016-04-14 21:05

developer   bugnote:0014459

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

shmuel

2016-04-14 21:24

developer   bugnote:0014460

А смысл в чём сканирования всех строк?

zg

2016-04-14 21:37

developer   bugnote:0014461

я глубоко не разбирался, но насколько я понимаю, сортировка цветов и удаление пустых списков. почему не хранить цвета сразу в чём-нибудь типа std::map — не знаю.

shmuel

2016-04-14 22:47

developer   bugnote:0014462

Или, например, 2 переменных minLine, maxLine. Исходно и после каждой перерисовки устанавливаются в -1. Корректируются при приёме ECTL_ADDCOLOR и ECTL_DELCOLOR. Тогда сканировать можно будет не все строки, а только диапазон [minLine, maxLine]. Для второго примера данного тикета этот диапазон будет 1 строка. (Но этот диапазон нужно будет корректировать также при удалении и вставке строк).

zg

2016-04-20 02:47

developer   bugnote:0014473

4628.

shmuel

2016-04-20 08:26

developer  

CrashLogs.7z (14,285 bytes)

shmuel

2016-04-20 08:30

developer   bugnote:0014474

Времена перерисовки, кажется, перестали зависеть от размера файла. Это радует. :)

Но стал падать Фар с моим плагином Highlight. Крэш-логи приложил здесь (Crashlogs.7z). Попозже, сегодня или завтра, постараюсь дать более точную информацию.

zg

2016-04-20 13:28

developer   bugnote:0014478

Last edited: 2016-04-20 13:28

View 2 revisions

4629, а где берут highlight?

shmuel

2016-04-20 13:50

developer   bugnote:0014479

4629, собранный GCC 5.3, не падает. Но на всякий случай подождём ночной сборки.

Highlight и некоторые другие плагины убрал с глючного плагринга, оставил только 3 плагина, о которых точно знаю, что есть хотя бы 1 пользователь, кроме меня. Если нужно (например, для коллекции), могу приложить прямо здесь.

zg

2016-04-20 14:05

developer   bugnote:0014480

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

shmuel

2016-04-20 14:15

developer   bugnote:0014481

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

Issue History

Date Modified Username Field Change
2016-04-10 23:39 shmuel New Issue
2016-04-10 23:40 shmuel File Added: changelog.7z
2016-04-14 00:27 zg Note Added: 0014450
2016-04-14 09:21 shmuel Build => 4621
2016-04-14 09:21 shmuel Note Added: 0014451
2016-04-14 09:21 shmuel Status new => closed
2016-04-14 09:21 shmuel Assigned To => zg
2016-04-14 09:21 shmuel Resolution open => fixed
2016-04-14 09:21 shmuel Fixed in Version => 3.0
2016-04-14 18:40 shmuel Note Added: 0014458
2016-04-14 18:40 shmuel Status closed => feedback
2016-04-14 18:40 shmuel Resolution fixed => reopened
2016-04-14 21:05 zg Note Added: 0014459
2016-04-14 21:24 shmuel Note Added: 0014460
2016-04-14 21:24 shmuel Status feedback => assigned
2016-04-14 21:37 zg Note Added: 0014461
2016-04-14 22:47 shmuel Note Added: 0014462
2016-04-20 02:47 zg Note Added: 0014473
2016-04-20 08:26 shmuel File Added: CrashLogs.7z
2016-04-20 08:30 shmuel Note Added: 0014474
2016-04-20 13:28 zg Note Added: 0014478
2016-04-20 13:28 zg Note Edited: 0014478 View Revisions
2016-04-20 13:50 shmuel Note Added: 0014479
2016-04-20 14:05 zg Note Added: 0014480
2016-04-20 14:15 shmuel Note Added: 0014481
2016-04-21 08:17 shmuel Build 4621 => 4629
2016-04-21 08:17 shmuel Status assigned => closed
2016-04-21 08:17 shmuel Resolution reopened => fixed