Как сделать перерисовку формы максимально быстрой - .NET

Здравствуйте, FR, Вы писали:

FR>А тебе зачем все делать именно в отдельном потоке?
FR>Эмулятор как я понимаю вещь близкая к играм, может лучше и сделать как в большинстве игр, все расчеты в основном цикле, и без остановки на ожидание сообщений. Как это сделать для C# можно посмотреть например тут http://rsdn.ru/forum/Message.aspx?mid=1837856&only=1 (второй способ)

а как же оконный интерфейс? если мессаджи не обрабатывать будет не очень удобно...

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Здравствуйте, Streamer1, Вы писали:

S>Здравствуйте, FR, Вы писали:

FR>>А тебе зачем все делать именно в отдельном потоке?
FR>>Эмулятор как я понимаю вещь близкая к играм, может лучше и сделать как в большинстве игр, все расчеты в основном цикле, и без остановки на ожидание сообщений. Как это сделать для C# можно посмотреть например тут http://rsdn.ru/forum/Message.aspx?mid=1837856&only=1 (второй способ)

S>а как же оконный интерфейс? если мессаджи не обрабатывать будет не очень удобно...

Там все нормально обрабатывается.

Здравствуйте, FR, Вы писали:

FR>>>тут http://rsdn.ru/forum/Message.aspx?mid=1837856&only=1 (второй способ)

S>>а как же оконный интерфейс? если мессаджи не обрабатывать будет не очень удобно...

FR>Там все нормально обрабатывается.

интерересная ветка, спасибо за ссылку

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Здравствуйте, Дмитрий Наумов, Вы писали:

ДН>Маленькое уточнение: очередь забивается WM_PAINT'ами, которые "появляются" в результате вызова Invalidate. В очереди, не помню точно то ли подряд, то ли вообще, два WM_PAINT'а "не живут", они "сокращаются"

ДН>Сообщение WM_TIMER "ставится" в очередь очень хитро и там есть некоторые условия, одно из которых, например, если в очереди есть WM_PAINT, то WM_TIMER "ставится" не будет, пока не обработается WM_PAINT. Из этого следует:
ДН>1. Генерить прямо или косвенно сообщения WM_PAINT из обработчика WM_TIMER рискованно.
ДН>2. Расчитывать на точность WM_TIMER наивно

Откуда информация. Можно ссылку — интересно почитать.
Спасибо.

Привет!
а ты не пробовал при входе в процедуру таймера тормознуть его вызов, а по выходу из нее запустить таймер снова?

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Здравствуйте, 4erniyPlasch, Вы писали:

P>Откуда информация. Можно ссылку — интересно почитать.
P>Спасибо.

Из головы, MSDN и блог Old New Thing

Не люблю рсдновские флуды, но ладно. Сам сегодня (хммм, скорее вчера) похожей ерундой занимался.

Так вот. Ответ оказался элементарен — а никак не получится через GDI/GDI+. Даже с супербыстрыми битмапами. Даже с насильной двойной буферизацией. Кадров 5-10 получишь, дальше никак. Про показ в большом разрешении можно забыть сразу.

Попробуй включить у формы (если дотнеть вторая) двойную буферизацию (свойство есть такое у формы, если вдруг не в курсе).

Я делал свой PictureBox со стилем DoubleBuffer=true.

Конечно быстрее рисует, но не настолько, насколько нужно было.

Короче это только через DirectX/OpenGL можно сделать. На это меня уже не хватило. Может сегодня попробую.

—

The speed of processors doubles every 18 months" -- Moore's law
"The speed of software halves every 18 months" -- Gates' law .

данное сообщение получено с www.gotdotnet.ru
ссылка на оригинальное сообщение

>>очень даже большой смысл, достаточно уменьшить частоту с 50 Гц до 49 и все, конец света

бегущая строка уже будет дергатся,

А ты знаешь, почему так происходит?

Да просто потому, что твое чудо даже 25 кадров в секунду не дает! хорошо, если 5 реально. Человек действительно не видит больше 25 кадров, так же как и не различает даже 64К цветов. Все FPSы в тестах — маркетинговая фигня для "меренья, у кого больше".

Поставь для начала частоту развертки монитор на 85 герц, как минимум. Простые люди не в курсе, что ее можно менять. Много раз убеждался.Так несчастные и работают на 50-60 герцах, гробя свое зрение и получая головную боль по вечерам.

The speed of processors doubles every 18 months" -- Moore's law
"The speed of software halves every 18 months" -- Gates' law .

данное сообщение получено с www.gotdotnet.ru
ссылка на оригинальное сообщение

>>Invalidate реально управление возвращает только тогда когда отрисовка уже произойдет... что сильно замедляет генерирующий поток, т.к. вызов Invalidate вызывается в нем...

Уууу, как всё запущено-то... Зачемже ты его вызываешь там? Так он там и выполняется! Про BeginInvoke слышал? Твой генератор должен только СООБЩИТЬ форме, что генерация закончена и надо перерисоваться. Но никак не вызывать саму прорисовку.

ЗЫ: Ты двойную буфферизацию контролов включил?

—

The speed of processors doubles every 18 months" -- Moore's law
"The speed of software halves every 18 months" -- Gates' law .

данное сообщение получено с www.gotdotnet.ru
ссылка на оригинальное сообщение

оО народ вы чё. С GDI можно сделайть прорисовку.
во первых ф-ия SetDIBitsToDevice. Во вторых убрать обработку wm_erasebackground (WndPrc). И DoubleBuffer ни в коем случае не включать. Тогда прорисовка будет быстрой.

А насчет метода Invalidate — он не обвновляет окно при частом вызове. Чтобы окно точно обновилось в нужный момент — вызывайте Refresh().

Кстати BlackTigerAP ты видел хоть раз анимацию с 25fps?

И вообще действительно, зачем же надо больше 30фпс то? *ушёл думать*

данное сообщение получено с www.gotdotnet.ru
ссылка на оригинальное сообщение

Увеличением FPS уменьшения мерцания не добиться.
Попробуй поизвращаться с чем-то типа:

  class Canvas: Panel
  {
    private Bitmap bmpCanvas;
    public Canvas()
    {

      this.SetStyle(ControlStyles.UserPaint, true);
      this.SetStyle(ControlStyles.OptimizedDoubleBuffer, true);
      this.SetStyle(ControlStyles.AllPaintingInWmPaint, true);
      this.SetStyle(ControlStyles.ResizeRedraw, true);
      bmpCanvas = new Bitmap(this.Width, this.Height);
    }
    protected override void OnSizeChanged(EventArgs e)
    {
      base.OnSizeChanged(e);
      bmpCanvas = new Bitmap(bmpCanvas, Size.Width, Size.Height);
    }
    public Bitmap CanvasBitmap { get { return bmpCanvas; } }
    public Graphics CanvasGraphics { get { return Graphics.FromImage(bmpCanvas); } }
    protected override void OnPaint(PaintEventArgs e)
    {
      e.Graphics.FillRectangle(new SolidBrush(BackColor), e.ClipRectangle);
      e.Graphics.DrawImage(bmpCanvas, e.ClipRectangle, e.ClipRectangle, GraphicsUnit.Pixel);
      #if DEBUG
      e.Graphics.DrawString(DateTime.Now.ToString("HH:mm:ss.ff"), Font, Brushes.Red, PointF.Empty);
      #endif
      base.OnPaint(e);
    }
  }

Набросал сейчас, надо только доработать OnSizeChanged, сейчас при ресайзе изображение очищается — фича

Эмпирическое изучение граблей высоких энергий несколько затруднено…

данное сообщение получено с www.gotdotnet.ru
ссылка на оригинальное сообщение

Здравствуйте, BlackTigerAP, Вы писали:

BTA>Да просто потому, что твое чудо даже 25 кадров в секунду не дает! хорошо, если 5 реально. Человек действительно не видит больше 25 кадров, так же как и не различает даже 64К цветов. Все FPSы в тестах — маркетинговая фигня для "меренья, у кого больше".

правда? может не 25, а 25.00000000002 ?

я бы на твоем месте не стал раскидыватся такими высказываниями, потому что:

1. Сам глаз вполне справляется с частотами 200 и более гц, но мозг так устроен что сознательно мы плохо различаем (это не значит что совсем не различаем!) таких частот, т.к. справлятся с таким потоком информации на уровне сознания мозг не способен... Впрочем мозгу это вполне посилам на подсознательном уровне...

2. нет четкой границы в 25 или 50 Гц, чем выше частота тем меньше мелькающих деталей различает глаз, однако это не значит что он совсем перестает все замечать, глаз способен различить мерцание даже с частотой 100-150 Гц... я например очень даже вижу мерцание дисплея с частотой обновления 100 Гц

3. Различные области сечатки глаза имеют различную чувствительность к частотам, центральная область (основное зрение) довольно четко различает мерцание в 70-80 Гц, а вот периферическое зрение очень даже неплохо справляется с частотами >150 Гц...

Это связано с тем что на периферическое зрение возлагается несколько инные задачи (детектирование каких либо изменений), а на основное — получение информации...

4. Следует учитывать что люминофор в дисплеях имеет некоторое послесвечение, что следует учитывать, т.к. при частоте 150 Гц пикселы уже не гаснут, а только меняятеся (в определенной степени) яркость их свечения, а у глаза есть еще чувствительность к разности изменения яркости в зависимости от частоты...

5. О количестве различаемых цветов стоит говорить обозначив о каких цветах речь — излучаемых или отражаемых?
Человеческое зрение в среднем различает порядка 16 млн цветов для излученного света и порядка 30-60 млн цветов (!) для отраженного света... а вы говорите 64к цветов

Кстати при 32bit цвете, если присмотрется, то можно заметить границы переходов цветов на самом плавном градиенте...

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

BTA>Поставь для начала частоту развертки монитор на 85 герц, как минимум. Простые люди не в курсе, что ее можно менять. Много раз убеждался.Так несчастные и работают на 50-60 герцах, гробя свое зрение и получая головную боль по вечерам.

Ты недавно узнал что есть такая штука как частота обновления дисплея?

К сожалению моя видеокарта не поддерживает частоту 50 Гц...

А вообще частота выбирается не от балды и не по максимуму, а в зависимости от нужд... Несоответствие частоты обновления источника и частоты обновления дисплея приведет к ОЧЕНЬ ЗАМЕТНЫМ (!) биениям, даже при частоте обновления 150 Гц, т.к. в этой ситуации мозгу достаточно не идентифицировать объекты, а лишь детектировать нарушения в порядке следования деталей изображения, на что большой скорости обработки не нужно...

Никогда не задумывался, почему фильмы переписанные из формата NTSC 60Гц в формат PAL 50Гц (и обратно!) выглядят как дерганные при движениях объектов изображения?

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Здравствуйте, BlackTigerAP, Вы писали:

>>>Invalidate реально управление возвращает только тогда когда отрисовка уже произойдет... что сильно замедляет генерирующий поток, т.к. вызов Invalidate вызывается в нем...

BTA>Уууу, как всё запущено-то... Зачемже ты его вызываешь там? Так он там и выполняется! Про BeginInvoke слышал? Твой генератор должен только СООБЩИТЬ форме, что генерация закончена и надо перерисоваться. Но никак не вызывать саму прорисовку.

ты угадал, у меня используется BeginInvoke

BTA>ЗЫ: Ты двойную буфферизацию контролов включил?

да, двойная буферизация контролов + двойная буферизация при выводе итого буферизация можно считать 4x

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Здравствуйте, McCulic, Вы писали:

MC>оО народ вы чё. С GDI можно сделайть прорисовку.
MC>во первых ф-ия SetDIBitsToDevice. Во вторых убрать обработку wm_erasebackground (WndPrc). И DoubleBuffer ни в коем случае не включать. Тогда прорисовка будет быстрой.

про DoubleBuffer это зависит от реализации (точнее прямоты рук

), у меня его включение на скорость никак не уменьшает...

MC>А насчет метода Invalidate — он не обвновляет окно при частом вызове. Чтобы окно точно обновилось в нужный момент — вызывайте Refresh().

да? а у меня почемуто Invalidate отлично все обновляет с частотами до 120 Гц... кадры не теряются...

а с рефрешем будут дикие тормоза... т.к. Invalidate это почти прямой вызов API, а refresh это куча всякой фигни в библиотеках + Invalidate

MC>Кстати BlackTigerAP ты видел хоть раз анимацию с 25fps?

И вообще действительно, зачем же надо больше 30фпс то? *ушёл думать*

для видео

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Здравствуйте, BlackTigerAP, Вы писали:

BTA>Так вот. Ответ оказался элементарен — а никак не получится через GDI/GDI+. Даже с супербыстрыми битмапами. Даже с насильной двойной буферизацией. Кадров 5-10 получишь, дальше никак. Про показ в большом разрешении можно забыть сразу.

зачем же так сразу

посмотри ZXMAK.NET — вся графика на чистом C#, а спокойно дает до 100 Гц (там частота насильно ограничивается до 50)...

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Здравствуйте, KindDog, Вы писали:

KD>а ты не пробовал при входе в процедуру таймера тормознуть его вызов, а по выходу из нее запустить таймер снова?

пробовал — не помогло...

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Здравствуйте, Streamer1, Вы писали:

S>зачем же так сразу

посмотри ZXMAK.NET — вся графика на чистом C#, а спокойно дает до 100 Гц (там частота насильно ограничивается до 50)...

А думаешь зачем ограничивается частота насильно ?

Вообще проблема мерцания изображения даже при двойной буферизации заключается как раз в том, что при отрисовке формы Windows похоже чихать хотел на вертикальную синхронизацию. Для OpenGL/DirectX приложений существует опция (в свойствах драйвера видеокарты), при включении которой она включается. Естественно она понижает fps до частоты обновления монитора.(у меня это 85 Гц= 85 fps MAX) Так как её смысл это синхронизация записи в видеопамять с отрисовкой на экране, т.е. пока кадр не отобразится на мониторе полностью изменять видеопамять запрещено, чтобы избежать эффекта мерцания. Сейчас вот запустил NFS MW с включенной wait for vblank и без неё, разница заметна налицо.

з.ы. Неужели ты на глаз способен отличить видео 24 и 30 fps (PAL и NTSC) ?

Здравствуйте, <Аноним>, Вы писали:

А>А думаешь зачем ограничивается частота насильно ?

Прикольно когда объясняют почему я ограничил частоту...

все довольно просто — спектрум подключается к телевизору, у телевизора 50 Гц, если частота отрисовки будет другая, то будут наблюдатся непрятные биения на различных скроллерах которых там полно...
Идеальная частота обновления дисплея там будет 100 Гц (50*2)...
Биения там и так есть (50 Гц недостаточно надо делать и ресамплинг под частоту дисплея, если она не кратна 50) но они не так заметны как при отличной от 50 Гц... Ну и кроме того просто удобно именно до 50 Гц ограничивать а не до 49, т.к. 50 Гц не влечет проблем с ускорением/замедлением программ...

А>з.ы. Неужели ты на глаз способен отличить видео 24 и 30 fps (PAL и NTSC) ?

отличить 24 и 30 сложно, т.к. и то и то мерцает, а разница мерцания отличается несильно. Хорошо заметно если PAL в NTSC перевести или обратно...

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

	От:	Streamer1
	Дата:	29.04.06 16:55
	Оценка:

	От:	FR
	Дата:	29.04.06 17:03
	Оценка:	1 (1)

	От:	Streamer1
	Дата:	29.04.06 17:11
	Оценка:

	От:	4erniyPlasch
	Дата:	02.05.06 11:09
	Оценка:

	От:	KindDog
	Дата:	02.05.06 13:23
	Оценка:

	От:	Дмитрий Наумов
	Дата:	02.05.06 15:15
	Оценка:

	От:	Аноним
	Дата:	27.04.06 23:53
	Оценка:

	От:	Аноним
	Дата:	28.04.06 07:54
	Оценка:	-1

	От:	Аноним
	Дата:	28.04.06 07:59
	Оценка:

	От:	Аноним
	Дата:	28.04.06 08:13
	Оценка: