Издавна повелось, что события, поступающие от устройств ввода (клавиатура, мышь, сенсорный экран и т.п.) складываются в очередь, и обрабатываются "по мере возможности". Но, если для клавиатуры это еще имеет какой-то смысл (нажимаемые подряд символьные клавиши, клавиши последовательной навигации и т.п.), то какой смысл это может иметь для мыши и тачпада — по крайней мере, по истечении 0.1-0.2 с?

Как беру в руки не самый быстрый гаджет, или даже быстрый гаджет, имеющий не очень быстрый канал в Интернет, так непременно наблюдаю классические косяки, связанные с обработкой этих самых событий из очереди. Например, кликаю/тапаю на какой-нибудь кнопке, отображаемой скриптом на веб-странице. Кнопка не реагирует, я делаю вывод, что событие "потерялось", кликаю/тапаю снова (иногда несколько раз) — происходит обновление блока/страницы, и нередко выясняется, что на том месте уже успела побывать другая кнопка (или другой элемент интерфейса), и все они срабатывают на взятые из очереди тапы/клики.

Еще круче, когда тормозит даже не сайт, а сам браузер. Хочу закрыть вкладку, жму на крестик — нет реакции. Чуть двигаю палец/курсор, жму снова — вкладка закрывается, на ее место встает соседняя, которая тут же снова закрывается по очередному тапу/клику, который ждал в очереди.

И эта хрень везде — в Windows, в Android, в iOS. MacOS под рукой нет, но вряд ли там иначе.

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

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

Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>Какой может быть смысл в том, чтобы держать в очереди два, три и более клика/тапа на одной и той же точке экрана, с интервалом хотя бы в полсекунды? Ни двойной клик, ни долгий тап из них уже никогда не получатся. Кто-нибудь может себе представить возможную пользу от такого?

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

Здравствуйте, swame, Вы писали:

S>Нужно выполнить долгую операцию многократно — например удаление заданий из очереди печати — кликнул 10 раз кнопку

Это где такая кнопка, серией кликов по которой можно удалить несколько заданий без подтверждения?

S>Я в своем при клике мышью во многих случаях валидирую в обработчике, актуально ли это событие еще — например находится ли еще мышь поблизости.

Тогда Ваш софт не позволит "выполнить долгую операцию многократно".

Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>Здравствуйте, swame, Вы писали:

S>>Нужно выполнить долгую операцию многократно — например удаление заданий из очереди печати — кликнул 10 раз кнопку

ЕМ>Это где такая кнопка, серией кликов по которой можно удалить несколько заданий без подтверждения?

Ну вот в форме очередей печати, когда такое делал , не требовалось.
Удалить файл в проводнике.
Завершить задание в диспетчере.
При наличии соответсвующих прав.


S>>Я в своем при клике мышью во многих случаях валидирую в обработчике, актуально ли это событие еще — например находится ли еще мышь поблизости.

ЕМ>Тогда Ваш софт не позволит "выполнить долгую операцию многократно".

В этих случаях такое точно не требуется.

Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>Издавна повелось, что события, поступающие от устройств ввода (клавиатура, мышь, сенсорный экран и т.п.) складываются в очередь, и обрабатываются "по мере возможности". Но, если для клавиатуры это еще имеет какой-то смысл (нажимаемые подряд символьные клавиши, клавиши последовательной навигации и т.п.), то какой смысл это может иметь для мыши и тачпада — по крайней мере, по истечении 0.1-0.2 с?

Смысл в том, что у мыши в очереди не только клики, но и относительные координаты перемещения курсора. (впрочем, очередь тачпада можно настроить на абсолютные)

ЕМ>Еще круче, когда тормозит даже не сайт, а сам браузер.

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

Все проблемы от жадности и глупости

Здравствуйте, Stanislaw K, Вы писали:

SK>А очередь системная. т.е. пользователь может "уехать" курсором из окошка тормозящего браузер и кликать/прокручивать в другое окно, иногда даже оставляя в foreground тормозящий браузер.

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

Здравствуйте, Евгений Музыченко, Вы писали:

SK>>А очередь системная. т.е. пользователь может "уехать" курсором из окошка тормозящего браузер и кликать/прокручивать в другое окно, иногда даже оставляя в foreground тормозящий браузер.

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

А как надежно определить устаревшее? К пример, браузер подвис. я подвинул курсор +100х -300у, подождал 6 секунд, подвинул курсор +150х +100у, подождал 6 секунд, я подвинул курсор +100х -300у, подождал 6 секунд, подвинул курсор -150х +100у, кликнул.

Получается система должна передать только последний клик, а те движения что я выполнял 666 секунд нет? но тогда в браузере нажмётся "не та кнопка". (там ещё и куча логики отслеживания поломается)

p.s. и что делать в случае, когда в приложении есть свой буфер событий (дополнительно к системной очереди)?

Все проблемы от жадности и глупости

Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>И эта хрень везде — в Windows, в Android...
ЕМ>По-моему, это уже запредельно криво. ...

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

Здравствуйте, Stanislaw K, Вы писали:

SK>А как надежно определить устаревшее?

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

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

Ну и чтоб это где-то настраивалось, как параметры времени двойного клика, автоповтора клавиатуры и прочего.

SK>Получается система должна передать только последний клик, а те движения что я выполнял 666 секунд нет?

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

SK>тогда в браузере нажмётся "не та кнопка".

В подозрительных случаях вообще никакая не должна нажаться.

SK>что делать в случае, когда в приложении есть свой буфер событий (дополнительно к системной очереди)?

Здесь, понятное дело, претензии только к приложению: взяло ответственность — пусть несет. Только вот зачем приложению свой буфер, если это не какая-нибудь игра на предельную скорость реакции?

Здравствуйте, Евгений Музыченко, Вы писали:

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

Система, которая принимает решение за пользователя (хотя бы и на уровне какую кнопку нажать а какую не нужно) будет утилизирована вместе с её архитектором.

ЕМ>Ну и чтоб это где-то настраивалось, как параметры времени двойного клика, автоповтора клавиатуры и прочего.

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

SK>>Получается система должна передать только последний клик, а те движения что я выполнял 666 секунд нет?

ЕМ>Если браузер на какое-то время перестал обрабатывать сообщения — это нужно признать нештатной ситуацией, и реагировать соответственно.

Кому реагировать? ОС? А браузер не перестал. это одна из вкладок в нем "немного задумалась". Сам браузер все вовремя принимает и снаружи, со стороны ОС, выглядит совсем как живой.

ЕМ>Если Вы перебрасываете кирпичи друг другу по цепочке, и вдруг увидели, что следующий в цепочке не поймал очередной кирпич — будете продолжать бросать, целясь в то место, где должны быть его руки?

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

SK>>тогда в браузере нажмётся "не та кнопка".
ЕМ>В подозрительных случаях вообще никакая не должна нажаться.

Система, которая принимает решение за пользователя (хотя бы и на уровне какую кнопку нажать а какую не нужно) будет утилизирована вместе с её разработчиком.

SK>>что делать в случае, когда в приложении есть свой буфер событий (дополнительно к системной очереди)?
ЕМ>Здесь, понятное дело, претензии только к приложению: взяло ответственность — пусть несет. Только вот зачем приложению свой буфер, если это не какая-нибудь игра на предельную скорость реакции?

Ну, не знаю. а что по этому поводу говорят разработчики FarManager, например?

Все проблемы от жадности и глупости

Здравствуйте, Stanislaw K, Вы писали:

SK>Система, которая принимает решение за пользователя (хотя бы и на уровне какую кнопку нажать а какую не нужно) будет утилизирована вместе с её архитектором.

Э-э-э... Вы вокруг себя давно смотрели? Да и кем она могла бы быть "утилизирована"? Подавляющее большинство пользователей только спасибо скажет, если система сумеет угадать, какие кнопки они собирались нажать, и сделает это за них. И таки говорят, начиная с T9 и подобных костылей.

SK>Это общесистемные настройки, а я с такими проблемами сталкиваюсь, как и Вы, только в одном из браузеров.

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

SK>Кому реагировать? ОС?

Ну да. Очередь-то системная. Если ОС поддерживает какой-то поток событий в реальном времени (прерывания, звук, видео и т.п.), и процесс не успевает их обрабатывать, то ОС их тупо херит. Почему очередь событий от устройств ввода должна быть исключением? Лишь потому, что памяти много?

SK>А браузер не перестал. это одна из вкладок в нем "немного задумалась". Сам браузер все вовремя принимает и снаружи, со стороны ОС, выглядит совсем как живой.

Если браузер забирает сам, то эту задачу следует переложить на него. По уму, обычная кнопка, по которой кликнули, должна автоматически становиться неактивной до тех пор, пока клик не будет обработан. Этакий аналог подавления дребезга в схемотехнике.

SK>очередь быстрый примитивный протокол без подтверждения и обратной связи.

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

SK>Система, которая принимает решение за пользователя (хотя бы и на уровне какую кнопку нажать а какую не нужно) будет утилизирована вместе с её разработчиком.

Еще два раза "ха".

SK>что по этому поводу говорят разработчики FarManager, например?

Не интересовался, поскольку в FAR Manager с таким не сталкивался. Что там нужно сделать, чтобы это увидеть?

Здравствуйте, Евгений Музыченко, Вы писали:

SK>>Система, которая принимает решение за пользователя (хотя бы и на уровне какую кнопку нажать а какую не нужно) будет утилизирована вместе с её архитектором.

ЕМ>Э-э-э... Вы вокруг себя давно смотрели? Да и кем она могла бы быть "утилизирована"? Подавляющее большинство пользователей только спасибо скажет, если система сумеет угадать, какие кнопки они собирались нажать, и сделает это за них. И таки говорят, начиная с T9 и подобных костылей.

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

SK>>Это общесистемные настройки, а я с такими проблемами сталкиваюсь, как и Вы, только в одном из браузеров.

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

"несколько миллиардов бессмысленных операций" это и есть та самая попытка оградить пользователя от его намерений.

SK>>Кому реагировать? ОС?

ЕМ>Ну да. Очередь-то системная. Если ОС поддерживает какой-то поток событий в реальном времени (прерывания, звук, видео и т.п.), и процесс не успевает их обрабатывать, то ОС их тупо херит.

Потому что буфер кончается.

ЕМ>Почему очередь событий от устройств ввода должна быть исключением? Лишь потому, что памяти много?

Потому что.. legacy. наследие алфавитно-цифровых терминалов соединенных с (многопользовательскими) мэйнфреймами каналами 1200бод. из тех времен, когда можно было быстро слепой печатью набрать (в черный экран) несколько килобайт текста, а увидеть вывод их на дисплей (по два символа в минуту) после перекура.

SK>>А браузер не перестал. это одна из вкладок в нем "немного задумалась". Сам браузер все вовремя принимает и снаружи, со стороны ОС, выглядит совсем как живой.

ЕМ>Если браузер забирает сам, то эту задачу следует переложить на него. По уму, обычная кнопка, по которой кликнули, должна автоматически становиться неактивной до тех пор, пока клик не будет обработан. Этакий аналог подавления дребезга в схемотехнике.

Мне нравится эта идея. Она приведет к массовым расстрелам и геноциду по признаку "принадлежности к социальной группе" frontend-bsckend js developer.
/шутка/
потому что активность/неактивность кнопки на веб странице давно уже ушла из под контроля браузера в ассинхронные интерактивные js frameworks, в которых никто не знает кто за что отвечает и почему оно работает так.

SK>>очередь быстрый примитивный протокол без подтверждения и обратной связи.
ЕМ>И подтверждением, и обратной связью является извлечение элемента из очереди клиентом.

Ок. с точки зрения ОС (один разработчик) -браузер быстро извлек элемент и ничего делать не надо.
С точки зрения браузера (другой разработчик) событие быстро передано в (веб страницу) и ничего делать не надо,
С точки зрения 100500мб js спагетти веб страницы (неопределенный круг лиц, несколько групп разработчиков) событие быстро получено и обработано локально и передано на серверы (несколько)
С точки зрения серверов (неопределенный круг лиц, несколько групп разработчиков) событие получено, обработано или находится в работе..
С точки зрения браузера ..

Что делать браузеру когда/если элемент (кнопка) асинхронно отрисовывается в зависимости от ответов нескольких серверов?

что делать, когда(всегда) реальный пользователь находится в реальных условиях реального мира
у пользователя не топовое устройство с ограниченным объемом памяти. (а не 256gb core9extrem как у разработчика).
у пользователя ограниченный (3мбит эффективной пропускной способности) канал связи (а не 100Гбпс как у разработчика).
у пользователя (в данную минуту) не долетают пакет до одного из серверов. (сервер не стоит под тумбой стола),

а без всего это у кнопка не отрисовывается lgbtRGB градиент фона.

Делаем кнопку не активной?

SK>>Система, которая принимает решение за пользователя (хотя бы и на уровне какую кнопку нажать а какую не нужно) будет утилизирована вместе с её разработчиком.
ЕМ>Еще два раза "ха".

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

SK>>что по этому поводу говорят разработчики FarManager, например?
ЕМ>Не интересовался, поскольку в FAR Manager с таким не сталкивался. Что там нужно сделать, чтобы это увидеть?

Попытаться выполнить долгую операцию в комбинации с вводом.
Например, вставить в редактор из буфера обмена большой объем текста, хоткеями сохранить, закрыть, в другой панели перейти к следующему файлу/поскролить список. Или тем же FAR что-то сделать по сети (очень тормозной плагин в части samba) с медленным хостом.
и сразу же переключится в другое окно. тогда видно что far несколько минут пытается все это выполнять, хотя фокус ввода давно ушел в другое окно и туда все приходит вовремя.
Хотя в других приложениях очередь ввода обрывается на операции на которой произошло переключение и не успевшие выполнится к этому моменту хоткеи дропаются. т.е. после возврата в это окно их нужно повторять (отчего в пальцах возникает ощущение дежавю и мышечно-психологический дискомфорт, буквально паническая атака "я дал команду, почему она не выполнилась! что сломалось?!").

Все проблемы от жадности и глупости

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

Вот откуда там снова возникает этот диалог? Если он системный, то должен закрываться автоматически. Или нынче приложениям принято рисовать стопку всех возможных окон одно на другом, перерисовывая их по мере использования?