import processing.opengl.*;

// Ellipse Drawing Test 8/13/2005
// van at <http://wdv.com>
// processing-0092

void setup()
{
size(100, 100, OPENGL);
colorMode(RGB, 1);

smooth(); // works fine when this is commented out.
}

void draw()
{
if(mousePressed)
{
for(int r = 100; r > 0; r -= 10)
{
fill(r/100.0);
ellipse(mouseX, mouseY, r, r);
}
}
}

could you provide a more descriptive summary than "ellipse drawing bug"?

more about the info i need is here:
http://processing.org/faq/bugs.html#found
and here:
http://dev.processing.org/bugs/page.cgi?id=bug-writing.html

edit]
Case 1: OpenGL Ellipse Drawing w/o forced 16 bit zbuf.

This bug manifests when I check the OPpenGL option to
Force 16 bit zbuffer on the Mobility Radeon 7500.
It is unclear if this is Java or the hardware.
I am attaching the "before" and "after" cases.
There is artifact in both drawings.

edit]
Case 2: OpenGL Ellipse Drawing w/o forced 16 bit zbuf.

This bug manifests when I check the OPpenGL option to
Force 16 bit zbuffer on the Mobility Radeon 7500.
It is unclear if this is Java or the hardware.
I am attaching the "before" and "after" cases.
There is artifact in both drawings.

but more simply, what's the bug? that the ellipse is not complete? that when smooth is used
those internal lines are visible?

Ben -

the bug is that ellipses are fractured and discontinuous when smooth() is
on, as illustrated in the case 1 vs. case 2 gif images. This means that for
some population of users using Sony Vaio computers, there is no way to
deploy an antialiased visualization that uses ellipses.

Regards,

- Van

if the bug is caused by checking "force 16 bit zbuffer" then why do that?

i still need a bug description... it's difficult to tell what the issue is in the images. the
internal lines in an ellipse when smooth() is enabled is a known issue. missing triangles
from the ellipse when forcing a 16 bit zbuffer is likely because of zbuffer resolution problems
introduced by doing that.

i am having a hard time communicating with you and that is not your fault.
it is mine. i really like some parts of your cogntive method. clearly they
have solved one of the most important problems of our time: making
java-based graphics available to the common person in almost real-time
interpreted format.

i think in pictures. when i write a set of symbols that are supposed to
produce a specific image, and I do not get that image, then i call that
situation a bug.

i can describe what that bug is, but the truth is, I don't know what the
bug is that causes incorrect rendering. so i sent images to do the
describing for me.

i do know that i am visually senstive to jagged edges, and will do almost
anything to avoid them. i like P3P mode the best, but OpenGL works for
applets and I like to make my work available to everyone, even though it
causes me to live in poverty.

given the choice between 16 bits of depth resolution and 8 bits of depth
resolution I choose 16, unless something bad has happened and clearly it
has. i try to err on the side of sound numerical analysis of a) round-off
b) overflow c) underflow and d) quantization error.

i also prefer doubles to floats because i can do more mathematically
sensitive calculations, but that is another conversation for another day.

the z-buffer is normally 32 bits, not 8, so forcing it to 16 is killing
your precision and causing problems.

edit]
OpenGL settings for Sony Vaio with Mobility 7500

This is the best combination of performance and quality settings that does not
produce ellipse rendering errors.

Thanks for clarifying the 16 bit z-buffer issue. A small drawing artifact
remains for wedge shapped sections of ellipses. The example demonstrates this.

As shown in the attachment three, there is a combination of OpenGL settings
that enable good performance while maintaining quality.

The Diplays-->Advanced-->OpenGL dialog provides options for full scene
anti-aliasing. The 4 sample option causes a serious rendering error and a
HUGE delay in screen update, but the 2 sample option performs quite well.

I propose we close the" bug", and add the OpenGL configuration snapshot to
documentation for users of Sony Vaio computers that are scratching their
heads like I was. My machine is fixed, but I don't want this lesson to be
lost and frustrate other users.

Perhaps the smooth() call and internal anti-aliasing feature of the Radeon
card are in contention with each other.

Cheers,
- Van