AS
Зачем ему Токио, если у него анимации, это какраз таки то что блокирует поток
да вот нихуя
Size: a a a
2017 November 26
A
переслать анимаху ввиде струтуры - ссылку на вьюху, проперти значения и время
ML
Там я не ковырялся =)
Там всё a bit tricky: для получения задач лучше юзать фьючерсовские потому что стрим, для отправки результатов — обычные, а то гемор)
A
Итак анимация
прилетела вьюха из угла (0, 0) в кординаты (100, 100)
и увеличилась с (0, 0) до (200, 200)
Добавить какой нить StateMachine (sm)
sm.set_frame_rate(60); // Чтобы обеспечить плавную анимацию
sm.add_transition_move(Arc(View), 100, 100, 1000ms); // 1sec
sm.add_transition_resize(Arc(View), 200, 200, 1000ms); // 1sec
Для move
// anim_time = 1000
step = anim_time / frame_rate; // 16.6
// x_aim, y_aim - конечный размер (100, 100)
x_step = x_aim / anim_time * step;
y_step = y_aim / anim_time * step;
loop 1 .. (frame_rate - 1) {
view.x += x_step;
view.y ~= y_step;
sleep(step)
}
view.x = x_aim;
view.y = y_aim;
прилетела вьюха из угла (0, 0) в кординаты (100, 100)
и увеличилась с (0, 0) до (200, 200)
Добавить какой нить StateMachine (sm)
sm.set_frame_rate(60); // Чтобы обеспечить плавную анимацию
sm.add_transition_move(Arc(View), 100, 100, 1000ms); // 1sec
sm.add_transition_resize(Arc(View), 200, 200, 1000ms); // 1sec
Для move
// anim_time = 1000
step = anim_time / frame_rate; // 16.6
// x_aim, y_aim - конечный размер (100, 100)
x_step = x_aim / anim_time * step;
y_step = y_aim / anim_time * step;
loop 1 .. (frame_rate - 1) {
view.x += x_step;
view.y ~= y_step;
sleep(step)
}
view.x = x_aim;
view.y = y_aim;
Основная идея тут
AS
что он лочить должен? Он может запустить тысячу разных анимаций с таймингами для них, и ждать, ибо нагрузки на set новых параметров стилей почти ничего не стоит сам по себе. Если анимация будет использовать для delay обычный sleep это будет фейл
AS
Там всё a bit tricky: для получения задач лучше юзать фьючерсовские потому что стрим, для отправки результатов — обычные, а то гемор)
вот тут я не понял момент
A
что он лочить должен? Он может запустить тысячу разных анимаций с таймингами для них, и ждать, ибо нагрузки на set новых параметров стилей почти ничего не стоит сам по себе. Если анимация будет использовать для delay обычный sleep это будет фейл
Ты запарил, ты можешь не юзать слип, а сверять время
ML
что он лочить должен? Он может запустить тысячу разных анимаций с таймингами для них, и ждать, ибо нагрузки на set новых параметров стилей почти ничего не стоит сам по себе. Если анимация будет использовать для delay обычный sleep это будет фейл
tokio-timer в помощь
AS
tokio-timer в помощь
ну а я о чем
AS
хотя мне уже кажется что мы в испорченный телефон играем) \
ML
Да, есть такое
AS
и толком у каждого свои вариации вопроса
A
У мну только концепт, без кокретных тулз
A
Кроме тебя этим нихто тут не занимается =)
AS
Вобщем смотрите: у меня есть контекст окна, для эвентов вроде клик, скролл мышкой, и тд - у окна есть свой ивентлуп - самый обычный аля loop {}, он само собой блокирует все что будет дальше. Во время его работы - я должен получить например положение мышки во время клика, сверить его с позициями кнопок и тд. Эвентов одновременно может быть много Hover, Click и тд. Их внутренняя обработка может быть более сложной - ибо как только я расчитал положение кнопки - я например должен перерисовать ее с стилями Hover и запустить например колбэк on_click - если это делать в контексте эвентлупа окна, это все блокируется и может вообще не срабатывать. Поэтому - эвентлуп окна запускается при инициализации сразу. Также запускается поток для основных прикладных эвентов для конкретных элементов - в который посылает эвенты вроде set_new_position_cursor() основной ивентлуп окна, и потом в отдельном треде, спокойно без тормозов он вычисляет по позициями элементов клики для обработки. После чего отправляет сигнал основному потоку "запусти этот колбэк для клика этого элемента". По этой же логике я хочу чтобы работал и поток анимаций - он обособленный, и также ленивый, все стили отправляются в очередь ленивую webrender-a - поэтому ивентлуп для анимаций будет работать очень быстро, и для очень большого количества вьюх в нем зарегистрированных. Почему я против например даже того чтобы оставлять обработку анимаций в потоке с обычными прикладными эвентами вроде клика? Потому что это будет слишком сильно засирать эвентами и обработчиками поток, а я хочу чтобы для каждого самодостаточного куска без блока работало все хорошо. Можно меня хуисосить мол нахуя сразу 3 треда: анимации, прикладной, окно - так я отвечу что для того чтобы сохранялась отзывчивость, чтобы после клика на кнопку мог сразу запустится колбэк в основном потоке - и сама по себе жить анимация: например я нажал на кнопку которая запускает анимацию длительностью 1 секунда. Я хочу чтобы анимация без блокировки сразу работала и позволяла нажимать на другие кнопки пока выполняется колбэк - иначе все будет люто тормозить и просирать фреймы
AS
AS
ML
Ну и делай как делал тогда. Заведи CpuPool для обработки анимаций и все
ML
Никиких токий
A
И eventLoop на уровень приложения вынеси, вдруг у тебя несколько окон