2

Some background: in order to learn GUI programming and drawing in Windows I'm starting to create my own GUI toolkit in Windows (so this is a didactic exercise, please don't suggest "use Qt" or "use MFC").

I would like to draw the entire window area from memory DCs in double buffering (thus also handling mouse and keyboard events myself) but I'm now wondering how should I handle resize events from the window: suppose I have a text control and a sidebar and my window gets a resize command

enter image description here

the sidebar should grow larger and the text control should show more text (it is also larger).

The first thing that comes to my mind is to redraw all the widgets on the memory DC and then BitBlt it to the screen. Anyway some widgets might not have changed at all or might be changed just a bit (the portion "Text here, text here, te" hasn't changed at all during the resize).

What can be done to exploit this fact and avoid redrawing (even in memory DC, not device DC) the parts which haven't changed?

  • Who is responsible for drawing in your "double buffering" context? Do the controls draw their images to the window buffer (using a "drawing context = DC" object, which actually does the drawing)? Or do they pass their image data to the window, and the window itself does the drawing? And concerning the "redraw" - do you pass always the same DC object for all "repaint" operations? Or is it always a new DC, operating on the existing buffer? And, when your window resizes, do you allocate a new buffer? Or do you have a preallocated buffer for the max window size? – Doc Brown Aug 28 '14 at 8:10
  • First comment: It really matters whether this is a widget toolkit with a paint handler, games-like with a render loop, or canvas-like. The answer is different for each. – david.pfx Aug 28 '14 at 14:25
  • Second comment: No, don't use Qt or MFC, but do you really have to use GDI? Even GDI+ is pretty weak and really can't handle transparency, alpha channel, blends or lots of other cool stuff. WPF and XNA are based on DirectX, which is way nicer. – david.pfx Aug 28 '14 at 14:29
  • @david.pfx Thanks, anyway I wanted to write code that could (more or less) easily get ported to GTK+ on linux. WPF and XNA would be even more difficult due to the differences between the frameworks. – user3834459 Aug 28 '14 at 19:59
4

You'll want to redraw the whole thing. Keeping track of which parts are still the same as the unsized image is going to be computationally more difficult as simply redrawing the whole lot, especially considering that in general usage you're going to have a dialog full of controls, not full of whitespace. Even in the case of text, the text displayed will be wrapped at different points, and thus require redrawing.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.