Bug #62972 for Prima: ellipse centre when even diameters

Sat Nov 13 19:33:52 2010 user42 [...] zip.com.au - Ticket created

Subject:	ellipse centre when even diameters
Date:	Sun, 14 Nov 2010 11:33:08 +1100
To:	bug-Prima [...] rt.cpan.org
From:	Kevin Ryde <user42 [...] zip.com.au>

For Prima::Drawable ellipse(), if the DIAMETER_X value is even, is it specified whether you should round the X coordinate up or down when giving the centre? Eg. a 4x4 circle, 0123 ** * * * * ** The X would be 1 would it, or 2? The docs might have a couple of words of guidance, presuming it is (or is meant to be) consistent across x11 vs msdos etc backends. Nosing around the code I saw a bit of x - (dX+1)/2 + 1 for XDrawArc, but wasn't sure if it and the hairy calculate_ellipse_divergence() expressed a documented feature. :-)

Sat Nov 13 20:16:47 2010 KARASIK [...] cpan.org - Correspondence added

A rather painful issue :) The problem with arcs on X11 is that different servers draw them differently, hence an attempt to calculate guts.ellipseDivergence so that pixel precision is at least somehow kept (XDrawArc etc is silent on that issue as well). Indeed, section "Arcs" should be updated in gp-problems.pod with documentation how at least modern X servers do that. The idea is, of course, that both X and Win32 code produce identical results; on Win32 point "X" is on 1. I'll try that on X later, but I'd expect the same too.

Sat Nov 13 20:16:48 2010 The RT System itself - Status changed from 'new' to 'open'

Sat Nov 27 19:30:11 2010 user42 [...] zip.com.au - Correspondence added

Subject:	Re: [rt.cpan.org #62972] ellipse centre when even diameters
Date:	Sun, 28 Nov 2010 11:29:48 +1100
To:	bug-Prima [...] rt.cpan.org
From:	Kevin Ryde <user42 [...] zip.com.au>

"KARASIK via RT" <bug-Prima@rt.cpan.org> writes: Show quoted text

> > A rather painful issue :)

Yes. Show quoted text

> The problem with arcs on X11 is that different servers draw them > differently,

Hmm. Show quoted text

> XDrawArc etc is silent on that issue as well

The protocol manual under PolyArc has a bit about "implementation dependent" if width!=height, but you'd like to hope that it gets close to the specified middle of the pixels, line centred on the arc, etc, per the spec ...

Sun Nov 28 02:28:15 2010 KARASIK [...] cpan.org - Correspondence added

Seeing this and two other bugs, I think that X11 ellipse/fill_ellipse/calculate_ellipse_divergence algorithms should be revisited. I'm not 100% happy with calculate_ellipse_divergence either, but it was added when back then I've seen different results on XFree86 and Irix. I'll dig into the issue when I get time, assuming that Irix is there no more, and Xorg is the de-facto standard, so possibly the whole thing could be done in a much more simpler way, removing the need for calculate_ellipse_divergence totally. But then again, I need to get results consistent with Win32, and if you can give me a hand, that would be greatly appreciated. Thanks!

Mon Nov 29 18:19:01 2010 user42 [...] zip.com.au - Correspondence added

Subject:	Re: [rt.cpan.org #62972] ellipse centre when even diameters
Date:	Tue, 30 Nov 2010 10:18:43 +1100
To:	bug-Prima [...] rt.cpan.org
From:	Kevin Ryde <user42 [...] zip.com.au>

"KARASIK via RT" <bug-Prima@rt.cpan.org> writes: Show quoted text

> > XFree86 and Irix

There used to be a reference implementation too I think, if divergence from that could be taken as a bug, at least apart from linewidth==0 unfilled, which is supposed to be native hardware or something. Show quoted text

> removing the need for calculate_ellipse_divergence

Could do, or stick in some tests to later notice if assumptions are not met in a really bad way. For some of my Image::Base tinkering I've merely asked an ellipse to draw 1 or more pixels on each outer edge of the requested box, and nothing outside of it. Might be able to go a touch tighter than that, but maybe not very much.

Thu Jan 06 04:57:17 2011 KARASIK [...] cpan.org - Correspondence added

added reference to this text in gp-problems.pod

Thu Jan 06 04:57:17 2011 KARASIK [...] cpan.org - Status changed from 'open' to 'resolved'