Hello,

Double buffering is enabled.

Scene is rendered to back buffer via:

mOpenGLAPI.glDrawBuffer( GL_BACK );

I am hoping to use the back buffer as a storage place...

When a paint message is received the following happens:

 mOpenGLAPI.glReadBuffer( GL_BACK );
 mOpenGLAPI.glDrawBuffer( GL_FRONT );
 mOpenGLAPI.glCopyPixels( 0, 0, ClientWidth, ClientHeight, GL_COLOR);
 mOpenGLAPI.glFlush;

The strange thing is... when the window is moved off the screen... so for 
example the window is half way the monitor...
and then moved back... then a paint message occurs and the same code 
executes again...

But it's like the back buffer is corrupted ?

Is this a known problem with opengl ?

Or is something else causing it ?

Bye,
  Skybuck.

On Sun, 8 Aug 2010 14:53:58 +0200
"Skybuck Flying" <IntoTheFuture@hotmail.com> wrote:

> But it's like the back buffer is corrupted ?

Indeed it is.

> Is this a known problem with opengl ?

Yes, this is a FAQ (at least on the NG).
 
> Or is something else causing it ?

Well, it's not OpenGL per se, which causes this, but the underlying
graphics system. When you move a window off the screen (or even just
move another window on top of if), the graphics system decides, that
the occluded area will no longer hold visible data and no longer keeps
it in a defined state. The backbuffer is just another buffer plane of
the window's visual. And by the graphics system discarding of the
occluded areas also the contents of the backbuffer are lost.

Being sent a WM_PAINT message tells you, that you've to redraw, because
data was lost.

Use a PBuffer or a Frame Buffer Object to get a buffer that is
independent of any interference with the window system. PBuffers are
special: They may be deliberately corrupted in which case a flag is
set, which you must test before retrieving content from a PBuffer and
rerender if needed. If used as a render-to-texture target PBuffers are
protected from this.


Wolfgang

On Aug 8, 3:16=A0pm, Wolfgang Draxinger <wdraxin...@darkstargames.de>
wrote:
>
> > Is this a known problem with opengl ?
>
> Yes, this is a FAQ (at least on the NG).
>

And this is why Starbucky is a waste of time.

"Wolfgang Draxinger" <wdraxinger@darkstargames.de> wrote in message 
news:20100808151623.2a8062ed@narfi.yggdrasil.draxit.de...
> On Sun, 8 Aug 2010 14:53:58 +0200
> "Skybuck Flying" <IntoTheFuture@hotmail.com> wrote:
>
>> But it's like the back buffer is corrupted ?
>
> Indeed it is.
>
>> Is this a known problem with opengl ?
>
> Yes, this is a FAQ (at least on the NG).

Hmm.. I am not familiar with the FAQ's for this NG.

I searched these 6 faq's for the word "back" and "backbuffer" and nothing 
found related to back buffer corruption and possible solutions:

http://www.faqs.org/faqs/by-newsgroup/comp/comp.graphics.api.opengl.html

Perhaps you thinking of another FAQ a link to it would be helpfull or a 
repost of it ;) :)

>> Or is something else causing it ?
>
> Well, it's not OpenGL per se, which causes this, but the underlying
> graphics system. When you move a window off the screen (or even just
> move another window on top of if), the graphics system decides, that
> the occluded area will no longer hold visible data and no longer keeps
> it in a defined state. The backbuffer is just another buffer plane of
> the window's visual. And by the graphics system discarding of the
> occluded areas also the contents of the backbuffer are lost.
>
> Being sent a WM_PAINT message tells you, that you've to redraw, because
> data was lost.
>
> Use a PBuffer or a Frame Buffer Object to get a buffer that is
> independent of any interference with the window system. PBuffers are
> special: They may be deliberately corrupted in which case a flag is
> set, which you must test before retrieving content from a PBuffer and
> rerender if needed. If used as a render-to-texture target PBuffers are
> protected from this.

These solutions depend on extensions...

I want/need a solution which works with opengl 1.1 without extensions...

I have a couple of questions about possible solutions:

1. OpenGL seems to have other buffers as well like auxerily buffers and 
depth buffers
and what not... is there any buffer that does not get corrupted ? Perhaps 
that could
be used to store the image data into... I just need to store a couple of 
colors...
9 or so..

2. Is it possible to draw on the back buffer while window is offscreen and 
then quickly copy it to some other kind
of buffer like a user allocated buffer ?

3. Does the front buffer get corrupted as well if it moves offscreen ? I 
guess so ;)

4. Is there anything in opengl that does not get corrupted if it moves 
offscreen ? ;)

I guess I could store all colors in a color array and simply redraw the 
verteces/primitives really quickly and such...

So then my rendering loop would not actually render anything... but only 
acquire the colors needed for a fast render...

Something like:

procedure Render:
begin
    Collect colors for primitives and store in color array;
end;

procedure Paint;
begin
    Draw primitives with color array to front buffer;
end;

Bye,
  Skybuck. 

On Sun, 8 Aug 2010 15:37:09 +0200
"Skybuck Flying" <IntoTheFuture@hotmail.com> wrote:

> These solutions depend on extensions...
> 
> I want/need a solution which works with opengl 1.1 without
> extensions...

Then you're out of luck. Sorry.

> I have a couple of questions about possible solutions:
> 
> 1. OpenGL seems to have other buffers as well like auxerily buffers
> and depth buffers and what not... is there any buffer that does not get corrupted ?

The buffers you're talking about (auxiliary and accum) are also tied to
the window's visual. (You could deduce that (by a far fetch) from
looking at PIXELFORMATDESCRIPTOR which is part of the GDI, not OpenGL).

> Perhaps that could be used to store the image data into... I just
> need to store a couple of colors...
> 9 or so..
> 
> 2. Is it possible to draw on the back buffer while window is
> offscreen and then quickly copy it to some other kind
> of buffer like a user allocated buffer ?

No. If the window is offscreen there's no practically useable
backbuffer. You must understand that all buffers that are somehow
associated with the window visual share the very same memory layout
with the window visual (that is, that you can use the same pointer
offsets for every buffer). The window visual itself is just a
rectangular portion of the screen framebuffer. You move the window
offscreen the visual is outside of the framebuffer, thus as no size and
so follow the OpenGL buffers.

An exception is, if the windows themself are placed in offscreen
buffers, like it is done in X11/AIGLX used for creation of nice 3D
compositing effects (Linux/X11 was the very first OS to have these,
MacOS X and Windows Vista are just "cheap" copies - no wonder,
implementing such stuff with X11 was a piece of cake, though the
architecture went through some significant changes).

> 3. Does the front buffer get corrupted as well if it moves
> offscreen ? I guess so ;)

Yes.

> 4. Is there anything in opengl that does not get corrupted if it
> moves offscreen ? ;)

Offscreen buffers.

PBuffer and Frame Buffer Objects have been invented for exactly that
reason and usage pattern. Frankly I'd be very suprised if you today
found any OpenGL installation (except the Windows software fallback)
that doesn't support at least one of them.

> I guess I could store all colors in a color array and simply redraw
> the verteces/primitives really quickly and such...
> 
> So then my rendering loop would not actually render anything... but
> only acquire the colors needed for a fast render...
> 
> Something like:
> 
> procedure Render:
> begin
>     Collect colors for primitives and store in color array;
> end;
> 
> procedure Paint;
> begin
>     Draw primitives with color array to front buffer;
> end;
> 
> Bye,
>   Skybuck. 

Something like that. But instead of color arrays (assuming you want
to feed them through glColorPointer) I'd use a texture. Preferrably a
GL_TEXTURE_RECTANGLE. Although it's an extension to OpenGL 1.1, there's
hardly any implementation not supporting it, and to use it you only
need the value of the GL_TEXTURE_RECTANGLE token.

Initialize the texture object once with
glTexImage2D(GL_TEXTURE_RECTANGLE, ..., NULL), yes, you can supply a
null pointer to glTexImage in which case it will just initialize the
texture but not yet fill it with content. Then you glCopyTexSubImage to
save the contents of the buffer you want to retain.

I admit that this whole offscreen buffer issue is rather poorly
documented, especially using PBuffers on Windows. So this is probably
the first time you asked a legitimate question on c.g.a.opengl which
you couldn't have solved yourself by 5 minutes on Google. IIRC it
took me one week to get PBuffers working, reading numerous specs
front-to-back, when I tried to use them the first time. Frame Buffer
Objects OTOH are as simple to use, as textures. Unfortunately their
support varies greatly between operating systems and GPUs. On Windows
only NVidia and AMD do have them.

But they're supported rather well on X11; probably because PBuffers
always have been a mess to use in X11 - it's not so much the API that
gets in your way, but the way they've been implemented between libGL.so
(the *nix counterpart to opengl32.dll), the X11 driver and auxiliary
libraries. Depending on the GPU used you either had to install a GPU
specific libGL.so to make them work (nasty if you got multiple GPU
from different vendors in your box), or had to wade through preloader
tricks in the X11 startup to inject the correct one. It got better
lately, but Frame Buffer Objects got there first.


Wolfgang

On Sun, 08 Aug 2010 16:13:23 +0200, Wolfgang Draxinger wrote:

> Depending on the GPU used you either had to install a GPU
> specific libGL.so to make them work (nasty if you got multiple GPU
> from different vendors in your box),

Or if your X server isn't running on the same box as the application.

What about draw to bitmap ?

The bitmap isn't even on the screen ?

Shouldn't that work ?

Maybe opengl can do glCopyPixels from a bitmap context to a window context ? 
Maybe by sharing the contexts ?

Bye,
  Skybuck. 

On Sun, 8 Aug 2010 19:23:58 +0200
"Skybuck Flying" <IntoTheFuture@hotmail.com> wrote:

> What about draw to bitmap ?

That's not HW accelerated. PFD_DRAW_TO_BITMAP makes GDI fall back to
the software rasterizer.

> The bitmap isn't even on the screen ?

It's not even on the hardware. Also a FAQ.


Wolfgang