Professional UI Solutions
Site Map   /  Register
 
 

Forum

Please Log In to post a new message or reply to an existing one. If you are not registered, please register.

NOTE: Some forums may be read-only if you are not currently subscribed to our technical support services.

Forums » Prof-UIS Tech Support » Painting of windows is very slow Collapse All
Subject Author Date
John Frederickson May 12, 2011 - 12:07 PM

We are using v2.90.

The drawing slows to a crawl during any redraw (clicking on a menu, switching tabs, etc.).

The Task manager shows memory utilization spiking, and heavy disk I/O during the slow down, but no process is reported as using the memory.

So far this seems to mostly occur on Windows XP 64 bit or Windows Server 2003 machines and seems to be greatly exaggerated when viewing the machine via a Remote Desktop Connection.

Any idea as to what could be causing this, or how we might fix it?

Technical Support Jun 22, 2011 - 11:42 AM

We cannot avoid creating a memory DC. There are no chances to implement clipping without a memory DC. Please add DT_NOCLIP flags into invocation of the CExtRichContentLayout::stat_DrawText() API in your project.

John Frederickson Jun 3, 2011 - 9:49 AM

None of these seem to be the problem. We don’t use OnIdle(), and timers only rarely (and not at the time we are seeing this painting issue) and our command updating uses cached values wherever possible. Yet this is still a problem even after we updated to v2.92.

As I said, this only seems to happen over a Remote Desktop Connection, and then only sometimes. Do you have any other ideas?

Technical Support Jun 3, 2011 - 11:13 AM

Does this problem go away if your app uses a simple UI theme (Office 2000, Office XP) while running over a remote desktop connection? These themes are light and fast as possible because everything is painted without bitmap based skins and gradient fills.

John Frederickson Jun 9, 2011 - 5:24 PM

We aren’t using themes. But it does go away if I change CExtRichContentLayout::stat_DrawPlainText() to not increase the rectangle by 32767x32767 when it comes in empty, thus NOT allocating a 2GB DC (on a machine that only has 2 GB RAM to begin with).

Technical Support Jun 10, 2011 - 10:31 AM

Please provide us with more details about 32767x32767 painting device surface. How does CExtRichContentLayout::stat_DrawPlainText() method create such big memory surfaces in your app?

John Frederickson Jun 13, 2011 - 4:23 PM

int CExtRichContentLayout::stat_DrawPlainText( CExtRichContentLayout::e_layout_orientation_t eLO, HDC hDC, __EXT_MFC_SAFE_LPTSTR str, int nCount, LPRECT lpRect, UINT nDTF /*= 0*/, UINT nExtDTF /*= 0*/, HWND hWndOpenThemeData /*= NULL*/, LPCVOID wstrOpenThemeDataClassList /*= NULL*/, DWORD dwOpenThemeDataFlags /*= 0*/, int nDtThemePartID /*= 0*/, int nDtThemeStateID /*= 0*/, CExtUxTheme::__EXT_UX_DTTOPTS * pDTO /*= NULL*/, CExtRichContentLayout::DRAWSTATE_data_t * pDSD /*= NULL*/ )
{

//NOTE: lpRect = {0,0,0,0} (possibly because the string we are trying to render is, " " (9 spaces)?)
[...snip...]

CRect rcDocRenderTarget, rcTmpSrc;

//NOTE: takes the ’else’ path

    if( lpRect == NULL )
    {
        dc.GetClipBox( &rcDocRenderTarget );
        rcTmpSrc = rcDocRenderTarget;
        lpRect = &rcTmpSrc;
    }
    else
    {
        rcDocRenderTarget = (*lpRect);
        if( rcDocRenderTarget.Width() <= 0 )
            rcDocRenderTarget.right = rcDocRenderTarget.left + 32767;
        if( rcDocRenderTarget.Height() <= 0 )
            rcDocRenderTarget.bottom = rcDocRenderTarget.top + 32767;
    }

//NOTE: rcDocRenderTarget rect now has width = 32767, height = 32767

    if( ( nDTF & (DT_NOCLIP|DT_CALCRECT) ) == 0 )
    {
        CExtMemoryDC dcMem(
            &dc, &rcDocRenderTarget,
            CExtMemoryDC::MDCOPT_TO_MEMORY | CExtMemoryDC::MDCOPT_FILL_BITS | CExtMemoryDC::MDCOPT_RTL_COMPATIBILITY
            );
//NOTE: very BIG dcMem now :-(

[...snip...]

Technical Support Jun 15, 2011 - 11:27 AM

Unfortunately, we cannot exclude this memory DC usage because we need to provide optional support for plain text and HTML clipping. Why do you need extra a large rectangle for text output and clipping at the same time?

John Frederickson Jun 16, 2011 - 2:01 PM

I don’t. The real question is, why do you?

Like I said, I changed your code to use (a much more reasonable, but still excessive) 4096 x 2048 and it solved my problem.

Jeroen Walter Jun 22, 2011 - 4:54 AM

Is there any news on this issue?


I find it very disturbing that ProfUis can decide to create a 32kx32k bitmap of 32bit color, i.e. about 4 billion bytes......


This is not yet fixed in profuis 2.92....


 

Technical Support May 13, 2011 - 12:32 PM

First of all, there are three things to check:

1) Idle time processing. If your application overrides the CWinApp::OnIdle() virtual method, then it should not be heavy. It should return execution control as fast as possible.

2) Timers. Do not use many timers in the main UI thread. Do not use very frequent timers. Timer handler methods also should not be heavy and return execution control as fast as possible.

3) Command updating methods. These methods should be especially short and simple. The should just invoke CCmdIU class methods and immediately return execution control.

In all the cases, the handler methods should not access any slow APIs like database queries, network requests, etc. The last case is especially important. If you need to set checked or enabled state of some toolbar button or menu item, then the command updating method should be based on some bool flags which are preliminary computed in command handler method(s).

John Frederickson Jun 3, 2011 - 9:51 AM

(Sorry, my reply post was out of order. Please refer to the June 3rd post above.)