Re: NSBezierPath + thin lines + antialias = :(
This may explain why my purchase of a program that outputs code for vector images resulted in disappointment. I don't have a retina display, so I bought a program to make graphics code that would look good at any size/resolution in my Mac app, even for displays I have no experience with. What I got was images that look *terrible* even at the designed size when the output code uses beziers. So far the only solution is to export the images as PNGs, which I could've done without spending a hundred bucks on other software. -- Charles On February 9, 2015 at 16:39:21, Jens Alfke (j...@mooseyard.com) wrote: On Feb 9, 2015, at 1:18 PM, Jerry Krinock je...@ieee.org wrote: Is there a way to draw thin lines in code, and get good results on non-Retina displays? What should I read to learn how? (The listserv strips image attachments, so we can’t see the pictures.) The typical problem drawing thin horizontal/vertical lines is that the line gets split between pixels, so you get a 2-pixel-wide gray line when what you wanted was a 1-pixel black line. The reason this happens is that when you use integer coordinates the line is centered on a pixel boundary, so the left half of the line is in one pixel and the right half is in another. Instead, to draw a one-point line, the coordinate on the axis perpendicular to the line should end in .5. For example, to draw a vertical line at x=100, the x coord of the line should be 100.5. That way you completely fill the pixels at x=100 and no others. (This only applies to odd widths, though. For a 2pt line, you do want whole-number coords.) (It gets more complicated if you’ve transformed the coordinate system, because the above considerations apply to device coords, so you’d have to transform your drawing coords into device coords, do the rounding/offset, and then back. This happens with scaling, but can also occur if you’ve scrolled/offset your coordinates by non-integral amounts.) —Jens ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/cejwork%40gmail.com This email sent to cejw...@gmail.com ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: NSBezierPath + thin lines + antialias = :(
On 2015 Feb 10, at 05:36, Charles Jenkins cejw...@gmail.com wrote: This may explain why my purchase of a program that outputs code for vector images resulted in disappointment. Counterintuitive at first, but, yes :)) I’ve always wondered why, when you’re dragging a window around a non-Retina screen, the anti-aliasing doesn’t show a “comb filter” kind of effect, with different lines getting fuzzy and sharp as they are dragged on and off their pixels. Looking at this closely today, I think the explanation may be that (1) Although you need to look carefully, Apple has constrained dragging windows to “snap to the grid of backing pixels. You cannot move a window by one half pixel. (2) A window’s intrinsic scrollers, title bars, etc. are also on a 1-pixel grid. (3) Any control or view that you place into Interface Builder must be on a 1-pixel grid. I just tried entering a decimal fraction, 139.5, and after I ended editing, it was rounded down to 139. So I think that’s why this has always been a mystery to me: Apple has layered on several contrivances to hide the ugly truth, and it works until you start adding your own views that have fractional pixel features. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: NSBezierPath + thin lines + antialias = :(
On Feb 10, 2015, at 11:23 , Jerry Krinock je...@ieee.org wrote: I’ve always wondered why, when you’re dragging a window around a non-Retina screen, the anti-aliasing doesn’t show a “comb filter” kind of effect, with different lines getting fuzzy and sharp as they are dragged on and off their pixels. Looking at this closely today, I think the explanation may be that (1) Although you need to look carefully, Apple has constrained dragging windows to “snap to the grid of backing pixels. You cannot move a window by one half pixel. (2) A window’s intrinsic scrollers, title bars, etc. are also on a 1-pixel grid. (3) Any control or view that you place into Interface Builder must be on a 1-pixel grid. I just tried entering a decimal fraction, 139.5, and after I ended editing, it was rounded down to 139. Case #3 is actually points, not pixels. Cases #1 and #2 may be points, too, but I don’t know. Then there’s #1A and #3A — meaning: positioning those elements programmatically. Even though you can’t place a button off the 1-point grid in IB, you might be able to do it programmatically. Or not. Also, be careful about conceptualizing backing “pixels”. On an iPhone 6+, the backing store is 2x, but the hardware is 3x. (Let’s hope I got that the right way round.) Something similar is true of the Retina iMac/MacBook, too, though it’s complicated by having multiple logical resolutions. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: NSBezierPath + thin lines + antialias = :(
On Feb 10, 2015, at 12:20, Quincey Morris quinceymor...@rivergatesoftware.com wrote: On Feb 10, 2015, at 11:23 , Jerry Krinock je...@ieee.org wrote: I’ve always wondered why, when you’re dragging a window around a non-Retina screen, the anti-aliasing doesn’t show a “comb filter” kind of effect, with different lines getting fuzzy and sharp as they are dragged on and off their pixels. Looking at this closely today, I think the explanation may be that (1) Although you need to look carefully, Apple has constrained dragging windows to “snap to the grid of backing pixels. You cannot move a window by one half pixel. (2) A window’s intrinsic scrollers, title bars, etc. are also on a 1-pixel grid. (3) Any control or view that you place into Interface Builder must be on a 1-pixel grid. I just tried entering a decimal fraction, 139.5, and after I ended editing, it was rounded down to 139. Case #3 is actually points, not pixels. Cases #1 and #2 may be points, too, but I don’t know. Then there’s #1A and #3A — meaning: positioning those elements programmatically. Even though you can’t place a button off the 1-point grid in IB, you might be able to do it programmatically. Or not. Also, be careful about conceptualizing backing “pixels”. On an iPhone 6+, the backing store is 2x, but the hardware is 3x. (Let’s hope I got that the right way round.) You got it backwards :) The app renders into a 3x backing store (i.e. each point is represented by a 3x3 grid of pixels). As far as the app is concerned, it is rendering to a 1242 x 2208 pixel (414x736 point) screen, but that is scaled down to the hardware resolution of 1080x1920 pixels. Something similar is true of the Retina iMac/MacBook, too, though it’s complicated by having multiple logical resolutions. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/clarkcox3%40gmail.com This email sent to clarkc...@gmail.com smime.p7s Description: S/MIME cryptographic signature ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: NSBezierPath + thin lines + antialias = :(
On Feb 10, 2015, at 15:34, Clark S. Cox III clarkc...@gmail.com wrote: On Feb 10, 2015, at 12:20, Quincey Morris quinceymor...@rivergatesoftware.com wrote: On Feb 10, 2015, at 11:23 , Jerry Krinock je...@ieee.org wrote: I’ve always wondered why, when you’re dragging a window around a non-Retina screen, the anti-aliasing doesn’t show a “comb filter” kind of effect, with different lines getting fuzzy and sharp as they are dragged on and off their pixels. Looking at this closely today, I think the explanation may be that (1) Although you need to look carefully, Apple has constrained dragging windows to “snap to the grid of backing pixels. You cannot move a window by one half pixel. (2) A window’s intrinsic scrollers, title bars, etc. are also on a 1-pixel grid. (3) Any control or view that you place into Interface Builder must be on a 1-pixel grid. I just tried entering a decimal fraction, 139.5, and after I ended editing, it was rounded down to 139. Case #3 is actually points, not pixels. Cases #1 and #2 may be points, too, but I don’t know. Then there’s #1A and #3A — meaning: positioning those elements programmatically. Even though you can’t place a button off the 1-point grid in IB, you might be able to do it programmatically. Or not. Also, be careful about conceptualizing backing “pixels”. On an iPhone 6+, the backing store is 2x, but the hardware is 3x. (Let’s hope I got that the right way round.) You got it backwards :) The app renders into a 3x backing store (i.e. each point is represented by a 3x3 grid of pixels). As far as the app is concerned, it is rendering to a 1242 x 2208 pixel (414x736 point) screen, but that is scaled down to the hardware resolution of 1080x1920 pixels. A good visualization of this: http://www.paintcodeapp.com/news/ultimate-guide-to-iphone-resolutions http://www.paintcodeapp.com/news/ultimate-guide-to-iphone-resolutions smime.p7s Description: S/MIME cryptographic signature ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: NSBezierPath + thin lines + antialias = :(
On 09 Feb 2015, at 22:18, Jerry Krinock je...@ieee.org wrote: I may need to break down and learn something about graphics and drawing. I use NSBezierPath in a -[NSView drawRect:] to do an engineering-style drawing. Here is a tiny arrowhead pointing to a vertical “dimension line”: Not very nice. If instead I draw this in a graphics program, with antialiasing off, and save to a png file, the result is much clearer. (Its accuracy is a little compromised, but that’s OK.) Of course this is an old problem, which, I think, goes away with Retina displays. But this is for an update to an OS X app, many of whom’s users have non-Retina displays. Is there a way to draw thin lines in code, and get good results on non-Retina displays? What should I read to learn how? The image didn’t make it to the list, but are you perhaps drawing between pixels? Here’s an article (with pictures!) about this issue I wrote ages ago: http://orangejuiceliberationfront.com/are-your-rectangles-blurry-pale-and-have-rounded-corners/ Does that help? Cheers, -- Uli Kusterer “The Witnesses of TeachText are everywhere...” http://zathras.de ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: NSBezierPath + thin lines + antialias = :(
On Feb 9, 2015, at 1:18 PM, Jerry Krinock je...@ieee.org wrote: Is there a way to draw thin lines in code, and get good results on non-Retina displays? What should I read to learn how? (The listserv strips image attachments, so we can’t see the pictures.) The typical problem drawing thin horizontal/vertical lines is that the line gets split between pixels, so you get a 2-pixel-wide gray line when what you wanted was a 1-pixel black line. The reason this happens is that when you use integer coordinates the line is centered on a pixel boundary, so the left half of the line is in one pixel and the right half is in another. Instead, to draw a one-point line, the coordinate on the axis perpendicular to the line should end in .5. For example, to draw a vertical line at x=100, the x coord of the line should be 100.5. That way you completely fill the pixels at x=100 and no others. (This only applies to odd widths, though. For a 2pt line, you do want whole-number coords.) (It gets more complicated if you’ve transformed the coordinate system, because the above considerations apply to device coords, so you’d have to transform your drawing coords into device coords, do the rounding/offset, and then back. This happens with scaling, but can also occur if you’ve scrolled/offset your coordinates by non-integral amounts.) —Jens ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: NSBezierPath + thin lines + antialias = :(
FWIW (and while we wait for Jerry to tell us what was in the missing screen shot), I’ve abandoned the “offset it by 0.5 points” approach, in the last year or two. I don’t necessarily have an unarguable justification, but my reasoning runs along these lines: 1. For general drawing, when the thin line might be drawn along with non-vertical and non-horizontal lines, the non-vertical and non-horizontal lines are going to be antialiased anyway, so the mixture of drawing outcomes (anti-aliased and not) looks wrong. You can’t eliminate the antialiasing in diagonal lines, so you have to *add* antialiasing to orthogonal lines to get a consistent appearance. It only looks really crappy when the pixels are really big. 2. It’s not 0.5 points anyway, it’s 0.5 pixels. Now, it’s possible to find the connection between points and pixels on any given device, but the whole enterprise starts to fall down when the relationship isn’t 1:1 or 1:2. If the pixels are very small, the perceptual results are not linear — not to mention that the perception is affected by things like the sub-pixel geometry of the screen. (Keep in mind that on the pixeliest new Apple displays, there’s a scaling up AND a scaling down involved in going from points to hardware pixels. With different scale factors.) 3. Seriously, at this point in history, non-retina is done as a technology. There’ll be plenty of 1:1 screens out there for a while, but (I’d argue) it’s hardly worth spending development effort on them. With 1:2 screens it’s already somewhat questionable whether any development effort in pixel alignment is necessary. With 1:3 screens — and how many months do we have left until that becomes the mobile hardware norm? — I’d remove the word “somewhat” from that claim. Of course, there are plenty of specific scenarios — specific apps — where it still makes sense to pay attention to pixels. But not for long, perhaps. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: NSBezierPath + thin lines + antialias = :(
On 10 Feb 2015, at 9:16 am, Quincey Morris quinceymor...@rivergatesoftware.com wrote: FWIW (and while we wait for Jerry to tell us what was in the missing screen shot), I’ve abandoned the “offset it by 0.5 points” approach, in the last year or two. I don’t necessarily have an unarguable justification, but my reasoning runs along these lines: I'd also say that it's just about justified for UI elements (button borders, etc) but never for content, and increasingly less so as you point out. Sound's like Jerry's case is content, so I'd draw it in the correct place and let the system rasterize it. The rationale there is that content such as CAD drawings are ulimately intended to be printed*, and printing technology has way higher resolution than the screen. *Maybe this is becoming less the case, but as someone who occasionally actually builds stuff from physical materials, a hard copy of a drawing is still essential. --Graham ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: NSBezierPath + thin lines + antialias = :(
On 2015 Feb 09, at 13:28, Uli Kusterer witness.of.teacht...@gmx.net wrote: The image didn’t make it to the list, Oh, well. I recall being able to send pictures in the past, as long as the message size was 25K. Maybe this is a new feature :( Here’s an article (with pictures!) about this issue I wrote ages ago: http://orangejuiceliberationfront.com/are-your-rectangles-blurry-pale-and-have-rounded-corners/ Yes, that is the issue. You didn’t need my missing graphics. :) Does that help? Yes, taken together with the explanations from Jens and Quincey. I was wondering if maybe there was some simple way to fix this, but apparently the answer is “Sorry, you need to tweak each line by hand. And I think Quincey’s answer confirmed my suspicion that this a non-issue in Retina displays, and a good business case can be made just ignore it and move on. Thank y’all. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
