Ribbon performance

This may sound stupid but I noticed that the performance of the Ribbon is way better if an Office 2007 application is also running.

This behavior is reproduceable, start the RibbonSample and move the mouse fast over the groups, the highlighting feels a little bit sluggish, non responsive.

Now start Excel or Access Beta1 TR or Beta2, minimize the Office app and move the mouse cursor over the ribbon groups, very fast and responsive.

Actually the whole application is faster, resize the RibbonSample without an Office app running and with, it is again way faster if an Office app is also running.

I know that this may sound stupid, but the performance increase is amazingly. To be honest if anybody else would tell me that story I would believe that he is stupid.

I guess that there are others who have the Office 2007 Beta installed, so please try it out.

Does anyone else have the same performance problems with the Q2 (10.2) Ribbon/Office 2007 theme?

It's way slower than Q1 (10.1) was, tested on different PCs.

But as soon as an Office 2007 app is running it's as fast as Q1 was.

Ok, those performance problems don't occur on a US Win2K system.

They occur on German Win2k and WinXp systems with Office 2007 installed on the XP system.

I'll try to track the problem down tomorrow, any idea what could cause the problem? Are there any code parts that I can disable to find the bottle neck?

Edit: As long as there are no tabs everything is fine.

Edit: void CXTPOffice2007Image::DrawImage(CDC* pDC, const CRect& rcDest, const CRect& rcSrc, const CRect& rcSizingMargins) const causes the performance problems, the DrawImagePart calls.

Edit 2: CXTPOffice2007Image::DrawImagePart, XTPImageManager()->AlphaBlend

If I set the color depth of my screen to 24-bit everything works fine, but as soon as I set it back to 32-bit it's slow as hell.

The problem is the AlphaBlend function where the source and destination seems to have a different color depth if I set my screen settings to 32-bit. If the DCs are incompatible AlphaBlend is known to be slow.

Could you please fix this ASAP?

Thanks

oleg wrote: All this very strange... Nothing changed from 10.1 , now just ribbon have more images.

How many and how large alpha bitmaps did v10.1 use and how many v10.2 now? The tabs are a large alpha bitmap now and I think it wasn't one in v10.1.

I guess you are using AlphaBlend to use a common set of bitmaps for different themes (Luna / Obsidian), couldn't you instead use non-alpha bitmaps?

Have you been able to reproduce the performance problems with a 32-bit color depth?

oleg wrote: Anyway we plan to improve drawing by adding double buffer and not redraw whole ribbon when something was changed.

That won't help when resizing the window because the Ribbon than needs to be redrawn.

P.S.: I did a quick hack,

BOOL CXTPImageManager::AlphaBlend(HDC hdcDest, const CRect& rcDest, HDC hdcSrc, const CRect& rcSrc) const
{
 return TransparentBlt (hdcDest, rcDest, hdcSrc, rcSrc, 0);
}

which solves all the performance problems. The result doesn't look pretty but I guess for many bitmaps transparency could be used instead of alpha blending.

Oleg, this is a little bit strange, I've tested it on 6 workstations, on 3 it's slow and 3 are ok.

The only thing that they have in common is that 3 have LCD monitors and 3 regular monitors.

On the workstations with a LCD monitor it's slow, but only if the color depth is not 24-bit.

Let me know if I you want to test anything else or need additional information.

gwoin wrote: Did you think about your graphic board's drivers?

I doubt that there is any hardware acceleration for alpha blending, GDI is solely software rendering.

The workstations also all have different graphic cards, from Matrox Millenium 550 / G450 to NVIDIA GeForce and a FX6600.

The problem occurs on several workstations, so I can't believe that I am the only one who has problems with the performance.

gshawn wrote: Still, I do believe the driver question is a valid one. I would check that you have the latest driver on each workstation.

Every workstation has a different graphic card, but they all have the latest drivers. Also AlphaBlending was introduced many years ago, so I doubt that a nVidia Quattro is the bottle neck here

gshawn wrote: Also, you did not mention checking the video hardware acceleration setting. From the Display Properties > Settings > Advanced > Troubleshoot, make sure that the hardware acceleration is set to Full and enable write combining.

I've tried that too, I've set the hardware acceleration to 0% on a workstation where everything is fine and there was no difference.

Have you tested it on a LCD?

Sven wrote: Maybe a ClearType issue?

Windows 2000 doesn't support ClearType and it's definitely the AlphaBlend call that causes the problems. So no need to speculate any longer

Just tried it here and it runs great, sorry...

Acer AL1916A 19" LCD
Windows Server 2003 SP1
Athlon XP 2500+
ATI 9800 Pro via DVI

The compiled Ribbon sample runs great in either 16-bit or 32-bit; I was unable to notice any slowdowns. I'm at a loss as to what to try next... Are there any specific tests or files versions you would like me to check?

ok, we will try to optimize ggraphic to remove alpha layer from some bitmaps. Largest is Office2007_RibbonGroups.bmp so will start from it.

Can you uplease

1. download these bitmaps:

2006-06-10_101439_pack.zip

replace them in Source/Ribbon/res folder,

2. open sampe, replace

void CMainFrame::RecalcLayout(BOOL bNotify /* = TRUE */)
{
 CXTPFrameWnd::RecalcLayout(bNotify);
 Invalidate(FALSE);
}

to

void CMainFrame::RecalcLayout(BOOL bNotify /* = TRUE */)
{
 CXTPFrameWnd::RecalcLayout(bNotify);
// Invalidate(FALSE);
}

it decrease perfomance a lot.

3. rebuild sample and check perfomance.

Thanks

oleg, the non-alpha Office2007_RibbonGroups.bmp has increased the performance alot, although it is still noticeable slower. Thanks.

I understand that alpha bitmaps make it easier to support different color schemes without changing the bitmaps and that there would be a size increase if you would make a set of bitmaps for each color scheme, but have you considered to use PNGs for the graphics? libpng and zlib can be used for free, even in commercial products.

That would reduce the graphics size from about 1.4 MB to 200 KB without any losses. You can also use GDI+ to load PNG resources.

http://www.codeproject.com/bitmap/PNGView.asp

http://www.codeproject.com/vcpp/gdiplus/cgdiplusbitmap.asp

@Marcus: GDI+ can also be used to load PNG resources, you would only have to ship the gdiplus.dll with your application. libpng/zlib is just an other option.

Office 2007 and Vista also uses PNG for its icons. Currently LCDs have a resolution of 96 DPI but soon we will have 240/320 DPI screens and then uncompressed bitmaps are unuseable, or would you like to have 15 MB of Ribbon bitmaps?

Marcus wrote: A lot of developers, like me, prefer clean, simple, self-contained solutions! Adding unnecessary dependencies will only bloat and complicate everything!

What would be the problem if libpng/zlib are added to the workspace? There would just be 2 additionally projects and you could compile the toolkit as always and get a lib or dll. That doesn't complicate anything.