Задача:
Сделать, чтобы во время ожидания ответа от устройства, крутился рисунок на форме (в точности как иконка браузера во время загрузки, только где-т 150x150рх)

Решение:
Заготовил стопку картинок. Положил их в массив изображений одно над другим. IF по таймеру переключает им Visible:



Всё работает, мерцания, бликов не наблюдается.  Но! Вращение получается неравномерным, переключение кадров периодически задерживается, что приводит к неприятному "дерганью". Впечатление, что таймер вызывается не через равные промежутки.
Машина - 1GHz (не очень заметно, но что же будет на более медленных?..)

Кто что порекомендует?

Юзаем ФАК
http://vingrad.ru/VB-ART-002308

Это сообщение отредактировал(а) ~FoX~ - 26.3.2007, 08:08

~FoX~, возможно имелось не то.
JusTalionis, тормоза возникают по многим причинам. Все дело в очереди обработки процессов. Как выход, могу посоветовать установить приоритет приложения в REALTIME. Будет немного лучше.

Тупо меняем на:




Каков TimeR Tick?

Насколько я знаю mod (div) считается дольше чем if (djnz).

Может это и не на всех процессорах так, но на некоторых именно так...
http://www.computer-museum.ru/technlgy/pro...MCS51/instr.htm

Если бы мы писАли на Ассемблере - да.

А из VB тот же ассемблер делается компилятором, вопрос только насколько эффективно что заменяется...

Akina:
Мысль красивая! Не вдаваясь в теоретические вопросы, я ее проверил. Заработало точно так же. Ни малейшего различия с работой моего варианта заметить не удалось.
(Предупреждая ненужные гипотезы: ушел от обращения к тегу, создав нормальную глобальную переменную. Изменений также нет.)
Интервал таймера- 40.



~FoX~:
Код, приведенный в твоей статье неработоспособен (копировал из текста).

 Ошибки:
Dim PicWidth As Single,'ширина картинки - не нужна запятая
Установим у всех Image свойства ... AutoRedraw=True, AutoSize=True. - у Image нет таких свойств
два PictureBox ... их тоже сделаем невидимыми Visible=False - тогда тогда вообще ничего не видно
PictureBox1.Picture = Msk(i).Picture
PictureBox2.Picture = Kadr(i).Picture
Здесь вместо (i) должно быть (SKadr).

Исправив это, запустил с горем пополам - тормозит жутко, форма вся мерцает, кошмар. Может на шести кадрах такое и прокатывало, но не на 36.



Black_Star:
Вот я тоже сразу про это подумал! Но как сделать это правильно пока не волоку...  Ведь все ресурсы забирать нельзя - в это же время будет ожидание ответа от устройства, нужно же хоть что-то ему оставить тоже. (А когда анимация отработает, лучше вообще максимально понизить, чтоб освободить ресурс.)

Их нет. Не считая компактности и (имхо) читабельности кода.


Мерцать будет однозначно... попробуй поставить не менее 55... впрочем, все одно будет мерцать.

я бы пошел по иному пути... грубо где-то вот так:

36 картинок. Скажем 55.6 мс на картинку - это 2 с на прокрутку всего набора.

Делаем таймер 5-10 мс. Помним текущую картинку. В процедуре таймера спрашиваем у системы точное время через API. Делим на 2 с, берем остаток, множим на 18, берем целое, получаем номер картинки, которая в данный момент ДОЛЖНА быть на экране. Если она - процедуру закончить, иначе отрисовать нужную.

В этом случае вместо ПРИТОРМАЖИВАНИЯ вывода очередной картинки ты в худшем случае будешь получать ПРОПУСК очередной картинки - а это не так заметно.

Akina:
Я пробовал разные значения таймера. При 50 и более, дерганье еще хуже заметно. Уменьшал до 20 .. 10 - вот тогда еще ничего! Причем реально скорость вращения не увеличивается настолько, так и остается где-то оборот в полторы секунды. Ну я и раньше знал, что таймер в VB "символический"...
Интересная идея вообще от него отказаться и переключать чисто по системному времени, всё написав "руками". НО! ведь надо будет еще попутно опрос устройства там как-то вставлять тогда... Таймер был бы, конечно, удобнее значительно!
Короч, есть, что вспахивать. Сегодня вечером, надеюсь, попробую; что получится отпишу.

ЗЫ Пропуск кадра - это дерганье вперед. При такой маленькой скорости (20FPS) все равно заметно. Хотя, в нормальном видео - это неплохой вариант синхронизации для тормозящих машин.

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

Akina:
Я обратил внимание на следующую вещь. В режиме работы в среде VB, когда эту стопку изображений двигаешь, или в процессе добавления каждой новой картинки в массив, Эта стопка автоматически перерисовывается на экране, начиная с первой. Так вот, при этом, вся стопка из 36 кадров пролетает менее чем за 0.3 сек, едва успеваешь увидеть, что картинка обернулась на полный оборот. Так что вывод сам по себе имеет значительный запас времени.
Можно посчитать: 36 кадров 150x150px - это 810K. За полторы секунды - это 540K в секунду. На гигагерцовой машине - более полутора тысяч тактов в запасе на копирование только одного пиксела. Я понимаю, что там не все так просто, но тысячекратный запас - это, IMHO, достаточно для нормальной работы.
Так что, тормозит сама Винда, но где именно и как с этим бороться, я не выяснил.

А это и не получится.

Вот тут детский пример, который навряд ли тебе подойдёт...

http://www.i2r.ru/static/375/out_15456.shtml

А вот тут - интересная мысль.
Как ты думаешь, сможешь ли ты заменить свою коллекцию рисунков одним gif-файлом?
Нужна анимация, показываешь гифку.
Не нужна анимация, на месте гифки рисуешь стационарный рисунок...

Как тебе идея?

Вот тут идея реализации...

http://www.megalib.com/books/1395/272.htm

Добавлено через 1 минуту и 17 секунд
И ресурсов почти не жрёт...

Это сообщение отредактировал(а) mihanik - 27.3.2007, 13:35

Black_Star: пасиб, это буду пробовать.


mihanik: Привет! )
Ну, первый пример - ничего нового, а 100 mS это, конех, мало для слитного движения, а только типа моргания индикаторной лампочки.

Про GIF - у меня была такая мысль, тем более что в списке связанных тем ссылочку на хороший контрол дали. Я попробовал тот пример - медленнее работает, но зато равномерно. Если так нормально не сделаю, буду крутить гиф. Там несколько громоздкий код выходит.

А от твоей ссылки - я полное офиге!  чтоб сделать это через браузер!... ну, голь на выдумки хитра!.. 
(Но в данном случае не хотелось бы тащить с собой отдельный файл-картинку.)
Кароч, пасиб!..   

Засунь ее тогда в исходник (в буфер какой-нибудь)...

Black_Star:
Попробовал твой код. К моему изумлению, реалтайм не дал ни малейшего прироста в равномерности, даже характер рывков остался прежним. 
  Вот такого варианта я никак не ожидал!..


Akina:
Попробовал - код выдает ошибку Run time error 6 Overflow в строке
Я не стал тратить силы на вылавливание этой ошибки (вечер перешел в ночь уже), и попробовал изобразить собственный вариант с хорошо знакомой мне бейсиковой функцией Timer, благо ее период (55ms) близок к нужному мне.



Здесь NextFrame - Это код смены кадра, приведенный мной в самом начале темы. Хотя лишний Call чуть замедляет выполнение, но облегчает отладку. Да!,- и там в конце добавлено DoEvents, потому что без него кадры не отрисовываются. При запуске таймером отрисовывались сами,  а в цикле - не отрисовываются без DoEvents.
Цикл For применен, чтобы обезопаситься от бесконечного цикла (с которыми в VB головная боль).

то, что я увидел, запустив, изумило меня еще больше! Рисунок мгновенно повертывался на пол-оборота с максимально возможной скоростью (порядка за десятую секунды) и застывал затем на 2 секунды. Потом опять пол-оборота и стоп. Клянусь, сам не поверил бы, если б не видел. (Приводимый здесь код прямо копирован из VB.) Вставка дополнительного DoEvents внутрь цикла Do картины не изменила.
Тогда я вместо цикла Do поставил для проверки паузу Sleep 40. Сразу же пошло нормальное вращение, но как и прежде, с небольшими рывками. (Кстати, Sleep адекватно работал даже на интервале 5, давая очень быстрое вращение, в отличие от стандартного таймера.)

Каким образом Do - Loop мог застревать на две секунды - для меня полная загадка! Всё, уже ночь, больше не могу, гашу машину и отрубаюсь.


Это сообщение отредактировал(а) cardinal - 2.8.2007, 15:19

Из темы: Скорость инициализации переменных



Можно в native. (Project > Properties > Comile > Compile to Native Code). 
Само собой прирост будет. У меня доходило до того, что прирост составлят чуть ли не в два раза по сравнению с пикодом. 

JusTalionis, у тебя был код без посдветки - я поменял...  

W4FhLF
Ааа, ты про это! Посмотрел. Стоит опция Native. Но компилится все равно не в нормальный машинный код (как, например, досовский екзешник); я и думал, что это P-код.
А для сравнения переключил в P и посмотрел, что будет. Размер екзешника сделался чуть меньше, потому что в нем не стало списка всех употребленных имен. Но на скорости в данном случае почему-то не отразилось; и, что плохо - на равномерности не отразилось (скорости-то мне хватает, запас есть).
А еще поигрался с флажками отмены всяческих защит - тоже никакого видимого эффекта, как и при смене опций оптимизации (изначально стояло "оптимизировать скорость").

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

P-CODE исполняется на виртуальной машине msvbvm, остальное всё машинный код. Не знаю, что ты подразумеваешь под словом "ненормальный". 




ОС я бы стал винить в последнем случае, А ТЕМ БОЛЕЕ, если ты пишешь на VB. Вот тебе для сравнения, простейшая программа на VB:



Компилятор превращает это всё в такое вот машинное чудо:



Без комментариев вообще, это просто ужоснах

Теперь вариант на С/С++:



Скомпилированный GCC такой код превращается в следующий аналог машинного:



Достаточно плохая оптимизация, а точнее такое впечатление, что её вообще нет. Хотя флаг /O стоял. 

Теперь гвоздь программы, MS VS C++ 7.1:



Очень красивый код, хорошо оптимизирован, но не предел  Ручками можно было бы выжать ещё. 

Делай выводы. Это элементарная рекурсия и арифметика. То, что творится с объектами и строками ещё хуже. 

Я в курсе. Но, тем не мненее, впечатляет. Да еще если развернуть все задействованные рутины MSVBVM...
Я в ассемблере рублю чуть-чуть, но он же машинно-зависимый, так что если я чё написал и у меня работает - еще не факт, что заработает на другом компе. По этой причине предпочитаю все же Бейсик (хотя у VB с переносимостью - крупные траблы :( ) Ну в большинстве случаев VB все же позволяет строить внешне сносные программки, за исключением вот таких вот узкоспециальных случаев. Да собсно на форуме таковые и разбираются.
Вот и вопрос: существует ли путь в данном частном случае повысить равномерность? Главное - непонятно: что именно вносит лишнюю задержку, чтоб убрать или обойти это место.
Кстати, наблюдаю интересное проявление: когда программа запущена, и рисунок начинает крутиться, сначала он движется весьма неравномерно, скачками. Но пройдя три-четыре оборота, как будто "входит в режим", остаются один-два рывка в обороте. Не знаю почему такое. Причем повторяется только в среднем: когда может дергаться больше, когда - меньше.
А работа функции Timer меня вообще убила. Вы прочитали выше? А вот интересно, ведь в BIOS есть прерывание, на котором всё это и базируется... нельзя ли его сюда привлечь?

Он процессорнозависимый, то есть от набора команд, которые понимает конкретный процессор.

Как уже сказано выше, всё зависит от того под какой камень ты пишешь. пишешь под ARM, заработает на всех арм'ах, пишешь под x86(x64) заработает на них.



Я, честно говоря, не смотрел твой пример. Может есть смысл глянуть тебе под профайлером? Локализуешь место. 



Это кеширование. 

А архитектура компа? Особенности шины, BIOSа? Когда я занимался этим, это было как раз первое на что я и напоролся: на разных компах устройства работали чуточку не так. Где-то требовалась только определенная последовательность, а где-то допускались и другие (типа записи в незадействованные биты регистра), где-то между командами требовалась некоторая задержка, и тому подобное. Но результат был один: что работало на одном компе - висло на другом.
Так что, чтоб писать на ассемблере, надо наперечет знать ВСЕ эти нюансы, то есть быть профессионалом неслабым.
А работа с видеокарточкой, особенно в высоких разрешениях? На асме никто не пробовал для прикола?  

JusTalionis, то, что ты описываешь похоже на программирование времён начала-середины 90х или конца 80х. Сейчас в целом всё стандартизировано и существуют интерфейсы предоставляемые ОС даже на самых низких уровнях. Короче тех проблем, что ты описал сейчас практически не существует. 

Да, эт давно было, я под дос писал. 
 А может все-таки посмотреть? А то за оффтоп Акина щас громы и молнии метать начнет ;))

Прикрепи проект с картинками. 

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

Может, перенести куда? в порядке превращения оффтопа в обсуждение по существу? Тема-то по сути интересная (воды, правда, многовато, но это нормально)...