Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 112
Mожно устранить, изменив параметр ускорения курсора, или поставить на Mac другую операционную систему
Внезапно!
Может проще с помощью торсионных полей отправить пользователя на 32мс в будущее? :)
Да таким способом можно радикально производительность всей системы повысить. Правда, ежемесячные счета будут приходить чаще :)
Но это же невозможно. Как известно — торсионные поля — это поля четвёртого порядка. Так что в будущее можно отправить максимум на два в степени четыре — на 16 мс. Это бы конечно помогло, но учитывая сложность реализации — проще поставить другую операционную систему.
Кстати, неплохая мысль — экстраполировать положение курсора на 32 мс вперёд. В самом начале движения, конечно, будет 32-милисекундный лаг, зато потом курсор на гладких участках траектории будет достаточно близко к ожидаемому месту.
Что-то я ему не верю. Подвигал тачпадом на стоящем слева макбуке. Подвигал мышкой на стоящем справа макмини. Что-то незаметно там задержки. И в третью диаблу вчера вечером играл — тоже не замечал. Вообщем-то 32 мс это дофига как много, должно быть заметно невооруженным глазом.
То же смое. Но киселя не наблюдаю. Возможно, спецэффект совсем не в ядре/windowserver и зависит от чего-то другого?
Может дело в том, что расстояние, на которое перемещается курсор, зависит от скорости движения мыши или пальца по тачпаду/трекпаду? Такое свойство вообще есть в других ОС?
В Ubuntu вроде бы точно было.
В «других ОС» оно минимум десять лет как есть
www.microsoft.com/taiwan/whdc/archive/pointer-bal.mspx
www.microsoft.com/taiwan/whdc/archive/pointer-bal.mspx
Экспериментируя с хакинтошем заметил такое поведение, списал на непривычность.
А у коренных макинтошевцев наверное просто мозг приспосабливается
А у коренных макинтошевцев наверное просто мозг приспосабливается
Чесгря «мышь как в киселе» я замечал только на блютузных мышах(не только в маке, под виндой тоже), либо когда игрался в винде под параллелсами(там-то понятно что лаги от виртуалки).
В случае с блютузом решается многими способами, в зависимости от причины — вайфай на другие каналы перевесить чтоб не мешал, дрова поменять если есть альтернативы, и т.п. ну и радикальный вариант сменить мышь на неблютузную.
В маке больше иногда подбешивает другой лаг с клавиатурой: когда машина чем-то фоновым загружена, например перепаковкой видео, часто наблюдается такой интересный эффект: печатаешь например новый коммент на хабре, тыкаешь мышью в поле ввода, жмакаешь Cmd+пробел для переключения на русский, и сходу начинаешь писать текст. В результате потом видишь текст, в котором первые несколько символов(7-15) на англицкой раскладке, остальное на русском.
Такое ощущение, что комбинация Cmd+пробел при наборе падает не в тот же стек, что остальные одиночные нажатия клавиш, либо обрабатывается системой асинхронно, в результате чего срабатывает с запозданием. В винде такого не наблюдал ни разу.
Но это весьма нечастый эффект. На незагруженной машине не заметно. Однако на старом маке(late 2006) под леопардом было и без нагрузки одно время. После очередной заплатки там исчезло.
В случае с блютузом решается многими способами, в зависимости от причины — вайфай на другие каналы перевесить чтоб не мешал, дрова поменять если есть альтернативы, и т.п. ну и радикальный вариант сменить мышь на неблютузную.
В маке больше иногда подбешивает другой лаг с клавиатурой: когда машина чем-то фоновым загружена, например перепаковкой видео, часто наблюдается такой интересный эффект: печатаешь например новый коммент на хабре, тыкаешь мышью в поле ввода, жмакаешь Cmd+пробел для переключения на русский, и сходу начинаешь писать текст. В результате потом видишь текст, в котором первые несколько символов(7-15) на англицкой раскладке, остальное на русском.
Такое ощущение, что комбинация Cmd+пробел при наборе падает не в тот же стек, что остальные одиночные нажатия клавиш, либо обрабатывается системой асинхронно, в результате чего срабатывает с запозданием. В винде такого не наблюдал ни разу.
Но это весьма нечастый эффект. На незагруженной машине не заметно. Однако на старом маке(late 2006) под леопардом было и без нагрузки одно время. После очередной заплатки там исчезло.
О, я думал у меня одного такой глюк. У меня и другие управляющие сочетания иногда с запозданием срабатывают, если машина загружена и текст набираешь очень быстро.
Лаг при переключении раскладки часто имел и в винде — ХР и 7, обычно при печати в браузере Firefox. Последнее время пользуюсь хромом, и проблему, вроде бы, не наблюдаю.
Лаг с переключением и кисельную мыш наблюдаю вот уже 5 лет :)
Какая мышь-то у вас? У меня Logitech VX Nano, радиомышь не блютуз.
Я не утверждаю, что эффекта «кисельной мыши» не существует в принципе.
Более того, я даже практически уверен в том, что это вполне вероятно, и даже имею гипотезу на этот счет(ясен пень я не уверен в ее абсолютной правдивости).
Мне кажется, что проблемы не в драйверах, и вообще не в низкоуровневых слоях системы, а как раз таки на высоких уровнях близко к UI.
Как знают разработчики под Apple, в документации к Objective-C очень настаивается, что информация между объектами передается не с помощью методов, а сообщениями. При чем при вроде бы общей их похожести разница есть не только в синтаксисе, но и во внутренней кухне. Я сильно подозреваю, что одно из основных отличий сообщений от методов — асинхронность доставки(если объекты лежат не на одном уровне/слое). Что в принципе может объяснить оба обсуждаемых нами глюка — и непоследовательность обработки разноуровневых сообщений клавиатуры, и задержки в обработке «мышиных» движений.
Или, что еще более вероятно, проблема скорее всего составная, то есть описанная мною гипотеза — не единственная причина всех этих «странностей», а только часть более комплексной причины.
Точно те же причины могут быть у пользователя diamant в комменте чуть выше с браузером Firefox. Только тут уже не система, а сам браузер может как-то по особенному работать с мышью: стекировать внутри себя ее события, чрезмерно следить за движениями и обрабатывать их с повышенным «вниманием»(например пытаться непрерывно ловить «жесты»), ну и т.п. Я думаю, есть смысл открыть параллельно с Firefox еще и менеджер задач и последить за тем, как он жрет процессор, активно двигая мышью в это время над активным окном Firefox. Если он слишком неоптимизированно следит за мышью — будет видно сразу — процент загрузки проца будет сремиться вверх.
И еще вспомнил одну изредка проскакивающую странность. Жесты трекпада. При «подзагруженной» системе иногда бывает, что перестает обрабатываться какой-нибудь один жест. Или два.
Например тремя пальцами влево/вправо работает переход между пространствами(экранами), а те же три пальца вверх для вызова Mission Control — не работают. При этом Mission Control без проблем вызывается «горячей клавишей» либо «замапленной» кнопкой мыши. И переход между экранами «хоткеями» работает. Что интересно, данный глюк не зависит от количества пальцев. Может не работать один из трехпальцевых жестов, либо например прокрутка двумя пальцами не пашет, а трехпальцевые жесты все работают, и прокрутка колесом мыши тоже ОК.
Обычно это ненадолго, на полминуты-минуту, потом все восстанавливается как ни в чем не бывало.
Я не утверждаю, что эффекта «кисельной мыши» не существует в принципе.
Более того, я даже практически уверен в том, что это вполне вероятно, и даже имею гипотезу на этот счет(ясен пень я не уверен в ее абсолютной правдивости).
Мне кажется, что проблемы не в драйверах, и вообще не в низкоуровневых слоях системы, а как раз таки на высоких уровнях близко к UI.
Как знают разработчики под Apple, в документации к Objective-C очень настаивается, что информация между объектами передается не с помощью методов, а сообщениями. При чем при вроде бы общей их похожести разница есть не только в синтаксисе, но и во внутренней кухне. Я сильно подозреваю, что одно из основных отличий сообщений от методов — асинхронность доставки(если объекты лежат не на одном уровне/слое). Что в принципе может объяснить оба обсуждаемых нами глюка — и непоследовательность обработки разноуровневых сообщений клавиатуры, и задержки в обработке «мышиных» движений.
Или, что еще более вероятно, проблема скорее всего составная, то есть описанная мною гипотеза — не единственная причина всех этих «странностей», а только часть более комплексной причины.
Точно те же причины могут быть у пользователя diamant в комменте чуть выше с браузером Firefox. Только тут уже не система, а сам браузер может как-то по особенному работать с мышью: стекировать внутри себя ее события, чрезмерно следить за движениями и обрабатывать их с повышенным «вниманием»(например пытаться непрерывно ловить «жесты»), ну и т.п. Я думаю, есть смысл открыть параллельно с Firefox еще и менеджер задач и последить за тем, как он жрет процессор, активно двигая мышью в это время над активным окном Firefox. Если он слишком неоптимизированно следит за мышью — будет видно сразу — процент загрузки проца будет сремиться вверх.
И еще вспомнил одну изредка проскакивающую странность. Жесты трекпада. При «подзагруженной» системе иногда бывает, что перестает обрабатываться какой-нибудь один жест. Или два.
Например тремя пальцами влево/вправо работает переход между пространствами(экранами), а те же три пальца вверх для вызова Mission Control — не работают. При этом Mission Control без проблем вызывается «горячей клавишей» либо «замапленной» кнопкой мыши. И переход между экранами «хоткеями» работает. Что интересно, данный глюк не зависит от количества пальцев. Может не работать один из трехпальцевых жестов, либо например прокрутка двумя пальцами не пашет, а трехпальцевые жесты все работают, и прокрутка колесом мыши тоже ОК.
Обычно это ненадолго, на полминуты-минуту, потом все восстанавливается как ни в чем не бывало.
Я сильно подозреваю, что одно из основных отличий сообщений от методов — асинхронность доставки(если объекты лежат не на одном уровне/слое). Что в принципе может объяснить оба обсуждаемых нами глюка — и непоследовательность обработки разноуровневых сообщений клавиатуры, и задержки в обработке «мышиных» движений.
Увы, нет. Я в свое время тщательнейшим образом изучал этот вопрос. По факту, в скомпилированной программе каждому сообщению присваивается уникальный числовой идентификатор и «отправка сообщения» соответствует поиску в целевом объекте метода-обработчика по этому идентификатору и его вызов. Там все достаточно быстро, не асинхронно и по скорости не сильно отличается от вызова метода по vtable в том же C++. Сообщения, они, к сожалению, не для асинхронности сделаны, а для динамики времени выполнения — возможности отправить сообщение для которого нет метода-обработчика, возможность отправить сообщение по имени (сначала по имени ищется идентификатор, после чего задача сводится к предыдущей).
Я сам в свое время очень надеялся что там есть асинхронность, очереди и многопоточность. Но увы :(.
Возможно и так. Но…
А вы только в своей программе это проверяли, или в системных событиях тоже?
Я не зря намекнул на асинхронность только при разноуровневых объектах. Внутри одной программы системе нет смысла диспетчеризировать сообщения непоследовательно. В разных потоках вы тоже не поймете что к чему, поскольку потоки и не должны быть синхронными при любом раскладе.
Однако, думаю в чем-то вы правы. Ок, может быть я поспешил с сообщениями. Проблема может быть не в самой системе сообщений, а только в некоторых нюансах. Возможно даже просто в архитектуре конкретного(маковского) GUI слоя.
Ща приведу пример(я правда не оратор, могу сумбурно описать, смешав людей с конями вместе, но надеюсь мою основную мысль вы поймете):
Вам знакома такая конструкция?:
Обращаю ваше внимание на waitUntilDone:YES.
В принципе такое дело есть везде, и в виндовз тоже.
Но! Когда читаешь документацию по WinAPI, в принципе понимаешь что система внутри построена совсем не на объектах — там сплошные функции и структуры, что в общем-то и правильно — ООП в общем представлении как таковое есть удобство для программиста, но для системы совершенно пофиг — все-равно поднаготная ничем не отличается от обычных функций со структурами, кроме большего жора памяти на объектную обвязку и более длинных цепочек вызовов. И даже для программиста при вроде бы большей простоте написания кода объекты могут затруднять «визуальную» отладку(без спецсредств) из-за большего «наслоения» этого самого кода.
Как все построено в маке, я к сожалению еще не очень хорошо понимаю, не профи я, только начинаю учить )
Однако я довольно внимательно изучал историю развития Apple, и хорошо помню, что текущие макоси построены на наработках NeXT, а об этой конторе во всех историях описывается, как сильно они(Стив и Ko) загонялись на объектной ориентированности всей системы. Что по сути в общем-то замечательно, но зная увлеченность этих людей идеей(да что уж там, зная себя в моменты увлеченности )))), можно предположить, что они могли местами и переборщить.
Так вот, вернемся к waitUntilDone:YES. По сути это не что иное, как обмен информацией между разными потоками(или «нитями»), и конкретно waitUntilDone:YES рулит синхронностью/асинхронностью вызова. И если предположить, что сканкоды клавиатуры от драйвера входят в обработчик GUI, который отправляет обычные нажатия в один поток(объект?), но просекая «горячую клавишу», отправляет ее обработку в другой поток(объект?), установив waitUntilDone:NO, вполне может получиться такая хрень, что она будет обрабатываться дольше, чем предполагается. В результате имеем ситуацию, при которой в момент переключения языка ГУЯми чудесным образом уже успели проскочить в конечную программу и обработаться еще несколько нажатий «обычных» кнопок.
Как-то так. Я по-прежнему ничего не утверждаю. Я не знаю наверняка. Просто теоретизирую.
Я делал серверные демоны, эмулирующие многопоточность, работая фактически в одном потоке. И много раз видел, как ответы на комманды приходят асинхронно совершенно не в той последовательности, в которой отправлялись. Именно из-за разного количества времени, потраченного на их обработку. Вот только в моем случае это не могло породить никаких глюков — в этой асинхронности и была цель той системы. А здесь(в МакОСи) могли просто что-то не продумать в архитектуре.
А вы только в своей программе это проверяли, или в системных событиях тоже?
Я не зря намекнул на асинхронность только при разноуровневых объектах. Внутри одной программы системе нет смысла диспетчеризировать сообщения непоследовательно. В разных потоках вы тоже не поймете что к чему, поскольку потоки и не должны быть синхронными при любом раскладе.
Однако, думаю в чем-то вы правы. Ок, может быть я поспешил с сообщениями. Проблема может быть не в самой системе сообщений, а только в некоторых нюансах. Возможно даже просто в архитектуре конкретного(маковского) GUI слоя.
Ща приведу пример(я правда не оратор, могу сумбурно описать, смешав людей с конями вместе, но надеюсь мою основную мысль вы поймете):
Вам знакома такая конструкция?:
[delegate performSelectorOnMainThread:selector withObject:object waitUntilDone:YES];Обращаю ваше внимание на waitUntilDone:YES.
В принципе такое дело есть везде, и в виндовз тоже.
Но! Когда читаешь документацию по WinAPI, в принципе понимаешь что система внутри построена совсем не на объектах — там сплошные функции и структуры, что в общем-то и правильно — ООП в общем представлении как таковое есть удобство для программиста, но для системы совершенно пофиг — все-равно поднаготная ничем не отличается от обычных функций со структурами, кроме большего жора памяти на объектную обвязку и более длинных цепочек вызовов. И даже для программиста при вроде бы большей простоте написания кода объекты могут затруднять «визуальную» отладку(без спецсредств) из-за большего «наслоения» этого самого кода.
Как все построено в маке, я к сожалению еще не очень хорошо понимаю, не профи я, только начинаю учить )
Однако я довольно внимательно изучал историю развития Apple, и хорошо помню, что текущие макоси построены на наработках NeXT, а об этой конторе во всех историях описывается, как сильно они(Стив и Ko) загонялись на объектной ориентированности всей системы. Что по сути в общем-то замечательно, но зная увлеченность этих людей идеей(да что уж там, зная себя в моменты увлеченности )))), можно предположить, что они могли местами и переборщить.
Так вот, вернемся к waitUntilDone:YES. По сути это не что иное, как обмен информацией между разными потоками(или «нитями»), и конкретно waitUntilDone:YES рулит синхронностью/асинхронностью вызова. И если предположить, что сканкоды клавиатуры от драйвера входят в обработчик GUI, который отправляет обычные нажатия в один поток(объект?), но просекая «горячую клавишу», отправляет ее обработку в другой поток(объект?), установив waitUntilDone:NO, вполне может получиться такая хрень, что она будет обрабатываться дольше, чем предполагается. В результате имеем ситуацию, при которой в момент переключения языка ГУЯми чудесным образом уже успели проскочить в конечную программу и обработаться еще несколько нажатий «обычных» кнопок.
Как-то так. Я по-прежнему ничего не утверждаю. Я не знаю наверняка. Просто теоретизирую.
Я делал серверные демоны, эмулирующие многопоточность, работая фактически в одном потоке. И много раз видел, как ответы на комманды приходят асинхронно совершенно не в той последовательности, в которой отправлялись. Именно из-за разного количества времени, потраченного на их обработку. Вот только в моем случае это не могло породить никаких глюков — в этой асинхронности и была цель той системы. А здесь(в МакОСи) могли просто что-то не продумать в архитектуре.
У Windows 7 с этим не лучше. Если нажать Shift + Alt и сразу начать набирать текст, раскладка может не переключится. Убил бы Майкрософт за это.
Раскладка вообще не переключается, или переключается с задержкой?
Понимаю, бесят оба глюка, но тем не менее разница между ними принципиальна.
Понимаю, бесят оба глюка, но тем не менее разница между ними принципиальна.
Совсем. Главное иногда все нормально, а иногда просто ужас. Бесит когда пишешь какой-нибудь код и часто переключаешься туда-сюда.
Самое обидное что специально это не получается повторить.
Самое обидное что специально это не получается повторить.
В вашем случае к сожалению затруднительно даже назвать виновных. Именно потому, что событие клавы не доставляется вообще.
Это может быть Майкрософт, это может быть производитель клавиатуры, это может быть производитель чипсета или драйвера, обрабатывающих USB или PS/2 подключение клавиатуры. Чип самой клавиатуры, грязь на контактах, драйвер совершенно третьей стороны, мешающий доставке событий клавиатуры, всякие программы типа пунтосвитчера(не обязательно он, любая программа, реализующая глобальный перехват клавиатуры на предмет своих глобальных хоткеев).
В маке с этим проще — событие хоткея доставляется, но позже, не вовремя. То есть глюк в самой операционке, а не в железе уже налицо.
Это может быть Майкрософт, это может быть производитель клавиатуры, это может быть производитель чипсета или драйвера, обрабатывающих USB или PS/2 подключение клавиатуры. Чип самой клавиатуры, грязь на контактах, драйвер совершенно третьей стороны, мешающий доставке событий клавиатуры, всякие программы типа пунтосвитчера(не обязательно он, любая программа, реализующая глобальный перехват клавиатуры на предмет своих глобальных хоткеев).
В маке с этим проще — событие хоткея доставляется, но позже, не вовремя. То есть глюк в самой операционке, а не в железе уже налицо.
1. Воспроизводится и на домашней, и на ноутбучной клавиатуре. Наблюдается только в Windows 7, в висте не было.
2. Домашняя клавиатура USB, ноутбучная — PS/2
3. Чипы и чипсеты абсолютно разные.
4. С другими кнопками проблем срабатывания не было.
5. Пунтосвитчеров не стоит. На ноутбуке стоит родной фильтр.
Есть слабая надежда что в Windows 8 это испрвят.
2. Домашняя клавиатура USB, ноутбучная — PS/2
3. Чипы и чипсеты абсолютно разные.
4. С другими кнопками проблем срабатывания не было.
5. Пунтосвитчеров не стоит. На ноутбуке стоит родной фильтр.
Есть слабая надежда что в Windows 8 это испрвят.
Хм…
Кстати, во многих клавиатурах их собственный чип не обрабатывает более какого-то количества одновременных нажатий. Возможно у вас и там и там подобные. В смысле я ваш глюк встречал раньше и сам.
Попытайтесь повторить этот глюк, попробовав переключить раскладку в то время, когда нажата любая алфавитно-цифровая клавиша, либо две таких клавиши. При чем сначала попробуйте клавиши рядом, например Z и X, а потом разнесенные, типа Z и U.
Не смотря на то что контроллер так или иначе должен такие нажатия отработать последовательно, некоторые контроллеры бывает «залипают» в таких ситуациях.
Ну соответственно и глюк проявляется из-за этого только во время быстрого набора текста(нажал следующую клавишу, а предыдущую еще не отпустил). При чем не во всеми произвольно выбранными клавишами срабатывает. У контроллера как правило кнопки поделены группами(особенности внутренней кухни клавиатур), каждая группа опрашивается «своими» ногами контроллера.
Часто по 9 клавиш в группе. Например квадратный блок кнопок QWEASDZXC вполне может быть такой группой. В таком случае контроллер может «терять» одновременные нажатия в пределах одной группы, но свободно всегда обрабатывать нажатия между разными группами.
В любом случае я вас понимаю. Такие глюки бесят, это да…
Кстати, во многих клавиатурах их собственный чип не обрабатывает более какого-то количества одновременных нажатий. Возможно у вас и там и там подобные. В смысле я ваш глюк встречал раньше и сам.
Попытайтесь повторить этот глюк, попробовав переключить раскладку в то время, когда нажата любая алфавитно-цифровая клавиша, либо две таких клавиши. При чем сначала попробуйте клавиши рядом, например Z и X, а потом разнесенные, типа Z и U.
Не смотря на то что контроллер так или иначе должен такие нажатия отработать последовательно, некоторые контроллеры бывает «залипают» в таких ситуациях.
Ну соответственно и глюк проявляется из-за этого только во время быстрого набора текста(нажал следующую клавишу, а предыдущую еще не отпустил). При чем не во всеми произвольно выбранными клавишами срабатывает. У контроллера как правило кнопки поделены группами(особенности внутренней кухни клавиатур), каждая группа опрашивается «своими» ногами контроллера.
Часто по 9 клавиш в группе. Например квадратный блок кнопок QWEASDZXC вполне может быть такой группой. В таком случае контроллер может «терять» одновременные нажатия в пределах одной группы, но свободно всегда обрабатывать нажатия между разными группами.
В любом случае я вас понимаю. Такие глюки бесят, это да…
>> PS/2 обрабатывает не более 4-х нажатых клавиш одновременно (аппаратное ограничение)
С чего вы взяли? Пруф есть? Я не исключаю такой вероятности, но чесгря впервые слышу о таком аппаратном ограничении именно интерфейса PS/2. PS/2 протокол похож на MIDI — он тупо передает хосту события нажатий, отпусканий и повторов удерживаемых клавиш(с событиями мыши в общем-то та же фигня). Не вижу ни одной причины ограничивать количество одновременно нажатых. Так что если таковое и имеется, то это косяки контроллера клавиатуры с наибольшей вероятностью(с наименьшей — косяки драйвера со стороны хоста). То есть тупо сэкономил производитель клавы.
В протоколе есть два узких места:
1. мало кто реализует покторные запрос/отправку данных при ошибках в канале(чтобы исключить зацикливание мусора). Из-за этого некоторые события могут теряться.
2. Клавиши-модификаторы не генерируют повторы нажатий. Только нажатие/отпускание. В результате чего при потере события нажатия оно не восстановимо, как у обычной алфавитно-цифровой клавиши.
>> Вычисленный вами блок это и есть зависимость матрицы клавиатуры.
своими словами "(особенности внутренней кухни клавиатур)" я не стал лезть в дебри.
а вы меня неявно нубом обозвали )))))
С чего вы взяли? Пруф есть? Я не исключаю такой вероятности, но чесгря впервые слышу о таком аппаратном ограничении именно интерфейса PS/2. PS/2 протокол похож на MIDI — он тупо передает хосту события нажатий, отпусканий и повторов удерживаемых клавиш(с событиями мыши в общем-то та же фигня). Не вижу ни одной причины ограничивать количество одновременно нажатых. Так что если таковое и имеется, то это косяки контроллера клавиатуры с наибольшей вероятностью(с наименьшей — косяки драйвера со стороны хоста). То есть тупо сэкономил производитель клавы.
В протоколе есть два узких места:
1. мало кто реализует покторные запрос/отправку данных при ошибках в канале(чтобы исключить зацикливание мусора). Из-за этого некоторые события могут теряться.
2. Клавиши-модификаторы не генерируют повторы нажатий. Только нажатие/отпускание. В результате чего при потере события нажатия оно не восстановимо, как у обычной алфавитно-цифровой клавиши.
>> Вычисленный вами блок это и есть зависимость матрицы клавиатуры.
своими словами "(особенности внутренней кухни клавиатур)" я не стал лезть в дебри.
а вы меня неявно нубом обозвали )))))
Что и требовалось доказать.
По-прежнему ни одного намека на аппаратные ограничения интерфейса PS/2.
Либо контроллер клавы, либо хост, как вы сейчас написали.
По-прежнему ни одного намека на аппаратные ограничения интерфейса PS/2.
Либо контроллер клавы, либо хост, как вы сейчас написали.
Современные ОС используют прерывания BIOS в Protected Mode? — не верю! Всю жизнь был уверен, что они читают порт клавиатуры.
Все верно, то, что выше написано про BIOS — высококачественный бред. Никакие прерывания BIOS в защищенном режиме не используются и использоваться не могут, т.к. это, грубо говоря, 16-битный код реального режима, который в 32- или 64-битном исполняться в принципе не может.
Более того, первые 0x20 векторов прерываний (включая используемое биосом для клавиатуры int 0x09) в защищенном режиме x86 вообще зарезервированы для использования процессором, и при переходе в этот режим контроллер прерываний перепрограммируется так, что аппаратные прерывания начинаются с 0x20 или выше:
sysbin.com/files/lowlevel/entering_pm.htm
Более того, первые 0x20 векторов прерываний (включая используемое биосом для клавиатуры int 0x09) в защищенном режиме x86 вообще зарезервированы для использования процессором, и при переходе в этот режим контроллер прерываний перепрограммируется так, что аппаратные прерывания начинаются с 0x20 или выше:
sysbin.com/files/lowlevel/entering_pm.htm
Часто попадалось такое и на XP, и на 7 (непереключение раскладки). Даже где то, вроде на баше шутка была, что мол, чтобы переключить раскладку в windows, нужно предварительно укоризненно посмотреть на индикатор языка.
Совсем. Главное иногда все нормально, а иногда просто ужас. Бесит когда пишешь какой-нибудь код и часто переключаешься туда-сюда.
Уже много лет как отказался от переключения Ctr+Shift (Alt+Shift) и сипользую для каждой расладки одну собственную кнопочку. Я остановился на Ctrl(left) — EN, Ctrl(right) — RU, LShift+RShift — UA. Похожий способ ипользовался мной еще под DOS посредством keyrus или типа того. Попробуйте, может и Вам понравится.
Не замечал, вообще ниразу, Скорее просто не переключится, чем переключится с задержкой. Или у меня пальцы не такие резвые.
Это не только на Windows 7 наблюдается. Уже очень давно замечаю.
Вообще, я свой кисель вылечил бесплатной Mouse Acceleration Preference Pane, а можно MouseWorks. Правда под киселем я понимаю кривую ускорения у макоси свою, отличную от виндовой.
Это 32/1000 секунды. Вы уверены, что подергав мышкой заметите это на глаз?
какой вывод? — ваши глаза невооруженные
Это на самом деле дело привычки. Когда-то давно проходил Quake 2 на 10 FPS, и ничего, тоже казалось что все нормально.
Мозг — ко всему адаптируется, и если не пробовать что-то другое, никогда и не поймет что может быть по другому.
Мозг — ко всему адаптируется, и если не пробовать что-то другое, никогда и не поймет что может быть по другому.
Тут вопрос не о привычке, а о комфорте.
Я же не просто так говорил про право и лево. По центру у меня вполне себе винда — так что есть с чем сравнивать. И вот, сравнивая, я в упор не вижу никакой разницы. И это заставляет меня не верить автру оригинальной статьи. BTW, если внимательно прочитать к ней комментарии, то там мнения также разделились. У кого-то лаги есть, а у кого-то нет. И это также склоняет меня к мысли, что причина там совсем не в страшном ядерном баге, а в чем-то другом.
Аналогично. Более того — не замечаю никакой разницы между поведением мыши в Linux и Windows, и ими же, запущенными в VMWare Fusion на маке.
Есть там задержка.
Я еще году в 2005-м где-то сказал это маковому продавцу-ушечесу. У Вас в маках говорю курсор с задержкой ползает.
Ну а они как всегда — у нас все круто, никаких задержек и вообще сгинь отседа неверный… С тех пор я на маки гляжу, слюни пускаю, а пересесть не могу… Не только из за курсора, но это уже другой разговор.
Я еще году в 2005-м где-то сказал это маковому продавцу-ушечесу. У Вас в маках говорю курсор с задержкой ползает.
Ну а они как всегда — у нас все круто, никаких задержек и вообще сгинь отседа неверный… С тех пор я на маки гляжу, слюни пускаю, а пересесть не могу… Не только из за курсора, но это уже другой разговор.
Хочу заметить, что после перехода на мониторы с 120FPS, обычные 60FPS уже кажутся ощутимо тормознутыми. Так что даже 10ms задержки весьма ощутимы.
Так вот почему после GNOME в Mac OS X мышь кажется неуправляемой…
Не по этому. Вот почему: ilyabirman.ru/meanwhile/2008/10/16/1/
Интересно, как они это высчитали?
Ну вот зачем вы это написали? Теперь буду обращать внимание :(
Если бы не статья — никогда не подумал бы об этом. При этом часто переключаюсь между виндой и макосью.
Замечал в COD4 и CSS задержку, не понимал в чем соль.
Думал что проблема в маковском ускорении мыши.
Думал что проблема в маковском ускорении мыши.
*звук бьющегося стекла*
аа. я знал, что она там есть. меня ещё дико бесило это у друга на маке! ещё там какая-то фигня с точностью, если очень медленно водить курсор около какого-то элемента, то движения идут как-то рывками.
Играю иногда в CS:S на трекпаде — не замечал ничего такого. А вот тупняки и прыжки иногда бывают и сильно бесят. Аж перелогиниваться приходится.
хотел бы я посмотреть, как играют на трекпаде: никогда нормально не получалось, хотя и очень хотелось.
Я знал, я знал! Когда переключился на мак, постоянно доставало, я и кривую ускорения изменял, но такого поведения как в видне\убунту так и не добился.
Потом привык.
Потом привык.
Это наверняка проблема композитинга.
Я играю в музыкальную игру osu!, где каждая милисекунда задержки ощущается. Под windows она идет идеально, а под linux звук всегда запоздает на 15мс. Что я только ни делал, крутил alsa, крутил wine, использовал oss — все фигня. Эти 15мс очень сильно ощущаются. У друга с asus xonar никаких задержек, оно и понятно.
Вот пример игры, если кто-то сомневается в ощущениях отклонения 15мс.
www.youtube.com/watch?v=Rzc_KFDEiso
Я играю в музыкальную игру osu!, где каждая милисекунда задержки ощущается. Под windows она идет идеально, а под linux звук всегда запоздает на 15мс. Что я только ни делал, крутил alsa, крутил wine, использовал oss — все фигня. Эти 15мс очень сильно ощущаются. У друга с asus xonar никаких задержек, оно и понятно.
Вот пример игры, если кто-то сомневается в ощущениях отклонения 15мс.
www.youtube.com/watch?v=Rzc_KFDEiso
www.youtube.com/watch?v=khe9eJ1gIlA
Вот игра реального человека.
Вот игра реального человека.
Вот это психодел! ))
Собственно, на десктопе я играл в нее либо под виндой, либо в виртуалке, втыкал клавиатуру и мышку в ps/2, устанавливал 1000гц обновление на ps/2 портах, и в наушниках, т.к. десинхронизация в 3-5мс между нажатием клавиши на клавиатуре(а во время игры вы по ней долбите) отвлекает, а в наушниках не слышно, и организм как-то сам подстраивается.
Хоть я и линуксятник, мне очень нравится, как майкрософт сделал свой композитинг(аеро). Ничего не тормозит, игры идут так же плавно, как и без композитинга, никаких задержек или проседаний fps. Пользователем linux и (наверное, точно не знаю) mac os о таком только мечтать остается.
Хоть я и линуксятник, мне очень нравится, как майкрософт сделал свой композитинг(аеро). Ничего не тормозит, игры идут так же плавно, как и без композитинга, никаких задержек или проседаний fps. Пользователем linux и (наверное, точно не знаю) mac os о таком только мечтать остается.
Человека? Да это же японец! Наверняка киборг ;)
Подрыгай мышкой — заработай эпилепсию?
А звук под виндой через ASIO? Если обычный — там 50мс минимум.
ASIO не позволяет микшировать? Тогда нет, не asio. Скачайте, попробуйте сами. Игра 25мб весит.
osu.ppy.sh
osu.ppy.sh
Вот оно в чём дело. А я думаю, почему меня в CS:S так дёргают.
Уже и мышь проводную подключил.
Уже и мышь проводную подключил.
Вон оно че, Петрович… К психиатру значит не пойдем, она внатуре сама тупила.
хорошее средство от кисельности мыши — ползунок скорости в system preferences на минимум, dpi мыши (если есть кнопка) на максимум.
Но 32 мс это видимо сосвсем отдельный лаг.
Но 32 мс это видимо сосвсем отдельный лаг.
Задержка 32 мс = 0,032 секунды. У человека среднее время реакции на визуальный сигнал составляет 0,2 секунды, а звуковой 0, 14, и в принципе не должны ощущать эту задержку. Или я чего-то не понимаю :)
Пинг прибавляется к этому среднему времени, поэтому ощущается.
В кваке разница в пинге в 32мс — ощутимое приемущество. На midi-клавиатуре при 32мс играть попадая в ритм уже не получится.
В кваке разница в пинге в 32мс — ощутимое приемущество. На midi-клавиатуре при 32мс играть попадая в ритм уже не получится.
Насколько я знаю, средняя реакция человека 20 мс == 0.02 секунды.
Поэтому, например, 120 FPS и выше нужно для приятной игры за компом.
Поэтому, например, 120 FPS и выше нужно для приятной игры за компом.
Интересно узнать, а я думал, что у меня все мыши просто тупят.
прошел Portal 2, Half-Life 2 на Magic Mouse — лагов не заметил
Как я поставил на макбук винду, или история одной мышки )
Приобрел мбп-17, поставил на него винду в отдельный раздел (не спрашивайте зачем, работать все равно буду на ней). Воткнул свою любимую logitech с микро usb-приемником-передатчиком. Все было хорошо, идеально двигался курсор. Чем больше работал (в этот же сеанс) тем больше начинал притормаживать курсор. Переткнул во второй usb — тоже самое. И в 3-й — тоже. Расстроился что usb болен, потому что переезжал с Вайо на котором два usb не работало из 3-х, очень хотелось это поменять. Воткнул майкрасофтовскую беспроводную. Тот же эффект. Отдал ноут в сервисный центр. Вердикт: проблемы не нашли, но можем так уж и быть поменять мать. Согласился.
Спустя 2.5 месяца вернули ноут (долговато, да), воткнул logitech, через 20 минут тоже самое. Расстроился окончательно. Пошел в магазин купил genius с рулеткой (чтобы провод вытягивать) — проводную собственно. Воткнул, отлично ездит. НО. Провода в таком genius около 40 см ), usb у макбука слева, а я правша. В итоге мак пошатывается на рулетке по центру, а мышь бьется о правую часть ноута. Расстроился опять.
Прочитал весь интернет, нашел на форуме околоэпловом обсуждения страдальцев похожих на меня — с майкрасофтами и logitech. Сходятся на мнении что это алюминевый корпус — плохо пропускает сигнал радио. И еще один человек в одном форуме упомянул что при некотором времени работы это возникает — т.е. при нагреве, именно тогда алюминий набирает максимум этого эффект. Прям как у меня. Расстроился.
Прочитал еще весь интернет. Поехал в магазин, купил меджик мауз! Приехал, приконектил. Винда с пол тычка распознала и поставила драйвера. Пользуюсь, сигнал не теряет. НО. Толи эти самые 35мс, толи блютуз пересекается с вайфай (есть такая проблема — я же весь интернет по этому поводу прочитал, да еще и каналы поменял — без толк), но мышка ездит иногда микрорывками, ощущение что обладает инертностью (руку остановил — курсор еще двигается), попасть в кнопку свернуть, или закрыть — сложнее не порядок чем моим логитеком. Вариантов нет. Расстроился надеюсь в последний раз. Пришел к выводу.
Пройдет годик, пора будет менять ноут. И не будет у меня больше никаких маков, со всеми их гемороями с мышами, с их клавиатурами без кнопки delete, и с кучей свободного места под эту кнопку, с их стартовым звуком «та-дам» откулючить который можно только поставив специальную программу «анти-та-дам», с отсутствием правого контрола, которым привык давно и прочно нажимать ctrl-enter, даже с их раскладкой которая не соответствует «обычной» виндовой.
И со всем их внешним видом, который не смотря ни на что — очень мне симпатичен. Для меня — мак не для работы, а для красоты получился.
Приобрел мбп-17, поставил на него винду в отдельный раздел (не спрашивайте зачем, работать все равно буду на ней). Воткнул свою любимую logitech с микро usb-приемником-передатчиком. Все было хорошо, идеально двигался курсор. Чем больше работал (в этот же сеанс) тем больше начинал притормаживать курсор. Переткнул во второй usb — тоже самое. И в 3-й — тоже. Расстроился что usb болен, потому что переезжал с Вайо на котором два usb не работало из 3-х, очень хотелось это поменять. Воткнул майкрасофтовскую беспроводную. Тот же эффект. Отдал ноут в сервисный центр. Вердикт: проблемы не нашли, но можем так уж и быть поменять мать. Согласился.
Спустя 2.5 месяца вернули ноут (долговато, да), воткнул logitech, через 20 минут тоже самое. Расстроился окончательно. Пошел в магазин купил genius с рулеткой (чтобы провод вытягивать) — проводную собственно. Воткнул, отлично ездит. НО. Провода в таком genius около 40 см ), usb у макбука слева, а я правша. В итоге мак пошатывается на рулетке по центру, а мышь бьется о правую часть ноута. Расстроился опять.
Прочитал весь интернет, нашел на форуме околоэпловом обсуждения страдальцев похожих на меня — с майкрасофтами и logitech. Сходятся на мнении что это алюминевый корпус — плохо пропускает сигнал радио. И еще один человек в одном форуме упомянул что при некотором времени работы это возникает — т.е. при нагреве, именно тогда алюминий набирает максимум этого эффект. Прям как у меня. Расстроился.
Прочитал еще весь интернет. Поехал в магазин, купил меджик мауз! Приехал, приконектил. Винда с пол тычка распознала и поставила драйвера. Пользуюсь, сигнал не теряет. НО. Толи эти самые 35мс, толи блютуз пересекается с вайфай (есть такая проблема — я же весь интернет по этому поводу прочитал, да еще и каналы поменял — без толк), но мышка ездит иногда микрорывками, ощущение что обладает инертностью (руку остановил — курсор еще двигается), попасть в кнопку свернуть, или закрыть — сложнее не порядок чем моим логитеком. Вариантов нет. Расстроился надеюсь в последний раз. Пришел к выводу.
Пройдет годик, пора будет менять ноут. И не будет у меня больше никаких маков, со всеми их гемороями с мышами, с их клавиатурами без кнопки delete, и с кучей свободного места под эту кнопку, с их стартовым звуком «та-дам» откулючить который можно только поставив специальную программу «анти-та-дам», с отсутствием правого контрола, которым привык давно и прочно нажимать ctrl-enter, даже с их раскладкой которая не соответствует «обычной» виндовой.
И со всем их внешним видом, который не смотря ни на что — очень мне симпатичен. Для меня — мак не для работы, а для красоты получился.
Опасная у Евгения фамилия — Зуев. Сантиметр вправо и можно нелепо поссориться.
Шел 2015 год, решил я поиграть в OSU! на свежеустановленом Хакинтоше.
Помню что-то взорвалось, как тут оказался не помню.
А я то думал, почему я попасть нормально не могу, даже в карты которые на S прохожу с закрытыми глазами мажу.
Помню что-то взорвалось, как тут оказался не помню.
А я то думал, почему я попасть нормально не могу, даже в карты которые на S прохожу с закрытыми глазами мажу.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Задержка курсора 32 миллисекунды в Mac OS X