Здравствуйте, Sinclair, Вы писали:
Ytz>>То самое меню в левом нижнем углу с надписью "Пуск". S>Это "то самое меню" реализовано в нескольких слоях слабо связанного кода. Если вас интересует не абстрактная логика, а возможность сделать конкретную реализацию, то надо разбираться с тем, из каких именно слоёв это состоит.
Без понятия как оно устроено, если как вы утверждаете, то оторвать руки разработчиком. Но откуда у вас такие сведения?
Ytz>>Зачем переписать? Опять фантазии? S>Тогда что вы предлагаете?
Ничего. Просто утверждаю, что реализовать асинхронные меню не только возможно, но и задача не сложная. Лично у меня опыт есть.
S>>>Я говорил, что это невозможно со стороны WinAPI. Ytz>>Таки нельзя асинхронный интерфейс сделать? Можно. Как оно сейчас устроено без понятия S>Вы понимаете разницу между WinAPI и Windows Explorer?
Глубокомысленно. Что сказать хотели?
S>>>Со стороны конкретного приложения, конечно, же, возможно. Я даже написал — как именно. И вы тщательно переписали тот же способ.
Ytz>>Да, да. Спасибо. Или наоборот? S>Принцип причинности подсказывает нам, что зависимое событие всегда происходит позже того, от которого оно зависит. Так что "или наоборот" не получится.
Тогда покажите, где вы это сказали, а я переписал.
Здравствуйте, Ytz, Вы писали:
Ytz>Без понятия как оно устроено, если как вы утверждаете, то оторвать руки разработчиком. Но откуда у вас такие сведения?
Ну, msdn.microsoft.com — адрес несекретный.
Ytz>Ничего. Просто утверждаю, что реализовать асинхронные меню не только возможно, но и задача не сложная. Лично у меня опыт есть.
Ещё раз поясняю: в конкретном приложении, для конкретного меню — да, ничего военного.
Починить единым махом все приложения, некоторые из которых портированы ещё со времён win3.1 — нет, невозможно.
Ytz>Глубокомысленно. Что сказать хотели?
Повторюсь: переписать Windows Explorer, реализовав асинхронность меню, можно. Починить WinAPI, не сломав все приложения — невозможно.
Ytz>Тогда покажите, где вы это сказали, а я переписал.
А, виноват — вы написали раньше.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, Ikemefula, Вы писали:
I>>Теоретически — можно. Но ведь нужно не просто асинхронный интерфейс, а качественный с т.з пользователя. Все асинхронные интерфейсы базирующиеся на Winapi есть УГ, тормозное и морозное и тому есть объяснения — Винда не гарантирует время отклика никоим образом. Как то так. Вот была бы винда ОС РВ где такая гарантия в наличии, можно было бы в легкую строить асинхронный интерфейс. I>>А так нет никакой гарантии, что система будет реагировать хотя бы за 0.5с, а для многих операций даже 0.1с это много, например всякие мышиные типа драг-дропа. I>>Чуть выше я давал расклад во что превращается Sleep(100) под нагрузкой, такие задержки для UI мягко говоря неприемлемы . S>Простите, это чушь. Практически — всё можно. В частности, протокол взаимодействия между контролом ListView и приложением был сделан с поддержкой некоторой асинхронности ещё в win95. Помните
чудесный фонарик, который шарил по фолдерам?
Помню, вот он и морозил зачастую даже при том, что в ём отсутствовала интерактивность. Морозил — значит до отрисовки дело не всегда и доходило.
S>Для меню, в принципе, можно было сделать то же самое. Надо было только принять волевое решение отказаться от обратной совместимости с Win16 (в котором паралельность была, мягко говоря, условностью), и сделать "menu95" с нуля.
Этого не достаточно. Нужно что бы винда гарантирвала определенное время отклика, а этой гарантии нет и не будет. Например что бы дать такую гарантию, даже для UI, нужен принципиально другой шедулер и таки решить проблему инверсии приоритетов. В противном случае в UI ты увидишь ровно тоже, что и со Sleep(100) из моего примера.
S>Увы, риск был слишком велик. Ну и порог вхождения в винду для разработчиков это бы повысило очень сильно. S>Вон — только появился WPF, где вообще всё асинхронно, как сразу начались стоны "ой, а как мне показать два диалога по очереди"?
Дело не в пороге вхождения. В примере со Sleep(100) нет никакого UI, а задержки есть. Что такого в WPF, что вдруг устранит эти задержки ? Опаньки !
Здравствуйте, Ikemefula, Вы писали:
I>Этого не достаточно. Нужно что бы винда гарантирвала определенное время отклика, а этой гарантии нет и не будет. Например что бы дать такую гарантию, даже для UI, нужен принципиально другой шедулер и таки решить проблему инверсии приоритетов. В противном случае в UI ты увидишь ровно тоже, что и со Sleep(100) из моего примера.
В подавляющем большинстве прикладных случаев это был бы overkill. Требовать ОСРВ для того, чтобы уметь отдать 1 фрейм-в-секунду (психологический порог "повисшести приложения") — это, простите, чрезмерно.
К примеру, те же меню, зависшие на чтении файлухи, будут прекрасно анимироваться благодаря тому, что CPU в это время свободен. Закормить CPU так, чтобы заморозить UI, в наше время — тяжкая задача.
I>Дело не в пороге вхождения. В примере со Sleep(100) нет никакого UI, а задержки есть. Что такого в WPF, что вдруг устранит эти задержки ? Опаньки !
Sleep() изначально и не планировался быть сколь-нибудь точным.
Измерялка задержек DPC показывает у меня до 8 секунд (если я правильно понимаю их единицы измерения). Тем не менее, видео в это время играет без заметных особенностей.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, Ytz, Вы писали:
Ytz>>Без понятия как оно устроено, если как вы утверждаете, то оторвать руки разработчиком. Но откуда у вас такие сведения? S>Ну, msdn.microsoft.com — адрес несекретный.
Я так и думал, что это ваша очередная фантазия.
Ytz>>Ничего. Просто утверждаю, что реализовать асинхронные меню не только возможно, но и задача не сложная. Лично у меня опыт есть. S>Ещё раз поясняю: в конкретном приложении, для конкретного меню — да, ничего военного. S>Починить единым махом все приложения, некоторые из которых портированы ещё со времён win3.1 — нет, невозможно.
А кто про это говорил? Изначально речь шла про то самое меню с надписью "Пуск". Опять запутались?
Ytz>>Глубокомысленно. Что сказать хотели? S>Повторюсь: переписать Windows Explorer, реализовав асинхронность меню, можно. Починить WinAPI, не сломав все приложения — невозможно.
А кто про это говорил? Но если возникнет такая необходимость, я бы объявил интерфейсы устаревшими и активно предлагал бы пользоваться новым API. Вроде не rocket science
Ytz>>Тогда покажите, где вы это сказали, а я переписал. S>А, виноват — вы написали раньше.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, Ikemefula, Вы писали:
I>>Этого не достаточно. Нужно что бы винда гарантирвала определенное время отклика, а этой гарантии нет и не будет. Например что бы дать такую гарантию, даже для UI, нужен принципиально другой шедулер и таки решить проблему инверсии приоритетов. В противном случае в UI ты увидишь ровно тоже, что и со Sleep(100) из моего примера. S>В подавляющем большинстве прикладных случаев это был бы overkill. Требовать ОСРВ для того, чтобы уметь отдать 1 фрейм-в-секунду (психологический порог "повисшести приложения") — это, простите, чрезмерно.
Нужно отдавать 20-50 фреймов в зависимости от степени интерактивности. Драг-дроп например требует около 50 фреймов.
S>К примеру, те же меню, зависшие на чтении файлухи, будут прекрасно анимироваться благодаря тому, что CPU в это время свободен. Закормить CPU так, чтобы заморозить UI, в наше время — тяжкая
задача.
Да дело то не в том, что они анимироваться будут. Если меню зависает на чтении файлов, стало быть ты будешь ждать если тебе нужен итем который еще не подгружен и будешь видеть например список элементов не в том порядке к какому ты привык.
I>>Дело не в пороге вхождения. В примере со Sleep(100) нет никакого UI, а задержки есть. Что такого в WPF, что вдруг устранит эти задержки ? Опаньки ! S>Sleep() изначально и не планировался быть сколь-нибудь точным.
Дело не в Sleep. В винде вообще нет ни одной функции, время работы которой худо-бедно детерминировано. Потому в винде например невозможно замерить точное время выполнения выполнения операций, всегда есть шанс, что ты замеришь чтото еще лишнее. И по этой же причине невозможно качественно управлять железом, для которого критичная точность задержек.
Вместо Sleep ты спокойно можешь подставить подгрузку меню и всё что угодно, ожидаемое время показа элементов может с большой вероятностью увеличиться вдвое, втрое и даже в десять раз.
S>Измерялка задержек DPC показывает у меня до 8 секунд (если я правильно понимаю их единицы измерения). Тем не менее, видео в это время играет без заметных особенностей.
Я не уверен что там милисекунды. Попробуй такой юзкейс — копирование файла в несколько гигабайта с диска на диск и проверь меню.
Здравствуйте, Ikemefula, Вы писали:
I>Нужно отдавать 20-50 фреймов в зависимости от степени интерактивности. Драг-дроп например требует около 50 фреймов.
Ну вот не странно ли, что quake их выдаёт, безо всяких скидок на не-риалтайм. А нам, простым пацанам, подавай ОСРВ. Непонятно.
I>Да дело то не в том, что они анимироваться будут. Если меню зависает на чтении файлов, стало быть ты будешь ждать если тебе нужен итем который еще не подгружен и будешь видеть например список элементов не в том порядке к какому ты привык.
ОСРВ тут никак не поможет. Ты же не думаешь, что она волшебным образом уменьшит латентность диска?
Значит, правильный ответ вовсе не в ней, а в том, чтобы отвязать показ меню от операций с ФС.
I>Дело не в Sleep. В винде вообще нет ни одной функции, время работы которой худо-бедно детерминировано. Потому в винде например невозможно замерить точное время выполнения выполнения операций, всегда есть шанс, что ты замеришь чтото еще лишнее. И по этой же причине невозможно качественно управлять железом, для которого критичная точность задержек.
По этой причине критичные к точности задержек железки управляют собой сами.
I>Я не уверен что там милисекунды. Попробуй такой юзкейс — копирование файла в несколько гигабайта с диска на диск и проверь меню.
Проверил — те же результаты. У меня Start меню читается из кэша, а не с диска.
В общем, основная мысль такова: я скептически отношусь к взаимосвязи реальности времени ОС и возможности построить плавный UI.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Иными словами, короткий ответ будет выглядеть так: в api windows асинхронное формирование пунктов меню осложнено сугубо синхронной природой системы сообщений. Одна конкретная особенность конкретной операционной системы создает проблемы не только разработчикам софта для этой системы, она является большим гвоздем для разработчиков кросплатформенных gui-библиотек и кросплатформенного ПО. Например, если вы в SWT попытаетесь вызвать методы gui-объектов из другого потока, то вы получите такую вот радость: "org.eclipse.swt.SWTException: Invalid thread access", причем вовсе не обязательно, чтобы ваша программа выполнялась в этот момент на винде. "Кроссплафторменности для" разработчики SWT тупо ограничили все gui-операции одним потоком (правда, остается возможность вызвать НЕКОТОРЫЕ методы SWT из другого потока при помощи костыля по имени asyncExec). В этом кроется ФУНДАМЕНТАЛЬНЫЙ недостаток кроссплаформенных gui-библиотек, использующих НАТИВНЫЕ компоненты — они слишком сильно завязаны на особенности реализации конкретных систем. Именно по этой причине я зарекся использовать подобные библиотеки (использовал wxWidgets и SWT) — несмотря на все преимущества, связанные с нативным видом, недостатков все же больше. Правда, в случае SWT, к сожалению, приходится отказываться от слишком многого, ведь Swing, не имеющий подобных недостатков (там все свое, рисованное), уже несколько лет назад прекратил свое развитие, и теперь просто не может конкурировать с SWT по количеству наработок. И тем не менее, практика показывает, что использовать по-настоящему кроссплатформенное решение целесообразнее.
Социализм — это власть трудящихся и централизованная плановая экономика.
Да и в догонку, в Windows API возможно:
— создавай сколько угодно message loops внутри одного процесса на каждом потоке;
— клеить нативное окно к любому родителю любого процесса.
В Linux/GTK:
— всегда и без вариантов всего один message loop. Что там хорошо: в любом потоке можно кусок UI кода обернуть в критическую секцию и выполнить валидные операции из другого потока. Иногда это просто удобно, чем посылать сообщения.
— хостить другое окно можно через GtkPlug/GtkSocket, — но это всё же совсем иная песня.
В MacOSX, на сколько мне известно:
— всегда и без вариантов всего один message loop;
— хостить напрямую out-of-process окно невозможно. Решается тоже только через приседания, в итоге или не очень перфоманс, или это не совсем окно (NSSurface какой-нибудь).
Здравствуйте, Sinclair, Вы писали:
I>>Нужно отдавать 20-50 фреймов в зависимости от степени интерактивности. Драг-дроп например требует около 50 фреймов. S>Ну вот не странно ли, что quake их выдаёт, безо всяких скидок на не-риалтайм. А нам, простым пацанам, подавай ОСРВ. Непонятно.
В кваке не надо ничего с диска подгружать, там даже целая куча приседаний что бы избежать лишних обращений к диску. Как только они появляются, в кваке падает фпс и появляются лаги, потому люди которые играют в кваку, отрубают все сетевые шары, коннекшны и тд и тд и тд.
I>>Да дело то не в том, что они анимироваться будут. Если меню зависает на чтении файлов, стало быть ты будешь ждать если тебе нужен итем который еще не подгружен и будешь видеть например список элементов не в том порядке к какому ты привык. S>ОСРВ тут никак не поможет. Ты же не думаешь, что она волшебным образом уменьшит латентность диска?
Помогут механизмы, вроде шедулера и тд.
S>Значит, правильный ответ вовсе не в ней, а в том, чтобы отвязать показ меню от операций с ФС.
Правильный ответ в том, что в винде диспетчеризация обработки внешних, т.к. аппаратных прерываний сделана не самым лучшим образом и поток IO может задушить все остальные потоки. А если глючит какой девайс, так это чисто бедствие — морозить будет вообще все, не только уи.
I>>Дело не в Sleep. В винде вообще нет ни одной функции, время работы которой худо-бедно детерминировано. Потому в винде например невозможно замерить точное время выполнения выполнения операций, всегда есть шанс, что ты замеришь чтото еще лишнее. И по этой же причине невозможно качественно управлять железом, для которого критичная точность задержек. S>По этой причине критичные к точности задержек железки управляют собой сами.
Точнее ими управляет ОС РВ, т.к. слишком дорого делать железо которое будет собой управлять. ОС РВ зашивается в кристал и дело в шляпе.
I>>Я не уверен что там милисекунды. Попробуй такой юзкейс — копирование файла в несколько гигабайта с диска на диск и проверь меню. S>Проверил — те же результаты. У меня Start меню читается из кэша, а не с диска.
Если кеша на это хватает, значит у тебя не нагружен комп.
Здравствуйте, Ikemefula, Вы писали:
I>>>Я не уверен что там милисекунды. Попробуй такой юзкейс — копирование файла в несколько гигабайта с диска на диск и проверь меню. S>>Проверил — те же результаты. У меня Start меню читается из кэша, а не с диска.
I>Если кеша на это хватает, значит у тебя не нагружен комп.
С целью пояснить сказаное, на многих компах достаточно мощных по характеристикам бесполезно кликать по меню или таскбару первые минуты после загрузки, тк в это время подтягиваются все фоновые аппликачки типа скайпа и тд и тд. Во многих есть проблема при копировании с DVD, комп точно так же морозится. Я считаю, что это проблемы не столька аппаратные, сколько виндовозного шедулера и такой особенности виндовса, как злоупотребление синхронными сообщениями для всякой дряни какая только может встретиться.
