Forum

When using ProfUIS, various things may pop up, such as menus, tooltips, etc.  These may overlap with the main workspace.  Our application uses OpenGL for graphics, and rendering a scene can be quite computationally expensive, so we wish to avoid redraws whenever possible.



Now some things that pop up cause a paint message to be sent, and some do not.  For example, with a ribbon bar, the main application menu may be quite large, but it does not send a paint message for the view area, although it overlaps.  I believe it grabs a bitmap and replaces it afterwards?



Drop-downs from ribbon bar items also avoid sending a paint message.



However, tooltips and old-style menus from a menu bar DO send a paint message.  Tooltips are particularly troublesome, because just pausing the mouse somewhere can cause the main window to redraw.  A tooltip comes up, and when it goes away a paint message is sent.  Tooltips may also appear while browsing through a drop-down menu from the ribbon bar.  A redraw at this point draws over the drop-down, since it overlaps our drawing area, leaving a bit of a mess on the screen, and it seems to almost hang sometimes just when moving the mouse up and down on such a menu, until the mouse is moved off the edge.



Anyway, is there a way to avoid the redraw for tooltips?  Can they be handled the same way as the application menu and other ribbon bar drop-downs?  And same question for old-style menus from the menubar.



On the other hand, sometimes we actually want to redraw while the application menu is open.  For example, we select a recently used file.  It loads and redraws while the menu is still fading out.  However, as the menu fades out it is replaced by the previous contents of the window, after which the view remains drawn incorrectly until next forced to redraw.  So I’m also wondering if you have any advice for this.



Thanks,

Rob.

We cannot confirm this. How do we test the background repainting issue? We run the ReportGrid sample application and made its main window non-maximized. Then we made the Visual Studio window restored two. Both windows are floating over the desktop and not intersected with each other. Then we set breakpoint to the beginning of the CExtScrollWnd::OnPaint() method. This is where report grid control handles the WM_PAINT message. Then we clicked the main frame caption of the ReportGrid app and passed the WM_PAINT message to let the main frame activate itself. Now we can invoke the menu bar’s menus. The menu bar is at the top and displayed popup menus always cover the report grid control. We can navigate popup menus and we never receive the WM_PAINT message in the report grid control.
We checked Windows XP SP3, Windows Vista SP 2 and Windows 7 systems on NVidia and ATI cards. All the systems have all the possible latest updates installed.
We also checked Visual C++ 6.0 compiled application, Visual C++ 2005 and 2008. We checked both Win32 and x64 platforms with Visual C++ 2005 and 2008.
Some additional information. The problem really can be provided by not-updated video card drivers. It can also depend from some desktop sharing software capturing the desktop surface.

I test redraws by drawing the background in a slightly different colour each time, so it’s obvious when it happens.

I will try to put some sample code together sometime and see if I can demonstrate the redraws due to menus.

In the meantime, here are some more redraw issues:

(1) The MDI tabs menu always causes a redraw when it disappears.

(2) To avoid screen flicker when I fill data into a tree control (CExtTreeCtrl), I use tree.LockWindowUpdate() before and tree.UnlockWindowUpdate() afterwards.  This should prevent redrawing until I’ve finished filling up the tree.  However when unlocked, the entire screen redraws!  Not just my potentially slow view, but you can also see desktop icons flicker and menus in other programs flicker.  If I don’t do the lock it fixes the problem, so for now that’s my workaround.  I would expect that at worst the locking should cause the whole tree control to be redrawn after the unlock, but not anything else.

Thanks,

Rob.

The reported repainting issues look like specific for your app. We would like to ask to create a test project reproducing them and send it to us.

Actually, here’s something even weirder:

1. I open a drop-down menu from an item on the ribbon bar. (Note opening and closing such menus does not cause a repaint for a view behind it - this is good).


2. Hover over an item to bring up its tooltip


3. Move away which closes the tooltip.  This also sends a repaint message to the view beneath it - this is what I want to avoid.


4. Click somewhere else to close the menu.  Now the bizarre thing is that it not only puts back what was there before from the underlying view, but also the tooltip is back!  If the menu stores a bitmap of what’s behind it before it goes up, it is weird that somehow the tooltip is also being put in that bitmap.  I notice the menu does flash though when we redraw due to the tooltip vanishing.  I guess it decides to redraw too and grabs another bitmap, but I can’t quite work out how it would end up with what I’m seeing.

Any thoughts?

Thanks,

Rob.

Thank you for reporting these issues. Please drop us an e-mail so we can provide you with the source code update.

Thanks, that did indeed fix the issue with the tooltips (ie no more redraw is required).

Old-style menus from a menu bar still seem to cause a redraw though.

Dialog boxes also cause a redraw when closed or moved.  Is there a way I can tell them to store and recover their backgrounds?

Thanks,

Rob.

Oh, something additional: if our users move a dialog box around, then each move of the mouse causes a redraw of the view behind.  If their model is complex this can be quite slow, so the dialog movement is very jerky.  But worse than this is the fact that it gets stuck to the mouse.  So even when they release the mouse button it just keeps following the mouse anyway.  You can get it to let go by clicking and holding for a while before releasing, but in the meantime, the dialog keeps following the mouse regardless which in turn causes lots of slow redraws.

This is presumably the same bug that means sometimes when moving the main window I can’t release it.  Happens when I click on the top titlebar of the window to bring it to the foreground.  This triggers a redraw of course, and because it takes a moment, Prof-UIS somehow doesn’t notice that the mouse button has been released and the whole window then follows the mouse around when it shouldn’t.

Also I presume related to a similar thing when resizing the window.  Sometimes when you release the mouse button it keeps resizing with the mouse anyway.

Aren’t other people having these problems?

Rob.

First of all, please re-upload the latest source code from the same location. Now looks like the popup menu and tooltip control improvements really complete.

The dialog windows are normal windows. They does not guarantee the automatic background saving restoring. You can do one of the following improvements:

1) Improve your complex painted view window and make it keeping a bitmap containing cached image of view surface. This bitmap should be recreated only if the view window is resized or if displayed on it information is changed. This solution will really work.

2) Replace your popup dialog window with a custom coded popup window which is based on the CS_SAVEBITS window class style. This window should be a container for the child dialog window. I.e. your popup dialog should be converted int child dialog type and created inside a popup container window which saves its background. This solution also should work but the CS_SAVEBITS window class style does not provide 100% guaranteed window background restoring especially for big size windows.

I downloaded the latest version, but it doesn’t seem any different.  In particular menus from a menubar still cause a redraw when closed.

Re (1) keeping a bitmap, this is tricky with OpenGL.  If OpenGL is used to render direct to a bitmap, then generally you don’t get hardware acceleration.  The other option is to copy a bitmap from what’s already rendered on screen, but then there are problems if another window or dialog is partly obscuring the window.

Re (2) it sounds like this is unreliable and maybe depends on the OS.  Is there some way to make use of the system you employ for tooltips?  Would be great if you could provided a function to call before opening a dialog box that would make it behave that way.

Rob.