[LWW 6] filled ellipses don't coincide with their boundaries
Unable to parse email body. Email id is 10916
Unable to parse email body. Email id is 10916
Unable to parse email body. Email id is 10917
A question (or two): Would Nick's issue be considered a bug or simply what happens with rounding (since pixel's are integral)? Z -----Original Message----- From: owner-lisp-hug@lispworks.com [mailto:owner-lisp-hug@lispworks.com] On Behalf Of Martin Simmons Sent: Wednesday, April 06, 2011 9:59 AM To: lisp-hug@lispworks.com Subject: Re: [LWW 6] filled ellipses don't coincide with their boundaries >>>>> On Tue, 5 Apr 2011 15:41:38 +0100 (BST), Nick Levine said: > > (gp:draw-ellipse x y rx ry) draws an ellipse of total width (1+ (* 2 > rx)) pixels, centred symmetrically about the given co-ordinates. > > (gp:draw-ellipse x y rx ry :filled t) draws an ellipse of total width > (* 2 rx) pixels, centred half a pixel above and to the left of the > given co-ordinates. > > The solutions appears to be to offset the filled ellipse half a pixel > down and to the right, and to add 1/2 to its radii. > > (defun filled-ellipse-ideal () > (let ((pane (capi:contain (make-instance 'capi:output-pane))) > (centre 100) > (x-radius 30) > (y-radius 50)) > (gp:draw-ellipse pane > (+ centre 1/2) (+ centre 1/2) > (+ x-radius 1/2) (+ y-radius 1/2) > :filled t :foreground :yellow) > (gp:draw-ellipse pane centre centre x-radius y-radius))) > > So now I know. Yes, that is a hack to get around it. We will have this working much better for the next release. Before anyone asks, we're not publishing a release date or feature list for LispWorks 6.1 yet.
On Apr 6, 2011, at 4:25 PM, Erik Ronström wrote: > Becuase of the anti-aliasing, the rendering engine is clearly aware of how to draw on a "subpixel" level. So IMHO it should be possible to use "subpixels" as starting points for a line as well! FWIW, this is a known issue and the LispWorks guys have told me that float arguments to gp:draw-polygon, etc. will be a feature in the next release. Until then I have been using the workaround that Erik suggests - supersampling. warmest regards, Ralph Raffael Cavallaro raffaelcavallaro@me.com
FWIW, this is a known issue and the LispWorks guys have told me that float arguments to gp:draw-polygon, etc. will be a feature in the next release.
On Apr 6, 2011, at 4:25 PM, Erik Ronström wrote:
> Becuase of the anti-aliasing, the rendering engine is clearly aware of how to draw on a "subpixel" level. So IMHO it should be possible to use "subpixels" as starting points for a line as well!
Until then I have been using the workaround that Erik suggests - supersampling.
warmest regards,
Ralph
Raffael Cavallaro
raffaelcavallaro@me.com
>>>>> On Thu, 7 Apr 2011 10:14:11 +0100, Yury Davidouski said: > > Will the floating point use be a tax on performance? It isn't clear, because the underlying drawing operations on the Mac use floating point anyway, so we are currently converting from real to integer and back to float. We will still support the existing integer-based drawing as an option, so the performance of that will remain the same. -- Martin Simmons LispWorks Ltd http://www.lispworks.com/ > > On 6 April 2011 22:09, Raffael Cavallaro <raffaelcavallaro@mac.com> wrote: > > > > > > > On Apr 6, 2011, at 4:25 PM, Erik Ronström wrote: > > > > > Becuase of the anti-aliasing, the rendering engine is clearly aware of > > how to draw on a "subpixel" level. So IMHO it should be possible to use > > "subpixels" as starting points for a line as well! > > > > FWIW, this is a known issue and the LispWorks guys have told me that float > > arguments to gp:draw-polygon, etc. will be a feature in the next release. > > > > Until then I have been using the workaround that Erik suggests - > > supersampling. > > > > warmest regards, > > > > Ralph > > > > > > Raffael Cavallaro > > raffaelcavallaro@me.com > > > > > > > > > > > > >
> > Well, if you draw a non-horizontal non-vertical line, you get anti- > > aliasing, which means that most of the pixels drawn are semi- > > transparent. So if I draw from (0, 0) to (1, 100), I get a line > > that is mostly "between" the pixel grid. >> > > Fwiw, I don't see that at all. > That is because the current drawing code on Windows doesn't do anti-aliasing, whereas it does on the Mac. Hmmm ... I would have expected both to be the same for consistent results. And, fwiw, a standard draw line function ought be NOT anti-aliased, IMHO. Then, users have a choice to roll their own if they want ... *and* different functions can be provided for anti-aliased line drawing too. So, what is the plan for the future release you mentioned? Z
On Thu, Apr 7, 2011 at 5:55 AM, Nick Levine <ndl@ravenbrook.com> wrote: > Well, if you draw a non-horizontal non-vertical line, you get anti- > aliasing, which means that most of the pixels drawn are semi- > transparent. So if I draw from (0, 0) to (1, 100), I get a line > that is mostly "between" the pixel grid. > > Fwiw, I don't see that at all. It's the behavior on OS X, but not on Windows. -- Joshua Taylor, http://www.cs.rpi.edu/~tayloj/
Unable to parse email body. Email id is 10934
Thanks for the info! Z -----Original Message----- From: owner-lisp-hug@lispworks.com [mailto:owner-lisp-hug@lispworks.com] On Behalf Of Martin Simmons Sent: Friday, April 08, 2011 7:38 AM To: lisp-hug@lispworks.com Subject: Re: [LWW 6] filled ellipses don't coincide with their boundaries >>>>> On Thu, 7 Apr 2011 06:21:41 -0700, Syed Zaeem Hosain (Syed Hosain@aeris net) said: > > > > Well, if you draw a non-horizontal non-vertical line, you get anti- > > > aliasing, which means that most of the pixels drawn are semi- > > > transparent. So if I draw from (0, 0) to (1, 100), I get a line > > > that is mostly "between" the pixel grid. > >> > > > Fwiw, I don't see that at all. > > > That is because the current drawing code on Windows doesn't do > > anti-aliasing, whereas it does on the Mac. > > Hmmm ... I would have expected both to be the same for consistent results.. We didn't do that because it made it look like a Mac OS 9 application :-) > And, fwiw, a standard draw line function ought be NOT anti-aliased, > IMHO. Then, users have a choice to roll their own if they want ... > *and* different functions can be provided for anti-aliased line drawing too. > > So, what is the plan for the future release you mentioned? capi:output-pane etc will have two modes, "compatible" and "quality", controlled by an initarg. The compatible mode will be the same as now. The quality mode will support alpha blending, anti-aliasing (which can be disabled), subpixel coordinates and arbitrary transforms for all drawing operations (currently, ellipses and text are not transformed). We are leaning towards making "quality" be the default because all of the supported platforms are moving to that style of drawing. -- Martin Simmons LispWorks Ltd http://www.lispworks.com/