Интересно, почему дажу в MSDN в обработчиках события Paint не вызывается Dispose для PaintEventArgs.Graphics. Насколько я понимаю, в наследниках Control нет поля для хранения Graphics, поэтому PaintEventArgs.Graphics создается каждый раз при обработке события. Если так, то странно, что не вызывается Dispose.

Поправьте, если не прав.

с чего ты взял? как ты это проверил?
а эта догадка откуда? 

Хм... Просто увидел в MSDN:

Мне это показалось странным, ведь событие Paint вызывается очень часто.


От туда же - из MSDN. Graphics каждый раз получается путем создания нового объекта через CreateGraphics или через статические методы Graphics.FromXXX. Хотя вполне логично было бы ожидать, чтобы Graphics создавался один раз и хранился в Контроле. Но почему-то сделано не так :(.

Это сообщение отредактировал(а) Idsa - 15.3.2007, 05:11

Это просто обработчик события, а очистка видимо происходит потом.


Чтоб ресурсы не сжирать.

Ну имхо, это тривиально: обработка событий в дотнет идёт по цепочке, т.е. если допустим на Paint подписано несколько обработчиков - все они получат один и тот же PaintEventArgs. Если один обработчик задиспозит графикс, остальные не смогут в нём рисовать.

Всё сказанное дальше - только в познавательных целях. Чтобы узнать, кем создаётся и кем убивается графикс для Paint, открываем рефлектор, смотрим где впервые создаётся графикс для OnPaint/события Paint (можно по "instantiated by" для PaintEventArgs), и видим сие:



Оказывается, что внутри контрола для Paint создаётся и диспозится чудесный объект BufferedGraphics, а также есть возможность передать в WM_PAINT свой контекст вывода через wparam.

Общее правило относительно любого любого обьекта Graphics :

• Если обьект Graphics был создан вами непосредственно , после окончания его его использования следует его освободить с помощью Dispose()
• Если вы ссылаетесь на существующий обьект Graphics , его освобождать НЕ следует.

Это обусловлено тем , что  " Вы создавали этот обьект ? ". Нет , а значит вы не можете гарантировать , что он не нужен еще кому то и значит не должны его освобождать , об этом должен беспокоится тот код , который создал его. Думаю это касается всех обьектов, реализующих IDisposable , а не только Graphics. Разумеется это правило общее и может не иметь силы в какой то конкретной задачи , хотя его нарушение по мне несколько портит логическую картину программы.

Это сообщение отредактировал(а) nikitao - 15.3.2007, 17:51

Логично. +1. Вопрос  снят.

А вот вопрос, почему бы не сделать поле, например, в классе Control для хранения ссылки на Graphics, остается открытым. По всей видимости, есть необходимость создавать новый объект Graphics при каждой отрисовке (какой-то параметр часто меняется)... однако при рассмотрении Graphics в MSDN и рефлекторе я так и не понял, что же такое "частоменяющееся" хранится в Graphics.
Если бы ссылка на Graphics хранилась в контроле, то все было бы гораздо проще. Нужно было бы проверить ее на null и использовать. Ответ, вроде

считаю несостоятельным.

P. S. Мои размышления основываются на том, что нет необходимости создавать Graphics при каждой отрисовке, что в нем нет таких полей, которые бы менялись при каждой отрисовке. Однако я более чем уверен, что я неправ в этом предположении .

Это сообщение отредактировал(а) Idsa - 15.3.2007, 18:43

Idsa, конечно, не уверен, но думаю это связано с занимаемой памятью. Пустая форма итак, занимает много места. Если все ее контролы будут хранить свой Graphics, потом тебе захочется еще чего-нибудь "хранить".
А, сообственно, (с Dispose()-то понятно) чем тебе не нравится, что Graphics() создается, когда он нужен, а не хранится?

А не нравится мне вот что. Graphics нужен все время жизни, например, формы, в течение которого ее Visible == true. Если бы мы сохранили ссылку на Graphics в каком-нибудь поле, то затратили бы на это X байт памяти. А получается же, что Graphics создается очень часто, и до сборки мусора у нас может уйти n*X байт памяти, где n - не такое уж и маленькое число.

Вопрос-то собственно был задан с целью узнать, может, в Graphics передаются какие-то меняющиеся в процессе выполнения параметры. Видимо, мое предположение оказалось неверным. Тогда получается, что Microsoft решила не хранить постоянно X-байт, а периодически выделять и "собирать" n*X байт. Что ж, это их право .

P. S. Раньше думал, что Paint вызывается и при движении мышки по форме. Однако сейчас убедился в обратном. Почему так происходит? Как будто курсор мышки в другом слое 

Graphics во время жизни формы нужен кому? Система сама позаботится об отрисовке. Graphics это вообще обертка над HDC - контекстами устройства Win32 и если каждый контрол будет его хранить, то ресурсов системы рано или поздно не хватит однозначно (ресурсы != память)

Ответ нужно искать в WinAPI, в том как винда отрисовывает окна (тема About Painting and Drawing в мсдн), ну и конечно же хранить для каждого окна HDC - значит забить все ресурсы винды (в среднем приложении м.б. сотни окон - кнопки и пр.), количество которых почему-то ограничено.

С вопросом от том, что хранение Graphics - пустая трата ресурсов, убедили! А вот с вопросом, почему событие Paint не вызывается при движении курсора мыши, я так и не разобрался :(

Отрисовкой курсора управляет ось, уж она может позаботиться о том чтобы корректно смешивать два буфера (рисунок курсора с маской и текущее содержимое десктопа) перед выводом на экран, вместо того чтобы тупо перерисовывать десктоп на каждый чих мышки. Практически то же самое относится к передвижениям окна: перерисовывается только то, что под окном, а передвигаемое окно - нет, пока не будет затронуто краями десктопа или topmost-окнами.