Hi everyone,

2 weeks ago I upgraded to Windows 7, and until then I wasnt aware of the terrible performance of GDI+ on Windows 7. Since VSTGUI 3.6 uses GDI+, and I'm locked to version 3.6 for a while, I had to find a "workaround"...

So, after some testing, coding, yes I found it! And I want to share this with all the developers here:

You need to modify CBitmap->draw function, so that it does NOT draw with GDI+, but just uses BitBlt/AlphaBlend functions found in Win32. That DOES the trick!

For BitBlt/AlphaBlend you'll need the images as HBITMAP though...

If your bitmap is scaled while drawing though (again for this you need to modify the CBitmap->draw function, VSTGUI 3.6 does not scale images), you'll have to draw the image with GDI+ so it draws the image antialiased.

Once I did this change, my plugin user interface went back to normal...

which problem your has?
http://www.kvraudio.com/forum/viewtopic.php?p=4483274#448327 4
full written in GDI+

greets

???

GDI+ performance is fully hardware acclerated both in Vista and Win7, but Win32 GDI uses software-based rendering since Windows Vista.

Did you profile your plugin properly? Are you really sure it was GDI+?

Wouldn't that add to cpu hit?

I dont think thats true. GDI+ has never been hardware accelerated except in those few cases where it could use GDI to do the work for it. This situation has not changed on Vista or 7, except that somewhere along the path HW acceleration for GDI got dropped.

Maybe you're getting confused with Direct2D, which is HW accelerated in Vista and 7.

What I noticed with VSTGUI 3.6 on XP SP3 is that if the background bitmap is a PNG the CPU load on animations (like knobs moves) increases too much. Possibly
there's a bug which decodes the PNG for each and every frame (timer tick)
kv331 do you use PNG or BMP ?

Always use pixel format 32 bit PARGB for everything, dont mix formats.

And dont assume that you will end up with a specific format just cause the source image has that format. Load the image and then set it to the required format.

If you don't do that you will not only increase the amount of work GDI+ has to do (converting pixel formats for each op) but you will also make it less likely that bitblit operations can be offloaded onto GDI and hence you will lose its HW acceleration.

if you want real speed, gdi isn't much of a match for gl as long as you can deal with getting the texture coordinates right.

i concur regarding gdi though - it's hardware accelerated since win3.0. the video drivers specifically must implement the bitblt function and a few others. if it wasn't accelerated do you think it could draw 50 windows layered on the screen at 1920x1600 resolution without a stutter? well, it does do so without any issue.

what really slows it down is when you use the wrong dib format vs. the desktop format and then bitblt becomes software - major speed hit.

Thanks so much, it's something I have to do. BTW shouldn't a lib like VSTGUI take care to set 32 bit PARGB anyway? And if it doesn't why it doesn't offer an option? Or does it?

Cheers

GDI+ (the "failed GDI successor") has never been accelerated. GDI was accelerated, then wasn't in Vista, then was again partially in Win7. Direct2D is in Vista & above, and is accelerated (that said, accelerated or not, D2D seems pretty slow here).




well for the optimal speed you have to use DDB's, and those are useless since you can't access the pixels. Even RGBA DIBs are slower to paint, but I noticed that they were faster when they were blitted using a handle (as DIBSections).

It's a pity that Windows keeps adding stuff that we can't use until they're already obsolete. No one would be crazy enough to use D2D until the WinXP userbase has fully disappeared, and that will take years. All it needed is support (even non-accelerated) for D2D in XP. Well there's portability concerns as well so OpenVG is probably a better choice.




yes, because when the GDI was used to do desktop composition, it was done through invalidated zones, not constantly (like a videogame) like Vista does through D3D acceleration. Windows weren't drawn using painter algo, a window behind another wasn't drawn.

i'm talking about when just displaying graphics on the screen, moving windows around and so on.

try this, create a lot of windows around the screen of various sorts. they don't need to be animated, they just need to redraw correctly on a wm_paint message. drag another window over top with "display window while dragging" enabled, so it doesn't just have a xor outline but the entire window. see how many windows you need under there to make it start to cost cpu or stutter while you're moving the foreground window around.

with windows that update correctly by just restoring their surface bitmap, (such as explorer windows) you can hardly notice any latency at all, even with windows covering the entire screen. it isn't fair to use just one fullscreen window because that only requires one surface/canvas bitmap and not several as with multiple windows.

with windows that try to draw anything in a wm_paint message (bad programming in my opinion, and goes against what microsoft recommends for years) you'll notice a major cpu issue - generally when windows are being totally retarded and trying to use gdi+ lines and stuff in a wm_paint. (facepalm...)

if gdi's basic bitblt was not accelerated, all applications would have severe drawing problems. i don't have any problem using bitblt on vista or win7 - so apparently this is not the case. it works fine, exactly as in winxp.

GDI IS accelerated in Windows 7 if your video drivers support it - from the horses mouth :

http://msdn.microsoft.com/en-us/library/ff566559(v=vs.85).as px

but it won't invalidate more than the size of the screen anyway (in XP), why does the amount of windows matter? (& yes their content will matter)




bad programming to draw in wm_paint?? Where else would you draw? IMHO it's bad programming to draw anywhere else. Caching very CPU-heavy stuff is ok but that's all. Painting in an offline bitmap once just to draw it faster in a wm_paint IS bad programming, because it's wasting memory, while Vista already does its own similar caching in the DWM, so you're wasting (big) memory twice for the same thing.



you're underestimating today's CPUs, obviously the CPU isn't gonna blit a gazillion of polygons, but we're talking about a couple of memory copies here.
If GDI is slow, it's because of the crap a simple function has to follow inside, & all the checks. So you won't fill thousands of tiny rectangles efficiently, but copying big rectangles is nothing for today's CPUs.
Maybe just the AlphaBlend function would have to be accelerated, and even here it's no rocket science to do an RGBA blit efficiently. Poly's with perspective, now that would be something else (that really requires acceleration & that's why Vista uses D3D).

see if you can write noise into, then memcpy 1920x1600x32 at 60fps using the cpu.

good luck.

(btw: 6gbps bandwidth)

even though the alphablit is accelerated, they still only implemented premul, and refuse to implement a full blend function due to speed issues.

why should different windows be used? random memory accesses. more windows = less efficiency. worst case, 1x1 pixel windows with their memory at random non-linear locations.

if you draw anything complex, precache it. period. using up 100% cpu due to dragging another window over yours while you're having to use complex gdi+ software rendering functions over and over to draw _identical_ content is plainly retarded. memory? you're concerned about a couple megs? we have gigs of memory sitting unused in a majority of machines.

if we're talking about an application that actually uses memory, what is 12mb compared to 100s of mb allocated for other reasons? 12mb = 1920x1600x32.

if you're insulted because you do this, then you ought to be. you should definitely rethink your methods and apply some bitmap caching. at least consider the facts of the situation. memory is worth a hell of a lot less than cpu cycles. it's by far in a majority of cases worth it.

also, i wonder if you have any idea who you're talking to.