Хм. Если коротко, то Вы делаете максимально неправильно. Скажем, стоит во время вывода взять другое окно и протащить его над Вашим - и график может и не выжить.

Позволю себе просто приложить максимально упрощенный пример относительно правильной реализации.

grexhideа) таймеры (вместо тредов)
А зачем там тред? Чтобы делать в нем Sleep?

grexhideб) буферизация изображения - тоже, конечно, вариант, но решение с .DoubleBuffered и грамотной отработкой именно WM_PAINT - будет
все-же более приближено к истине (хотя - тут и про DirectX уже можно
подумать)
Хм. Вы всегда охотитесь на воробьев с пушкой?

Имхо таки стоит соразмерять цели и средства. Впрочем, я с интересом увижу решение с тредами и WM_PAINT, вкупе с объяснением, чем именно оно лучше для решения данной конкретной задачи.

grexhideну не с пушкой ;)) но даже помповое ружье всяко предпочтительнее рогатки..
Сомнительно, сомнительно.

grexhideзадача была именно динамической отрисовки графика, да так, чтобы не было дерганий экрана, интерактивность выдерживалась на уровне (в смысле не создавала неудобств пользователю), а также - вопрос с массой графиков одновременно
Где? 8-[ ] (как следует протерев глаза) Так где все-таки? Либо я тупой, либо в упор не вижу.

grexhideуход от VCL дал весьма заметное снижение нагрузки на CPU - порядка 30-40%)
Хм. Безусловно. Но в примере решения простой задачи стоит писать коротко-ясно-стандартно. Когда наш собеседник дойдет до "TImage не удовлетворяет" - он уже легко сможет его заменить.

grexhideА таймеры, по моему скромному мнению, использовать вообще не разумно, разве именно как костыль, дополняющий OnIdle - в остальных случаях их применение просто нецелесообразно - именно в аспекте интерактивности и
в виду наличия механизма потоков (тредов).
Хм. Скажем так, я сомневаюсь в существовании аргументации, показывающей преимущество OnIdle, тредов или чего-либо еще для решения данной конкретной задачи.

Критерий прост: ничего лишнего. В данном случае нечего параллелить - значит, треды не нужны. Здесь нет, например, распараллеливания вычислений и отрисовки - у автора темы координаты посчитаны заранее, у меня их расчет мягко говоря быстр. А раз так - делать отдельный поток - значит делать синхронизацию двух ничего не делающих потоков. Зачем? OnIdle в данном случае хуже тем, что потребует самостоятельно контролировать временные промежутки, обеспечивая плавность и равномерность отрисовки.

grexhideесли график обновлять раз в минуту - то TImage и пр. как
раз и не нужны - как раз более чем достаточно именно WM_PAINT (.Invalidate),
и даже .DoubleBuffered уже как-бы и не сильно нужен.
Не согласен.

1. Если обновлять раз в минуту, DoubleBuffered действительно не нужен. Но для двадцати раз в секунду без него некрасиво.

2. Image в данном случае - "решение в ноль строк", альтернативное TBitmap+WM_PAINT (решение существенно больше чем в ноль строк). Итого, до тех пор, пока оно не мешает, это наиболее удачное решение.

grexhideно за треды - именно потому, что может быть еще и ожидающее событие какое,
Какое? Не вижу в постановке задачи никакого ожидающего события.

grexhideу нас просто была цель - создать один раз некое универсальное решение,
Это, конечно, особый вопрос.

grexhideуже есть. основной поток обработки сообщений Windows и
собственно поток отрисовки графика.
Ой. То есть два потока, занятых в лучшем случае на 0.1% каждый.

grexhideпрограммы, усиленно занятой в основном потоке динамической отрисовкой графика
Хм. Как же надо ухитриться написать программу, чтобы она "усиленно занималась динамической отрисовкой графика"? Под отрисовкой я в данном случае понимаю процесс модификации bitmap-а, то, что делается внутри таймера.

grexhide(задержка > .05 сек дает ощутимую потерю интерактивности)
Согласен. И в данной конкретной программе все задержки, которые только могут быть, сосредоточены в WM_PAINT, вынести который в отдельный поток не очень-то просто. А выносить в поток содержимое OnTimer - только ради студенческого выпендрежа.

Федор_ФедорТо что мне нужно работает. Зачем усложнять?
Правильный сам по себе подход. Но тот фрагмент кода, который Вы привели, мало того что сложен, но еще и работать (хорошо) не будет.

Федор_ФедорМне нужно, чтобы суммы колебаний появлялся на экране не сразу весь, а "потихоньку", последовательно, пошагово...
Я дал Вам шаблон, как это делать. Вам достаточно будет только изменить несколько строк.

Федор_ФедорВ режиме "пошагового построения" получается так: я щелкаю по экрану, а график продолжает себе спокойненько строиться дальше еще секунды три-пять.
Так, как Вы написали - безусловно. Уверен, что строится он до тех пор, пока не сработает if i mod 1000 .

Опять-таки, в моем примере сажаете еще кнопку, или OnClick, или что хотите.

grexhideна практике, в более-менее серьезном приложении, подобные злоупотребления нарастают как снежный ком. вроде бы и ничего страшного, но от массы полу- решений со временем получается та самая свалка кривых поделок,
с неумолимо стремящимся к нулю запасом прочности.
Я полностью согласен с описанием эскалации кривых решений, но в ходе нашей дискуссии не увидел ни одного, кроме сугубо религиозных, аргумента, при чем тут таймеры. В целом, имхо:

1. Тот, кто криво применяет таймеры, в потоках тем более таких дел наделает....
2. Уместно примененные таймеры ничем плохим не характерны.

По поводу выбора, имхо, также все довольно просто:

1. Ресурсоемкие операции, долгие ожидания и прочие вещи, надолго захватывающие выполнение, желательно выносить в отдельные потоки.

2. Короткие операции, выполняемые время от времени, желательно инициировать таймерами.

3. Признаком неуместно примененного таймера являются ухудшение интерактивности программы, усложнение кода таймера, попытка разбить выполняемое на куски типа "это сейчас, это в следующем срабатывании" итп.

4. Признаком неуместно примененного потока является слишком частая его синхронизация с другими потоками; ситуация, при которой поток большей частью ожидает времени, когда ему будет пора работать.

5. И применение таймеров, и применение потоков, требует определенного уровня грамотности разработчика и соблюдения соответствующей "техники безопасности".