Win32::GUI operates at a much lower level than Tk. Hence the programmer is charged with doing much more of the housekeeping with the former, than with the latter.

For simple things like text windows and gui controls, re-drawing the contents each time a portion of the window is exposed is a reasonable approach, but for complex graphics, repeatedly re-drawing the entire window each time gets costly. The first response to this is to confine drawing to the update region, but even this can be too costly for complex (or slow to calculate) graphics.

The next step is to not draw directly to the window during the paint message, but rather create an off-screen buffer (device context) compatible with the window and draw into that. Then when paint messages are received, blit the appropriate portion (update region) of the off-screen DC into the window's DC.

However, unless things have moved along markedly since I last looked at Win32::GUI, much of the underlying system API required to implement this schema, has never been exposed via the module. (And again, unless things have improved substantially, even that functionality that has been implemented is often scarsely documented, which makes working out how to do things quite hard.)

Finally, I have my doubts whether Win32::GUI and Perl is an appropriate toolset for drawing complex graphics. I'd guess that the intent of the module was mostly to allow access to the pre-defined control types, not impement complex graphics.