Run the following program against 1.2beta4-J and you will see rows
of circles painted with fillOval to an offscreen image.  However,
the circles will have several flat edges which make them look 
more like polygons than circles.  This doesn't happen under 1.1.6,
nor does it happen when painting directly to a component.

import java.awt.*;
import java.awt.event.*;

public class CircleBug extends Panel {
    
    public CircleBug() {
	super(null);
	
	setSize(400, 400);
	buffer = null;
    }

    public void paint(Graphics g) {
	if (buffer == null) {
	    Dimension size = getSize();
	    Graphics bg;
	    int x, y;
	    
	    buffer = createImage(size.width, size.height);
	    if (buffer != null) {
		bg = buffer.getGraphics();
		
		bg.setColor(Color.black);
		bg.fillRect(0, 0, size.width, size.height);
		bg.setColor(Color.white);
	
		x = 0;
		y = 0;
		while (y < size.height) {
		    while (x < size.width) {
			bg.fillOval(x, y, 36, 36);
			x += 40;
		    }
		    x = 0;
		    y += 40;
		}
	    }
	}
	
	if (buffer != null) {
	    g.drawImage(buffer, 0, 0, this);
	}
    }

    public static void main(String args[]) {
	Frame frame = new Frame("2D Circle bug");
	
	frame.addWindowListener(new WindowAdapter() {
	    public void windowClosing(WindowEvent e) {
		System.exit(0);
	    }
	});
	frame.setLayout(new BorderLayout());
	frame.add("Center", new CircleBug());
	frame.pack();
	frame.setVisible(true);
    }

    protected Image buffer;
}





c:\users\default>java -version
java version "1.2.1"
HotSpot VM (1.0fcs, mixed mode, build E)

c:\users\default>java -fullversion
java full version "JDK-1.2.1-A"

Please find code below.  

g2.draw(new Ellipse2D.Double(40.0, 100.0, 20.0, 20.0)); produced a much poorer circle both on screen and printer then its g.drawOval... counterpart.

I thought it was supposed to be the other way around???
________________________________
package printing;

import java.awt.*;
import java.awt.event.*;
import java.awt.print.*;
import java.awt.geom.*;
import javax.swing.*;

public class FramePrint extends JFrame {

    public FramePrint() {

        JMenuBar menuBar = new JMenuBar();
        setJMenuBar(menuBar);

        JMenu menuFile = new JMenu("File");
        menuBar.add(menuFile);

        JMenuItem itemPrint = new JMenuItem("Print");
        menuFile.add(itemPrint);
            itemPrint.addActionListener(new ActionListener() {
                public void actionPerformed(ActionEvent e) {
                    print();
                }
            }
                                        );

        setSize(100,200);
        setVisible(true);
    }

    public void paint(Graphics g) {
        super.paint(g);

        Graphics2D g2 = (Graphics2D)g;

        g2.draw(new Ellipse2D.Double(40.0, 100.0, 20.0, 20.0));

        g.drawOval(70, 100, 20, 20);
    }

    public void print() {
        //NOTE how can a PrinterJob be related to a PrintJob?????
//        PrinterJob.getPrinterJob().pageDialog(new PageFormat());
        PrintJob printJob = Toolkit.getDefaultToolkit().getPrintJob(this, "blah", null);
        Graphics g = printJob.getGraphics();
        this.paint(g);
//        printAll(g);this will print all GUI components, but not the custom graphics
        g.dispose();
        printJob.end();
    }

    public static void main(String[] args) {
        new FramePrint();
    }
}
(Review ID: 84211)
======================================================================




FULL PRODUCT VERSION :
java version "1.4.0-rc"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.0-rc-b91)
Java HotSpot(TM) Client VM (build 1.4.0-rc-b91, mixed mode)

FULL OPERATING SYSTEM VERSION :
Windows 2000 SP2

A DESCRIPTION OF THE PROBLEM :
This is not a duplicate of the related 4151279. In 4151279,
it is pointed out that offscreen rendering of circles does
not work quite right and does not produce circles. While
4151279 is not closed, the last Sun comment is from
1998-08-13 and it does not appear that this bug is truely
open (you have released 1.2, 1.3 and 1.4 since then).

In light of this, the API specifications should be changed
(or at least the documentation). It presently reads, "Draws
the outline of an oval." But does nothing of the sort, As i
mentioned in 4151279, i made a 8.5 pixel diamater circle and
got something back with two edges that were 8 pixels long.

I would suggest a change to "draws a shape that fits within
a rectangle of dimensions... that, at times, resembles an oval."

here is the web link to you documentation
http://java.sun.com/j2se/1.4/docs/api/java/awt/Graphics.html#drawOval(int,%20int,%20int,%20int)

NOTE: comments and opinions of the author are independant of
those of EML, DOE, and the US government.


REGRESSION.  Last worked in version 1.1.8

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
1.see 4151279, there is code there.
2.also look at the user who claims that drawOval(a,b,c,d)
followed by drawOval(a,b,c,d) does not produce the same output!
3.

EXPECTED VERSUS ACTUAL BEHAVIOR :
I expect the Documentation to document what the JMV does. It
does not.

For 4151279 the expected result is a circle (even when the
oval is drawn off screen) and the results are a football/oval.

This bug can be reproduced always.

---------- BEGIN SOURCE ----------
import java.awt.*;
public class Class extends Frame{
  public static void main(String[] args) {
    Class c = new Class();
    c.setSize(100,100);
    c.setVisible(true);
    c.repaint();
  }
  //note that just double buffering doesn't make it very bad
  //calling another method with an image to draw on
  //is what makes it _very_ bad
  public void paint(Graphics g) {
    Image i = this.createImage(this.getWidth(),this.getHeight());
    drawOnIt(i);
    drawOnIt(i.getGraphics());
    g.drawImage(i,0,0,this);
  }
  //draws "ovals"
  public void drawOnIt(Image i) {
    Graphics g = i.getGraphics();
    g.setColor(Color.black);
    for(int h=0;h<=15;h++)
      g.drawOval(30+(h*35),30,h+1,h+1);
    for(int h=0;h<=15;h++)
      g.drawOval(30+(h*35),70,16+h,16+h);
  }

  //draws "ovals", just as bad
  public void drawOnIt(Graphics g) {
    g.setColor(Color.black);
    for(int h=0;h<=15;h++)
      g.drawOval(30+(h*35),110,h+1,h+1);
    for(int h=0;h<=15;h++)
      g.drawOval(30+(h*35),150,16+h,16+h);
  }
}

---------- END SOURCE ----------

CUSTOMER WORKAROUND :
do all you rendering on screen (not really a work around).
(Review ID: 139638)
======================================================================




FULL PRODUCT VERSION :
Java 2 SDK Standard Edition v1.3

FULL OPERATING SYSTEM VERSION :
 customer  & Windows 98

ADDITIONAL OPERATING SYSTEMS :
Macintosh 8.6


A DESCRIPTION OF THE PROBLEM :
Hello,
   I have used Java since 1998, because it looks like C and
it is platform-independent.
   But I have one problem: filloval function does not work
correctly, especially small ones.

Please look at my homepage
http://homepage3.nifty.com/Aim/oval
On Macintosh system, all three rows of circles are seen the
same except their colors, but on Windows system the three
sets of
circles are seen differently. Some are not true circles, one
of them looks like a silhouette of a dome.

Please improve the quality of this.
Thank you,
T

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
1. use update(Graphics g)
2. offG.fillOval(25, 20, 3, 3);
3.

EXPECTED VERSUS ACTUAL BEHAVIOR :
true circles

ERROR MESSAGES/STACK TRACES THAT OCCUR :
Nothing

This bug can be reproduced always.

---------- BEGIN SOURCE ----------
/*
 * circles.java	01/06/2001
 */

import java.awt.*;


public class circles extends java.applet.Applet {
	Image 	offscr;
	Graphics 	offG;
    

    public void init() {
    }
    
    public void paint(Graphics g) {
    	Image pict;
    	
    	update(g);
		
    	g.setColor(Color.red);
		for(int i = 0; i < 20; i++){
			g.fillOval(i*25, 40, i, i);
		}
    }

    public void update(Graphics g) {
		offscr = createImage(500, 60);
		offG = offscr.getGraphics();
	
		offG.setColor(Color.white);		//make background
		offG.fillRect(0, 0, 500, 60);
		offG.setColor(Color.green);
		for(int i = 0; i < 20; i++){
			offG.fillOval(i*25, 20, i, i);
		}
		g.drawImage(offscr, 0, 0, this);
		offG.dispose();

    }
}




---------- END SOURCE ----------
(Review ID: 145281)
======================================================================

N/A

We currently use an algorithm that does the following to render the
circles and ovals:

	convert to Bezier approximation (less than 1% error)
	flatten to floating point polygons (less than 1 pixel error)
	round polygon vertices to integers (? error)
	fill integer polygon

I believe that most of the error and visible artifacts come from the 3rd
stage that rounds polygons to integers before scan converting them.  We
plan to implement subpixel precision scan conversion for FCS which I believe
will fix most of the problem.  If there is still a significant problem and/or
there is time for FCS, we will investigate direct scan conversion of the
Bezier segments, but that should not be necessary since there are plenty
of commercial rendering packages that get decent results for circles from
rendering flattened Bezier approximations.

  xxxxx@xxxxx   1998-07-27

I fixed the filler to maintain sub-pixel precision in filling the flattened
cubics and the circles are now much better, though not yet perfect.  I am
downgrading this bug to a P4.  If we have time to write a Bezier tracer
for FCS then we will, otherwise I think circles look good enough for the
first release.

  xxxxx@xxxxx   1998-08-13

  We are currently working on separate pipeline for drawing cubic and quad
 Bezier curves. We are using adaptive forward differencing. This approach
 according to our preliminary results could noticeably increase quality and
 speed up drawing of the Bezier curves.

  xxxxx@xxxxx   2005-2-18 14:21:49 GMT

This is no doubt related to 4179437.
I don't agree that the circles look good enough.
I use small circles in my applets and with JDK
1.2 RC1 they come out looking like diamonds when
drawn into an offscreen buffer.  The legend of my
map doesn't use an offscreen buffer and the shape
of the markers there is quite different.

The small circles look particularly ugly with a radius of 6 (JDK 1.2 RC1)

Circles are still unusably bad for my 
chemistry viewer when atom sizes get small.

If you want to talk directly to the underlying
Graphics2D object in 1.2, using RenderingHints 
can help make the filled circle output more
palatable:
 Graphics2D g2 = (Graphics2D) g;
 g2.setRenderingHint(RenderingHints.KEY_ANTIALIASING,
RenderingHints.VALUE_ANTIALIAS_ON);
 g2.setRenderingHint(RenderingHints.KEY_RENDERING,
RenderingHints.VALUE_RENDER_QUALITY);

Sun circles are of terrible quality (JDK 1.2.2)
drawOval is just as badly afflicted as fillOval.
fillOval(a,b,c,d) followed by fillOval(a,b,c,d)
to my amazement produces visible gaps between the two circles!

The fact that the quality of circle painting degraded from JDK 1.1 to JDK 1.2 
is putting java in a poor light in our company.  Sun, please address this
problem.
This is not "good enough" for our quality assurance team.  Please
help us make
a good Java product by fixing this problem in the next JDK 1.2 update release.

Happy birthday 4151279!

Three long years of 'good enough' circles.

I have circles up now that are nowhere near "good enough". I
have a "circle" that is 17 pixels across and has two
sections that are 8 pixels long and straight. This is
pathetic! (yes, i draw off screen).

This is not a circle:

     xxxxxxxx
    x        x
   x          x
  x            x
 x              x
 x              x
 x               x
 x               x
 x               x
 x               x
 x              x
 x              x
  x            x
   x          x
    x        x
     xxx   xx
        xxx
(if you are not using a monotype font, this will not look
right, you should be able to copy and paste or change your
browser settings).

See if the html makes it
<pre>
     xxxxxxxx
    x        x
   x          x
  x            x
 x              x
 x              x
 x               x
 x               x
 x               x
 x               x
 x              x
 x              x
  x            x
   x          x
    x        x
     xxx   xx
        xxx
</pre>

Between 1.4.0.beta2 and 1.4.0.beta3 the circles got better,
on Linux, at least.  And they still look good in 1.4.0
final.  It's just a shame that the enormous number of broken
runtimes out there mean that my code will need to continue
to be bloated with workarounds for this issue.

This should have been fixed long ago. I should be able to 
draw a perfectly round circle in a panel or in an 
offscreen image which gets drawn in that panel. As the 
following code demonstrates, the offscreen image contains 
things that aren't quite circles:

import java.awt.*;
import java.awt.Image;
import java.applet.*;

public class sample extends Applet { 
    myPanel p1;
    Image img;
    Graphics off;
    myPanel2 p2;

    public void init() {
        img = createImage(200, 200);
        off = img.getGraphics();
        p1 = new myPanel(img);
        p1.setSize(200, 200);
        p2 = new myPanel2();
        p2.setSize(200, 200);

        this.setLayout( new GridLayout(0,2) );
        this.add(p1);
        this.add(p2);
    }
}
  
class myPanel extends Panel {
    Image img;
    Graphics off;
    
    public myPanel() {
        super();
        this.init();
    }
    
    public myPanel(Image i) {
        img = i;
        this.init();
    }
    
    public void init() {
        off = img.getGraphics();
        off.setColor(Color.black);
        off.fillRect(0, 0, 200, 200);
        off.setColor(Color.red);
        off.drawOval(100, 100, 10, 10);
        off.drawOval(70, 70, 20, 20);
        off.drawOval(20, 20, 50, 50);
    }
    
    public void paint(Graphics g) {
        if (img != null) {
            g.drawImage(img, 0, 0, img.getWidth(this), 
img.getHeight(this), this);
        }
    }
}

class myPanel2 extends Panel {
    public void paint(Graphics g) {
        
        g.setColor(Color.white);
        g.fillRect(0, 0, 200, 200);
        g.setColor(Color.blue);
        g.drawOval(100, 100, 10, 10);
        g.drawOval(70, 70, 20, 20);
        g.drawOval(20, 20, 50, 50);
    }
}

still no new evaluation,argh!

Sun considers this bug report to be the 'master' bug report 
for rasterizer problems, but so far has failed to update 
this bug report to reflect this fact (see the comments in 
bug 4092170 for a discussion).

So here goes: drawArc, fillArc, drawOval, fillOval, 
drawRoundRect, fillRoundRect, drawPolygon, fillPolygon when 
drawn to an offscreen buffer will yield different 
areas/outlines than when drawn directly to an onscreen 
Graphics object.

Results: ovals and round rects with square corners, etc.

If you are doing any type of double buffering and the 
output looks different then without double buffering, this 
is probably your bug.

Here is an example that yields SQUARE corners in a drawOval
() and drawRoundRect():
--------------------------------------------------
import java.awt.*;

public class drawrectbug extends Frame {
    public static void main(String[] args) {
        new drawrectbug();
        }
    public drawrectbug() {
        super("drawRoundRect/drawOval bugs");
        resize(400,300);
        show();
        }
    public boolean handleEvent( Event evt ) {
        if (evt.id==Event.WINDOW_DESTROY) {
            System.exit(0);
            }
        return super.handleEvent(evt);
        }
    public void paint(Graphics g) {
        Image i = createImage(size().width, size().height);
        drawAll( i.getGraphics(), 50 );
        g.drawImage( i, 0, 0, null );
        drawAll( g, 100 );
        g.setColor( Color.black );
        g.drawString( "buffered:", 10, 60 );
        g.drawString( "direct:", 10, 110 );
        }
    private void drawAll( Graphics g, int y ) {
        g.setColor( Color.yellow );
        g.fillRoundRect( 80, y, 30, 20, 6, 6 );
        g.fillOval( 150, y, 6, 6 );
        g.setColor( Color.black );
        g.drawRoundRect( 80, y, 30, 20, 6, 6 );
        g.drawOval( 150, y, 6, 6 );
        }
    }
--------------------------------------------------

"g.drawOval(0,0,6,6)" under Java 1.0 or Java 1.1:

     00112233445566

  0      XXXXXX
  1    XX      XX
  2  XX          XX
  3  XX          XX
  4  XX          XX
  5    XX      XX
  6      XXXXXX

"g.drawOval(0,0,6,6)" under Java 1.3 or Java 1.4:

     00112233445566

  0  XXXXXXXXXXXX
  1  XX        XX
  2  XX          XX
  3  XX          XX
  4  XX        XX
  5  XXXX      XX
  6      XXXXXX

Not pleasing?  Or a bug that should be fixed.  Write to Sun 
and let them know what you think.

Better yet, use all three of your bug votes on the left
sidebar for this bug to bump it up the queue! The number is
4151279.

4 years since the last evaluation, who should we write to at
sun?

Four years is ridiculous. Sun, fix this damn bug!

"who should we write to at sun?" 
 
Perhaps java2d-comments@java.sun.com ? 

How many years will we have to wait?

Update: I turned off the outline to have a closer look.  The 
offscreen ellipse filling does look better than the outline.  It 
doesn't look as good as the onscreen version, but it's 
probably adequate.

So if you can bring the offscreen outline "in-line" with the 
offscreen filling, then Ellipse2D will be adequate for my needs.

I run into this problem when trying to render filled and
outlined ellipses into a back buffer.  (On Win2K & WInXP.)

The problems are:

1. Both outlined and filled ellipse looked bad (angular,
    asymmetric) when drawn to offscreen buffer.

2. Ellipse filling did not touch outline in some places;
    and in other places, filling bled through outline.

3. Neither the offscreen ellipse outline nor filling matched
    the onscreen version.

My test applet is below.

In my test, I tried applying a value-quality hint but
it doesn't help.

Using anti-alias is not an option (too fuzzy, etc.)

/* EllipseTest.java */

import java.awt.*;
import java.awt.geom.Ellipse2D;

/** Tests Graphics2D ellipse. */
public class EllipseTest extends java.applet.Applet {

    public void init() {
        setLayout(new java.awt.BorderLayout());
    }

    public void paint(Graphics g) {

        // on screen
        g.setColor(Color.BLUE);
        g.drawRect(5, 5, 90, 90);
        Graphics2D g2 = (Graphics2D) g;
        Shape s = new Ellipse2D.Double(5, 5, 90, 90);
        g2.setPaint(Color.RED);
        g2.fill(s);
        g2.setPaint(Color.BLACK);
        g2.draw(s);

        // off screen
        Image image = createImage(100, 100);
        Graphics gi = image.getGraphics();
        gi.setColor(Color.BLUE);
        gi.drawRect(5, 5, 90, 90);
        Graphics2D gi2 = (Graphics2D) gi;
        gi2.setPaint(Color.RED);
        gi2.fill(s);
        gi2.setPaint(Color.BLACK);
        gi2.draw(s);
        g2.drawImage(image, 100, 0, this);
    }
}

This bug is 5 years old, and it is still not corrected?
If it is so difficult to write this correction, you could at least
rename the object Ellipse2D to Potato2D, so you don't need 
to write correction at all   :-).

Just come across this problem and can't believe that it 
has now passed it's 5th birthday!  It seems to have 
been fixed on Linux but on Windows those same small 
circles are looking pretty deformed.

Anyone know a good work-around which isn't too 
compute intensive?

I'm drawing Ovals using a polygon and simply 
computing the points.  On the screen the ovals are 
nice and smooth, but when sent to the printer their 
shape is slightly distored.  If few points are used, the 
printed oval becomes slightly boxey.  But if a large 
number of points are used, the printout will show very 
jagged edges like a piece of serrated metal!

    double radians = 0.0;
    for (int i=0; i<numPoints; i++) {
      xPoints[i] =  width  * Math.cos(radians);
      yPoints[i] =  height * Math.sin(radians);
      radians += (2.0 * Math.PI) / numPoints;
    }

Five and a half years of waiting now. I'll have to teach
myself Java again to remember why I wanted this fixed so
badly. Should we throw a party in June when this bug turns six?

Whenever this bug will be fixed?

I don't understand the need to go through a Bezier and 
then approximate points, when drawing ovals and 
circles is a known algorithm which can be 
implemented cleanly using only integer arithmetic.
I understand that using Beziers may improve the 
performance for large circles where the difference 
isnearly invisible, but for small circles, an integer-
based incremental algorithm already exists since long 
and there are many historic books that demonstrate 
how to do this cleanly and fast..

Bibliography of methods used to draw circles and arcs incrementally (hope this helps):

[BRE77] Bresenham, J.E.  "A Linear Algorithm for Incremental Digital Display of Circular Arcs", CACM, 20(2):100-106, February 1977.

[COH69] Cohen, D. "On Linear Difference Curves", Dept. Eng. Appl. Math., Harvard Univ. 1969.  Also in "Computer Display Review, see [KEY66].

[PIT67] Pitteway, M.L.V.: "Algorithm for Drawing Ellipses or Hyperbolae with a Digital Plotter", Comput. J., 10(3):282-289, November 1967.

[KEY66] Keydata Corporation, "Computer Display Review", KeyData Corp., Watertown, MA.  This review was published annually beginning in 1966, and consisted of reviews of display hardware and selected articles on graphical techniques.  Individual articles were retained for several years.  The review is now published periodically by GML Associates, 594 Marrett Rd., Lexington, MA.  Articles on graphical techniques are contained in volume 4.

As you see this has been studied since long, and lots of articles and books have been published on computer graphics.   Drawing circles correctly should no more be a problem, and there are LOTS of various implementations on as many platforms.

The likely reason for using Bezier curves to draw circles is to keep down the number of special cases (and thus code bloat). Remember that if the transform matrix is not just a scale and shift (i.e. includes a shear) component, then the result of drawing a 'circle' is rather different. So the Bezier approach is needed to cope with general transforms. Yes, a special case renderer could be used when the transform is simple, but that would be extra code which they understandably want to avoid if adequate quality can be achieved by the more general Bezier approach.

I never noticed this bug, since I am always using anti-aliasing in Java 1.4. Looks much better. I cannot find it "fuzzy" at all. Maybe that is due to my flatscreen.

However, I am not writing to tell you this. You can easily program around making your own circle routine. For circles with less than 5 pixels of radius, you can just as well use a sexagon.

Finally, I would urge Sun to fix this, for it is ridiculous. The kind of thing you are spreading if you want to make Java look bad.

Does anyone at Sun ever look at these outstanding bugs?   This bug makes graphical Java programs look very amateurish on Microsoft operating systems just when it really needs to look at its best; it is a very poor advertisement for Java.  I may be wrong but it would also seem to be a very straightforward one to fix being just a simple algorithm.

It is not just a problem with small circles although it is more obvious with them and the polygon work-around is too inefficient for the bigger ones.  If there was an efficient pixel painting method I would write a Bresenham algorithm myself, but there isn't.

Does anyone know of a more efficient work-around?

Should have mentioned that it all appears to work perfectly on Linux and Solaris operating systems.
So why is it such a problem to get it right on Windows?
We have now been waiting 6 years since that evaluation.

One last thing, I'll try a bit of extortion: if this bug doesn't get fixed in the next release I am porting my app to C#. ;-)

We are actively working on a fix of this bug. At the moment  we are considering two potential solution:
- Improving our flattening algorithm by adding intelligent rounding 
- Creating special casing for curves and ovals using incremental algorithms

Six years and seven months now.

Good on you guys for getting this into mustang. Just make sure it

So will you ever fix the bug that cuts a text at the first single-quote?

... just make sure it works fast with anti aliasing, since that will be the largest use case in the future.

Dear Mgrev,
Could you please provide us more info about bug which cuts a text at the first single-quote. Does it have bug id or you just have a test case ? If the problem is not filed in our database please report about it or send us example of code showing incorrect behavior. 

I think he (mgrev) is referring to the fact that comments are often cut off right HERE, the Bugs Database interface itself! ^^"

Just out of interest - are we expecting the improved routines to appear in Mustang btw?

Yes, we are trying to get the fix into Mustang.

cool~  \(^0^)/
looking forward to that

We do a lot of PLAF/skin work with small radius circles, and we have three issues, which we are still seeing in 1.4.2_07 and 1.5:
1. small circles look awful (radius < 10)
2. circular corners in round rects look different from circles
3. circular corners in round rects look different depending on which corner they are placed

It's really, really bad. Frustrating. Disappointing. The circles look like crap. *** PLEASE FIX IN MUSTANG!!!  DON'T MAKE US SUFFER ANY LONGER!!!  ***

looks like even the JSR166x maintenance update has made itself into Mustang now; being rather courious - what are the actual problems that the "separate pipeline" is facing?

Seven years, two months and counting.

It took 7 years and 3 months to fix this bug! And this was one of the most popular bugs. Does this mean that the time to fix some of the less popular bugs will be measured in decades?

The output looks better in Mustang b55 but it is not perfect. Circles drawn in offscreen buffers look more like rounded ovals. This could still use some improvement.