PureBasic Forums - English

BeginBufferedPaint and it's brethren.

Here is a great example: http://www.codeguru.com/cpp/misc/misc/g ... c15709__1/
Make sure to check out the BufferedPaintExample_demo.zip run it and resize the window, flickery text, then choose buffered in the menu and resize again, no flickering.

Now I do know that freak redid the drawing in PureBasic, but what I'm really asking here is to use the Buffered API features on Vista and Window 7, on anything older than Vista the native routines would be used.

One cool function in this API is BufferedPaintClear "This function accesses the buffer bits directly and is therefore faster than calling a GDI function to erase the buffer." There is also BufferedPaintSetAlpha and so on.

Buffered drawing supports DIB which is what PB use as default I believe?

There are also GetBufferedPaintTargetRect and a few other Getxxxx.

Another cool thing is that BeginBufferedPaint takes a BP_PAINTPARAMS Structure which lets you specify:
BPPF_ERASE "Initialize the buffer to ARGB = {0, 0, 0, 0} during BeginBufferedPaint. This erases the previous contents of the buffer."
and a pointer to BLENDFUNCTION structure which let to specify how the buffer is blended with the DC (for example the window) when you do EndBufferedPaint

I have no idea if text drawing can be sped up or not using this.

And I have not done any speed tests comparing Buffered API with PureBasic's built in, but I'm assuming similar (with potential for hardware acceleration maybe?)
If anyone feel bored enough to do speeds tests please do so

Why don't you just draw to an image first? Then you avoid the flicker.

The flicker isn't the issue. (at least not any more on PB + Vista)
The example I point to there simply shows that the offscreen stuff freak coded for PB4.40 is available as API in Vista+, which could mean smaller executable and benefit of cached API calls as I assume Vista and Win7 use the Buffered calls a lot? And I'm just guessing here but it's odd if those do not take advantage of the GPU. (I'm assuming the Buffered API calls create the offscreen buffer on the graphics card? or does that use system mem?)

The new 2DDrawing functions do much more than GDI can do (gradients, alpha channel), and they are crossplatform. There is no reason to switch back if there is not really a problem.

A strange looking api for sure; given that you can achieve the same basic results by creating your own off-screen buffer (as most of my apps do). Granted, I haven't studied the api in depth but my first instinct is to ask... why?

That's why I posted, as I'm guessing it could be hardware accelerated...