window repainting

[roytam1]

I found that MyDefrag 4.0b2 repaints when scrolling mouse wheel in main window. It even repaints when zoom = 1. I can see the main window blanks for a very short time and then repaints.

[Huggu]

I detected 2 situations where we should avoid zooming:

• dont zoom out when already full zommed out
• dont zoom in any direction when i use a mouse click to bring the program window in front (if the program is not the topmost, dont zoom)

[jimbo]

Related to your first point

Don't attempt to scroll on mouse-wheel movement when fully zoomed out, either.

[roytam1]

Related to your first point

Don't attempt to scroll on mouse-wheel movement when fully zoomed out, either.

People will ask "Why? mouse wheel don't affect JkDefrag."
I think stop repainting when zoom = 1 in programmatical way will be the best solution.

[jimbo]

Uhhh, isn't that what I said?

I was pointing out that it isn't just zoom-outs that you need to not repaint for, but also scroll attempts.

[jeroen]

Thanks everybody for testing and for the feedback, I appreciate it! I will make a note and see what I can do.

[schitzn]

I remember dealing with the BitBlt api and trying to deal with the flicker once myself in a windows app.

The way I dealt with it was create a seperate handle to hold the new painted contents, paint it to this memory handle, then bitblt it to the on-screen handle.  The flicker should cease. Oh, and dont forget to delete the memory handle.  Even better, create on program start and kill it on program exit to minimize overhead.

I coded in *looks around and whispers "vb", so the code I have wouldnt be useful to you being a C++ coder.

[jeroen]

Thanks for the suggestion, but the redrawing described in this thread is not bitblt flicker. The program is actually redrawing the total diskmap, file by file. The MyDefrag v4 graphics are a complete rewrite, totally different and a lot faster than JkDefrag v3.

[schitzn]

There is a white flicker that occurs during the paint process, normally this is due to a clearing of the graphics handle that gets called before the updated graphic is applied, and windows refreshes that clear request to screen prior to the updated graphic being applied.  To avoid the flicker, like a games programmer, one needs to utilize a backbuffer to draw the graphic offscreen and then flip it onto the on-screen buffer rather than using a clear, then dump directly onto the on-screen buffer.

Im assuming your using the GDI api of Windows to do your painting, so surely something around these lines would apply?