Overlapping glCopyPixels

Overlapping glCopyPixels

Post by Cesar Blecua Udia » Fri, 25 May 2001 21:25:50



What does it happen when the source and destination rectangles of a
glCopyPixels overlap? According to the IRIX 6.5 glCopyPixels manpage,
pixels are copied in row order from the lowest to the highest row, left
to right in each row. So, I assume that copying overlapping rectangles
is not safe in general. Is this assumption right?

An special case (used by many people) happens when copying a rectangle
to itself, just for image processing operations.

However, I suppose that copying a rectangle to itself can fail for some
ARB_imaging operations, such as convolution (if you're blurring an
image, the convolution kernel could be using already blurred pixels).

I found no specific information about this at the OpenGL specification
nor manpages. Anybody knows something or has pointers to more
information?

Thanks in advance,

Csar Blecua

 
 
 

Overlapping glCopyPixels

Post by Robb Willia » Sun, 27 May 2001 02:08:41


Cesar,

I know the 3dLabs Oxygen GVX1 card has a glCopyPixels glitch. When
one shifts an area of pixels directly left on the offsceen buffer
(double buffered format), the result is messed up. Some pixels
don't transfer correclty, leaving an unpleasant visual appearence.
The folks at 3dLabs suggested using the onscreen buffer as the
source buffer instead of the offsceen buffer. In our case, it fixed
the problem.

Robb


> What does it happen when the source and destination rectangles of a
> glCopyPixels overlap? According to the IRIX 6.5 glCopyPixels manpage,
> pixels are copied in row order from the lowest to the highest row, left
> to right in each row. So, I assume that copying overlapping rectangles
> is not safe in general. Is this assumption right?

> An special case (used by many people) happens when copying a rectangle
> to itself, just for image processing operations.

> However, I suppose that copying a rectangle to itself can fail for some
> ARB_imaging operations, such as convolution (if you're blurring an
> image, the convolution kernel could be using already blurred pixels).

> I found no specific information about this at the OpenGL specification
> nor manpages. Anybody knows something or has pointers to more
> information?

> Thanks in advance,

> Csar Blecua



 
 
 

Overlapping glCopyPixels

Post by bof » Sun, 27 May 2001 10:51:41


If you look at the OpenGL spec under glCopyPixels, it's written (IIRC) that
overlapping glCopyPixels should be supported. (I know for sure that ATI
supports it, since I was involved in programming/debugging that feature.)

Christian Laforte
A|W


> Cesar,

> I know the 3dLabs Oxygen GVX1 card has a glCopyPixels glitch. When
> one shifts an area of pixels directly left on the offsceen buffer
> (double buffered format), the result is messed up. Some pixels
> don't transfer correclty, leaving an unpleasant visual appearence.
> The folks at 3dLabs suggested using the onscreen buffer as the
> source buffer instead of the offsceen buffer. In our case, it fixed
> the problem.

> Robb




> > What does it happen when the source and destination rectangles of a
> > glCopyPixels overlap? According to the IRIX 6.5 glCopyPixels manpage,
> > pixels are copied in row order from the lowest to the highest row, left
> > to right in each row. So, I assume that copying overlapping rectangles
> > is not safe in general. Is this assumption right?

> > An special case (used by many people) happens when copying a rectangle
> > to itself, just for image processing operations.

> > However, I suppose that copying a rectangle to itself can fail for some
> > ARB_imaging operations, such as convolution (if you're blurring an
> > image, the convolution kernel could be using already blurred pixels).

> > I found no specific information about this at the OpenGL specification
> > nor manpages. Anybody knows something or has pointers to more
> > information?

> > Thanks in advance,

> > Csar Blecua


 
 
 

Overlapping glCopyPixels

Post by César Blecua Udía » Mon, 28 May 2001 02:31:10


Thanks for your reply, Christian and Robb.

Unfortunately, I'm not able to find any comment about overlapping
glCopyPixels at the OpenGL 1.2 spec (page 126, glCopyPixels
description).

Do you remember if overlapping glCopyPixels should be supported for all
paths (for example, when convolution is enabled) ?

Doing convolution (and other ARB_imaging operations) at the original
pixels location would save me of allocating more than one pbuffer. I'd
like to be sure that this feature is mandatory from the spec (I won't
use it if some machines can fail).

Csar


> If you look at the OpenGL spec under glCopyPixels, it's written (IIRC) that
> overlapping glCopyPixels should be supported. (I know for sure that ATI
> supports it, since I was involved in programming/debugging that feature.)

> Christian Laforte
> A|W



> > Cesar,

> > I know the 3dLabs Oxygen GVX1 card has a glCopyPixels glitch. When
> > one shifts an area of pixels directly left on the offsceen buffer
> > (double buffered format), the result is messed up. Some pixels
> > don't transfer correclty, leaving an unpleasant visual appearence.
> > The folks at 3dLabs suggested using the onscreen buffer as the
> > source buffer instead of the offsceen buffer. In our case, it fixed
> > the problem.

> > Robb



> > > What does it happen when the source and destination rectangles of a
> > > glCopyPixels overlap? According to the IRIX 6.5 glCopyPixels manpage,
> > > pixels are copied in row order from the lowest to the highest row, left
> > > to right in each row. So, I assume that copying overlapping rectangles
> > > is not safe in general. Is this assumption right?

> > > An special case (used by many people) happens when copying a rectangle
> > > to itself, just for image processing operations.

> > > However, I suppose that copying a rectangle to itself can fail for some
> > > ARB_imaging operations, such as convolution (if you're blurring an
> > > image, the convolution kernel could be using already blurred pixels).

> > > I found no specific information about this at the OpenGL specification
> > > nor manpages. Anybody knows something or has pointers to more
> > > information?

> > > Thanks in advance,

> > > Csar Blecua


 
 
 

Overlapping glCopyPixels

Post by Andrew F. Vespe » Mon, 28 May 2001 10:47:10



> Unfortunately, I'm not able to find any comment about overlapping
> glCopyPixels at the OpenGL 1.2 spec (page 126, glCopyPixels
> description).

> Do you remember if overlapping glCopyPixels should be supported for all
> paths (for example, when convolution is enabled) ?

The closest that the spec comes to defining this is the order of operations
in describing it:

QUOTE
Values are obtained from the framebuffer, converted (if appropriate),
then subjected to the pixel transfer operations described in section 3.6.5,
just as if ReadPixels were called with the corresponding arguments. If the
type is STENCIL or DEPTH, then it is as if the format for ReadPixels were
STENCIL INDEX or DEPTH COMPONENT, respectively. If the type is COLOR, then if
the GL is in RGBA mode, it is as if the format were RGBA, while if the GL
is in color index mode, it is as if the format were COLOR INDEX.

The groups of elements so obtained are then written to the framebuffer
just as if DrawPixels had been given width and height, beginning with
final conversion of elements. The effective format is the same as that already
described.
END QUOTE

Because the spec says that the values are obtained "just as if ReadPixels were
called" and
later says "written ... just as if DrawPixels ...", I feel the only valid
interpretation
is that the result must be as if read into main memory and then written. Thus,
when the rectangles overlap, the "values obtained" must be prior to the values
written.

You can ask the ARB to clarify this, if you need an answer more authoritarian.

--
Andy V (OpenGL Alpha Geek)
"In order to make progress, one must leave the door to the unknown ajar."
Richard P. Feynman, quoted by Jagdish Mehra in _The Beat of a Different Drum_.

Paul Martz's OpenGL FAQ: http://www.opengl.org/developers/faqs/technical.html

 
 
 

1. Overlapping glCopyPixels

What does it happen when the source and destination rectangles of a
glCopyPixels overlap? According to the IRIX 6.5 glCopyPixels manpage,
pixels are copied in row order from the lowest to the highest row, left
to right in each row. So, I assume that copying overlapping rectangles
is not safe in general. Is this assumption right?

An special case (used by many people) happens when copying a rectangle
to itself, just for image processing operations.

However, I suppose that copying a rectangle to itself can fail for some
ARB_imaging operations, such as convolution (if you're blurring an
image, the convolution kernel could be using already blurred pixels).

I found no specific information about this at the OpenGL specification
nor manpages. Anybody knows something or has pointers to more
information?

Thanks in advance,

Csar Blecua

2. Lightwave erfahrung ?

3. Getting leftovers from overlapping windows with glCopyPixels.

4. HELP! PPC 7100AV RGB->NTSC mirror?

5. glCopyPixels() speed? (was: Re: glCopyPixels(...,GL_DEPTH) ?)

6. Building a new machine

7. glCopyPixels on iR

8. Simple Texture mapping

9. PBuffer and glCopyPixels

10. glCopyPixels Performance

11. geforce4go, glMinmax, glCopyPixels

12. Is glCopyPixels supposed to be so slow?

13. Scrolling with glCopyPixels misses column