Skip Menu |

This queue is for tickets about the Prima CPAN distribution.

Report information
The Basics
Id: 63392
Status: rejected
Priority: 0/
Queue: Prima

People
Owner: Nobody in particular
Requestors: user42 [...] zip.com.au
Cc:
AdminCc:

Bug Information
Severity: (no value)
Broken in: (no value)
Fixed in: (no value)



Subject: fill_ellipse() 5x3 extra pixel
Date: Sun, 28 Nov 2010 11:57:02 +1100
To: bug-Prima [...] rt.cpan.org
From: Kevin Ryde <user42 [...] zip.com.au>
In recent debian Prima 1.28 the program bar.pl draws a 5x3 filled ellipse and gets "q c #000000", "w c #FFFFFF", "qwwwq", "wwwww", "qwwww"}; where I expected that the bottom right pixel would be black "q" "qwwwq"}; which would be symmetric. Nosing around the code I suspect the width,height passed to XFillArc is 1 too big. Or at least it seems to be the XFillArc which draws the extraneous corner pixel. I like the way an extra XDrawArc does the outermost pixels which XFillArc doesn't, per the drawing model and specs, but just perhaps the XFillArc is too big.
use strict; use warnings; use Prima; use Prima::Const; my $d = Prima::Image->create (width => 5, height => 3); $d->begin_paint; $d->color (cl::Black); $d->bar (0,0, 4,0); $d->color (cl::White); $d->fill_ellipse (2,1, 5,3); $d->end_paint; $d->save('/tmp/foo.xpm') or die "Error saving:$@\n"; system "cat /tmp/foo.xpm"; exit 0;
Subject: Re: [rt.cpan.org #63392] fill_ellipse() 5x3 extra pixel
Date: Wed, 01 Dec 2010 07:13:40 +1100
To: bug-Prima [...] rt.cpan.org
From: Kevin Ryde <user42 [...] zip.com.au>
Incidentally, other possibility for a filled ellipse might be to set the GC line width to half the radius and XDrawArc a correspondingly smaller box. If the line width is rounded up to the next odd integer then it can cover the extra 1/2 pixel that an XFillArc doesn't do. I wonder if that would help GCxor mode where two drawing requests would otherwise step on each other's toes (the cases the FILL_ANTIDEFECT_REPAIRABLE doesn't cover, if I understand that). In some of my own code I've still got the FillArc+PolyArc combination. -- The sigfile political applications of mathematics series: "The rate of increase of inflation is decreasing" -- Nixon in 1972 appealing to a third derivative in his campaign for re-election
Втр Ноя 30 15:13:54 2010, user42@zip.com.au писал: Show quoted text
> Incidentally, other possibility for a filled ellipse might be to set the > GC line width to half the radius and XDrawArc a correspondingly smaller > box. > If the line width is rounded up to the next odd integer then it > can cover the extra 1/2 pixel that an XFillArc doesn't do. > > I wonder if that would help GCxor mode where two drawing requests would > otherwise step on each other's toes (the cases the > FILL_ANTIDEFECT_REPAIRABLE doesn't cover, if I understand that).
Exactly. XFillArc doesn't do a very good job, so the code tries to help it with XDrawArc. But in xor mode we can't do much. Show quoted text
> In some of my own code I've still got the FillArc+PolyArc combination.
Do you have a good algorithm with this combination that can be used generally here? Does that also include the half-width GC line, you mentioned above? A patch would be great then.
Subject: Re: [rt.cpan.org #63392] fill_ellipse() 5x3 extra pixel
Date: Wed, 01 Dec 2010 09:48:31 +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
>
>> In some of my own code I've still got the .
> > Do you have a good algorithm with this combination that can be used > generally here?
Oh, the FillArc+DrawArc I only arrived at the same as you presumably did. Show quoted text
> Does that also include the half-width GC line, you > mentioned above?
Concept code below for the half-width idea. Apologies for it being gtk based. Gtk is bloat on top of xlib, draw_arc() is XDrawArc. To do a 20x10 ellipse it draws line width 5 with the ellipse line at y=2. This means the line extends up by 2.5 from the centre of the y=2 pixel, thus taking in the whole of the y=0 pixel. Not certain if I've got the rounding right for all different odd/even sizes (or modulo 4 or what :-). Slightly ironically I don't think this works for 5x3, because the 3 ends up drawing h=0, and the same missing end pixel as the other 5x1 ticket! At any rate, this may be an idea for bigger ones. height==3 or width==3 could be made a special case with three lines or a little polygon or something. The middle of the 3 rows is full width, and not too hard to take a sqrt() for how many pixels desired on the two top and bottom rows. use 5.008; use strict; use warnings; use Gtk2 '-init'; use List::Util 'min'; my $width = 20; my $height = 10; my $rootwin = Gtk2::Gdk->get_default_root_window; my $pixmap = Gtk2::Gdk::Pixmap->new ($rootwin, $width, $height, -1); my $black = Gtk2::Gdk::Color->new(0,0,0,0); my $gc = Gtk2::Gdk::GC->new ($rootwin, { line_width => 1, foreground => $black, }); $pixmap->draw_rectangle ($gc, 1, # fill 0, 0, $width,$height); my $line_width = min ($height/2, $width/2); $line_width = int($line_width + .5); # up to integer $line_width += !($line_width&1); # up to next odd integer print "line_width=$line_width\n"; my $white = Gtk2::Gdk::Color->new(0xFFFF,0xFFFF,0xFFFF,0xFFFFFF); $gc = Gtk2::Gdk::GC->new ($rootwin, { line_width => $line_width, function => 'xor', foreground => $white, }); my $shrink = int($line_width/2); # round down print "shrink=$shrink\n"; my $x = 0 + $shrink; my $y = 0 + $shrink; my $w = $width-1 - 2*$shrink; my $h = $height-1 - 2*$shrink; print "x=$x, y=$y, w=$w, h=$h\n"; $pixmap->draw_arc ($gc, 0, # unfilled $x,$y, $w,$h, 0, 360*64); print "\n"; my $pixbuf = Gtk2::Gdk::Pixbuf->get_from_drawable ($pixmap, undef, 0,0, 0,0, $width,$height); $pixbuf->save ('/tmp/x.png', 'png'); system ("convert -monochrome /tmp/x.png /tmp/x.xpm && cat /tmp/x.xpm"); exit 0;
I see, thanks! I doubt though that I'll have time soon to experiment with this. Too bad that it doesn't work for 5x3, but well, if it doesn't work, then we can't use it really, sorry. Or rather, I don't see why one flawed algorithm should be replaced with another.
Subject: Re: [rt.cpan.org #63392] fill_ellipse() 5x3 extra pixel
Date: Thu, 02 Dec 2010 06:17:10 +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
> > one flawed algorithm should be replaced with another.
Actually I realize I got it badly wrong. An ellipse drawn with a wide line doesn't make an ellipse shape, the outer edge is a bit fatter than an ellipse. So alas no good, except for a circle (width==height).
So, should we abandon all hope and close the ticket? :)
Subject: Re: [rt.cpan.org #63392] fill_ellipse() 5x3 extra pixel
Date: Tue, 07 Dec 2010 09:00:21 +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
> > So, should we abandon all hope and close the ticket? :)
:-). I would fix the XFillArc size 1 too big, stay with the XPolyArc outer rim "repair" bit, send width,height <= 2 to the rectangle code, and rate that close enough for the moment. In the future perhaps attack the non "REPAIRABLE" cases like xor by drawing onto some sort of temporary bitmap or pixmap to select desired pixels. -- The sigfile finance for the layman series: In a mining company's annual report, the more detail about mineralization and geology, the less chance of making money from it.
Show quoted text
> :-). I would fix the XFillArc size 1 too big, stay with the XPolyArc > outer rim "repair" bit,
I tried to experiment adding -1 to arguments to XFillArc (I'd urge you to try too), and interestingly enough 5x3 fill_ellipse _still_ has the extra pixel, just in another location. So I'm unsure if that helps, and am reluctant to change the logic based just on that. Also, the extra pixel, technically speaking, is not necessary an "extra" - it doesn't get out of the 5x3 box, and I'd personally accept it as a roundoff error, rather than a bug. It's not symmetric, I agree, but the "size 1 too big" fix doesn't help that either. So I'd leave thing as is unless there exists a good algorithm that solves the problem in a more global way. Show quoted text
> send width,height <= 2 to the rectangle code,
Yes, this one's agreed, I'll fix that. Show quoted text
> In the future perhaps attack the non "REPAIRABLE" cases like xor by > drawing onto some sort of temporary bitmap or pixmap to select desired > pixels.
That's of course possible, but I'm not going to do that in foreseeable future, too much hassle, sorry :) If you feel that you can to contribute, yes, by all means, please do, I'll accept patches with thanks. Otherwise, I'll just mark that in TODO somewhere. But thanks for the pedantic insight, I really appreciate that, just don't have the energy :)
Subject: Re: [rt.cpan.org #63392] fill_ellipse() 5x3 extra pixel
Date: Thu, 09 Dec 2010 08:27:24 +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
> > I tried to experiment adding -1 to arguments to XFillArc (I'd urge you > to try too),
Yep, I did. Show quoted text
> and interestingly enough 5x3 fill_ellipse _still_ has the > extra pixel, just in another location.
Err, it worked for me. If you mean the XFillArc alone gives a shape like +-----+ | * | |**** | | | +-----+ then I believe that's correct. I think it's in a sense missing pixels rather than drawing an extra, it's like +-----+ | * | |*****| | * | +-----+ but the rightmost and bottommost are not drawn due to the X rule about pixel centre on the bounding line is drawn only if on the left or upper sides of the shape. The XDrawArc "repair" around the outside covers those pixels. Show quoted text
> just mark that in TODO somewhere.
Yes, put it somewhere, it's the sort of added-value or smoothing out the nasty bits I think you'd look for in a cross platform toolkit.