Delphi / GDI +: когда создается / уничтожается контекст устройства?

Вы не можете использовать стандартный TPaintBox, потому что TPaintBox имеет Canvas типа TControlCanvas, члены которого имеют отношение к этой проблеме:

TControlCanvas = class(TCanvas)
private
  ...
  procedure SetControl(AControl: TControl);
protected
  procedure CreateHandle; override;
public
  procedure FreeHandle;
  ...
  property Control: TControl read FControl write SetControl;
end;

Проблема в том, что FreeHandle и SetControl не виртуальные.

Но: TControlCanvas создается и назначается здесь:

 constructor TGraphicControl.Create(AOwner: TComponent);
 begin
   inherited Create(AOwner);
   FCanvas := TControlCanvas.Create;
   TControlCanvas(FCanvas).Control := Self;
 end;

Итак, что вы могли бы сделать, так это создать нисходящий TMyControlCanvas, у которого есть виртуальные методы, и TMyPaintBox, который назначает Canvas следующим образом:

 constructor TMyPaintBox.Create(AOwner: TComponent);
 begin
   inherited Create(AOwner);
   FCanvas.Free;
   FCanvas := TMyControlCanvas.Create;
   TMyControlCanvas(FCanvas).Control := Self;
 end;

Затем вы можете использовать методы TMyControlCanvas для динамического создания и уничтожения вашего TGPGraphics.

Это должно вас подтолкнуть.

- Джерун

Обнаружить создание легко. Просто переопределите CreateHandle в потомке TControlCanvas и поместите свой вместо по умолчанию один , как показывает ответ Джероена . Обнаружить разрушение сложнее.

Один из способов избежать этой проблемы - проверить, равен ли дескриптор TGpGraphics дескриптору рисования, поэтому вместо того, чтобы определять момент, когда контекст устройства освобожден, вы просто проверяете, прежде чем вам понадобится знать.

if not Assigned(FGraphics)
    or (FGraphics.GetHDC <> PaintBox1.Canvas.Handle) then begin
  FGraphics.Free;
  FGraphics := TGpGraphics.Create(PaintBox1.Canvas.Handle);
end;

Однако это, вероятно, ненадежно; значения дескрипторов могут использоваться повторно, поэтому, хотя значение HDC может быть одинаковым между двумя проверками, нет гарантии, что оно по-прежнему относится к одному и тому же объекту контекста устройства ОС.

Базовый класс TCanvas никогда не очищает собственное свойство Handle, поэтому все, что делает холст недействительным, должно происходить извне. TControlCanvas очищает свое свойство Handle, когда его свойство Control повторно назначается, но это обычно происходит только при создании элемента управления, поскольку TControlCanvas экземпляры редко используются совместно. Однако TControlCanvas экземпляры работают из пула дескрипторов контекста устройства, хранящегося в CanvasList. Когда одному из них нужен DC (в TControlCanvas.CreateHandle), он вызывает FreeDeviceContext, чтобы освободить место в кэше холста для дескриптора, который он собирается создать. Эта функция вызывает (не виртуальный) метод FreeHandle. Размер кеша равен 4 (см. CanvasListCacheSize), поэтому, если у вас есть несколько потомков TCustomControl или TGraphicControl в вашей программе, высока вероятность того, что вы получите промахи кеша всякий раз, когда необходимо перерисовать более четырех из них одновременно.

TControlCanvas.FreeHandle не является виртуальным и не вызывает никаких виртуальных методов . Хотя вы можете создать потомка этого класса и дать ему виртуальные методы, остальная часть VCL будет продолжать вызывать невиртуальные методы, не обращая внимания на какие-либо ваши дополнения.

Вместо того, чтобы пытаться определить, когда контекст устройства выпущен, вам может быть лучше использовать другой конструктор TGpGraphics. Используйте тот, который принимает дескриптор окна вместо дескриптора DC, например. Разрушение оконной ручки обнаружить намного легче. Для одноразового решения назначьте свой собственный метод для TPaintBox.WindowProc свойство и следите за сообщениями wm_Destroy. Если вы делаете это часто, создайте класс-потомок и переопределите _21 _ .

Потеря производительности при создании / уничтожении графического объекта минимальна. Это намного перевешивает снижение производительности, связанное с использованием команд рисования gdi + в первую очередь. Когда дело доходит до рисования пользовательских интерфейсов, ни о чем из этого, я думаю, не стоит беспокоиться, потому что пользователь все равно ничего не заметит. И, честно говоря, может быть очень неудобно пытаться переносить графический объект и отслеживать изменения в дескрипторе DC (особенно если вы инкапсулируете графические подпрограммы внутри своего собственного набора классов).

Если вам нужно кэшировать растровые изображения, вы можете подумать о создании растрового изображения, которое вы хотите кэшировать с помощью GDI + (сделайте его подходящего размера и с любыми настройками сглаживания, которые вы хотите), сохраните его в tmemorystream, а затем, когда он вам понадобится , загрузите его из потока и нарисуйте, используя старый добрый bitblt. Это будет намного быстрее, чем при использовании Graphics.DrawImage. Я говорю на порядки быстрее.