Fast 2d window painting

[inbugable]

Hi, I'm looking for a way to paint a window very quickly (it shouldn't skip on resize like some do). I need alpha support and gradients, so I tried GDI+ but it was too slow. I'm not making a game, its for an interface that needs to be fast, so I am not sure what to do.

If somebody could give some alternatives other than using 3rd party rendering libraries, I'd appreciate it.

Thanks :)

[srelu]

If you have only one or just a few images, store them in a bitmap and use TransparentBlt.

What makes you to think it's "too slow" ? Flickering ?

[inbugable]

When I resize the window it takes a while to redraw, the window resizes choppily. Mostly because of all the gdiplus functions, gdiplus is extremely slow.

I will have many images eventually.

[srelu]

In this case it' indeed slow.
Usually the libraries have lots of code to be able to hohour any user request. Even if you only need a few of them lots of code is still executed to sort out your options from the many options the library has.

I suggest you to try to use directly the API functions. You can have gradients with the GradientFill function. You can have transparency with TransparentBlt or MaskBlt. If it's still slow you have no other option than simplify the graphics.

Actually it would be one more option. The assembly language can speed up spectacularly the execution (hundreds or thousands of times faster). But there are two problems: One, you need to know the language. Two, it requires much more complex algorithms, you have to handle separately each possible color format (example: the code for the 32 bits/pixel screen will not be the same as the code for the 24 bits/pixel screen).

[JamesSchumacher]

Hi, I'm looking for a way to paint a window very quickly (it shouldn't skip on resize like some do). I need alpha support and gradients, so I tried GDI+ but it was too slow. I'm not making a game, its for an interface that needs to be fast, so I am not sure what to do.

If somebody could give some alternatives other than using 3rd party rendering libraries, I'd appreciate it.

Thanks :)

Most of the time, slow window drawing is due to using a large bitmap, and painting the entire contents onto it before a simple BitBlt onto the window DC. There is a much better approach. I do not know if that is what you are doing, but obviously you have problem with the drawing speed.

The better approach is to calculate only what you need to draw on the screen, and not attempt to draw into a large bitmap or outside the contents of the client. (Or the equivalent memory DC)

I have created a map editor (in fact, I pretty much wrote it all yesterday) that calculates the data it needs before drawing. (Otherwise, it would eat up a whole lot of resources)

Check It Out (http://cid-f7d26664ce20e649.skydrive.live.com/browse.aspx/Public/TXR)

It is possible to just calculate the data you need to draw on the screen, draw it in a mem DC, and Blt that onto the window DC. It also happens to help to keep that memory bitmap in memory and store a 'dirty' flag whether to redraw it's contents or not. Then you can simply BitBlt the memory DC's contents (the bitmap selected in) onto the paint DC, whether you redrew the data or not.

[inbugable]

This would be a good optimisation for me to make, but unfortunately the biggest problem lies with resizing the window, in which it would all have to be redrawn anyways, so this caching wont work for resizing.

[JamesSchumacher]

This would be a good optimisation for me to make, but unfortunately the biggest problem lies with resizing the window, in which it would all have to be redrawn anyways, so this caching wont work for resizing.

With resizing the window, you can do it one or two ways enable speed up. You can do it the easy way and draw a blank screen telling the user to 'wait, resizing' or you can do your drawing also based on relative position versus the window size. (You can do the calculations based on window size as well)

Any EXPENSIVE operations could be flagged to 'not draw' while the window was resizing.

You can allocate a new bitmap for your cache. You can use a larger bitmap than required if they resize to smaller. (Your calculations are the same, internally it is handled if you are using GDI)

Resizing the window is an issue that can be handled similar to scrolling.

[inbugable]

My drawing code calculates the positions for the given window rectangle, but its the actual gdiplus drawing that takes a long time as it resizes.

[JamesSchumacher]

If you can extract the required code you need from this, you can use my Gradient for rectangles. You will have to remove the dependency on my old library code.


EDIT... I have extracted the code myself, I got bored. You can figure from a gradient going top down how to apply it left to right.