Думаю это решается тем же способом, каким пользовались Сократ и Бруно. Рассказывать общую идею многим, доносить глубокую суть избранным. И собственно эти «избранные» сами откликались среди многих, проявляя интерес. Благодаря им, и знаем об этих двоих.
Т.е. кому это действительно надо, смогут найти среди котиков своего Сократа. Путем проб и ошибок. Главное этому Сократу не сдаваться.
А по лайкам, для поиска специализированного контента, дальше обзорной статьи они не используются. Натыкаешься на статью «эксперта», что впечатлил. А уже по ней раскручивается, на основе чего она была создана и какие ресурсы использовались. Собственно, под научными статьями состав кто работал, и какие источники использовались. Ну и копай, если действительно нужно.
В принципе, если присмотреться за машиной, при высокой скорости остается шлейф(полупрозрачный хвостик), при скриншотах все чисто. Хвостик и есть обман зрения и вторая машина.
Идея интересная, но сработает ли, можно проверить только на практике.
Так и так потоки хорошо усложняют код, как в плане читаемости, так и тестируемость. И если нет, действительно важной причины на их использование(как понимаю, тут идет речь о больших вычислениях, как цель применения потоков), то тоже не вижу в них смысла. Тем более, это все таки Web, сильно суровыми вычислениями, насиловать компьютеры пользователей не принято.
fps прыгает или низкий. Т.к. пройденное расстояние зависит от времени прошедшее с предыдущего кадра. Т.е. машина за секунду, что за 60, что за 5 кадров пройдет примерно одно и то же расстояние(напомню, время между кадрами разное). Но глаз не обманешь, не которые шажки будут короче, некоторые длиннее.
Плюс, алгоритм вычисления скорости, зависит от значения самой скорости. От скорости отнимается 40 процентов ее значения. Это дает лишнею привязку к частоте кадров.
Под отдельным потоком подразумевался, не поток UI.
Если обратиться из такого потока напрямую к свойствам элемента интерфейса, будет ошибка меж потокового доступа(cross-thread access).
В System.Windows.Threading.DispatcherTimer можно по обычному с UI работать, но если вычисления длительные, интерфейс будут подвисать. Все как в настольных приложениях.
Внутреннее(физическое) устройства потоков в Silverlight мне не известно. Но снаружи, в плане программных манипуляций, все вполне многопоточно и асинхронно. Работают же многозадачные ОС на одно ядерных машинах)
Изначально пример хотел делать на WP7, но т.к. на эмуляторе не нажать сразу несколько кнопок(мышью по крайне мере), решил под браузер.
При испытание проблем не возникло, все так же анимировалось. Код, не считая куска работы с клавиатурой, почти полностью с примера на WP7.
Т.е. кому это действительно надо, смогут найти среди котиков своего Сократа. Путем проб и ошибок. Главное этому Сократу не сдаваться.
А по лайкам, для поиска специализированного контента, дальше обзорной статьи они не используются. Натыкаешься на статью «эксперта», что впечатлил. А уже по ней раскручивается, на основе чего она была создана и какие ресурсы использовались. Собственно, под научными статьями состав кто работал, и какие источники использовались. Ну и копай, если действительно нужно.
Идея интересная, но сработает ли, можно проверить только на практике.
Плюс, алгоритм вычисления скорости, зависит от значения самой скорости. От скорости отнимается 40 процентов ее значения. Это дает лишнею привязку к частоте кадров.
Если обратиться из такого потока напрямую к свойствам элемента интерфейса, будет ошибка меж потокового доступа(cross-thread access).
В System.Windows.Threading.DispatcherTimer можно по обычному с UI работать, но если вычисления длительные, интерфейс будут подвисать. Все как в настольных приложениях.
Внутреннее(физическое) устройства потоков в Silverlight мне не известно. Но снаружи, в плане программных манипуляций, все вполне многопоточно и асинхронно. Работают же многозадачные ОС на одно ядерных машинах)
При испытание проблем не возникло, все так же анимировалось. Код, не считая куска работы с клавиатурой, почти полностью с примера на WP7.