Address Book question
I occasionally am getting the following message when I use the address book api to add a record to my sharedAddressBook, which then causes the add to fail: is being ignored because main executable (/System/Library/Frameworks/AddressBook.framework/Resources/AddressBookSync.app/Contents/MacOS/AddressBookSync) is code signed with entitlements What's causing this and how do I resolve the issue? Best regards, John ___ 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: Video bit rate
On Dec 9, 2013, at 2:27 AM, Damien Cooke wrote: > I am taking video on in my iPhone app at 1280x720 this turns out at about > 40Mb/min What I want is to drop the bit rate not the size using > AVAssetWriter/AVAssetReader, is this possible or even the right way of doing > this? Yes. You can specify the bit rate and profile to use when writing. -- Seth Willits ___ 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: Please stay awake!
On 9 Dec 2013, at 23:32, Jens Alfke wrote: > There are also APIs to disable the new “app nap” power-saving feature in OS X > 10.9 — look at NSProcessInfo. My understanding is this is basically a wrapper around the lower level Power Assertion APIs, which have been extended to give App Nap a little more info about what’s going on. If you need to support earlier releases than 10.9, you may find http://www.mikeabdullah.net/kspowerassertion.html helpful. ___ 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: Threaded drawing
>> The single CGContextDrawImage in drawRect: should end up essentially being a >> memcpy which will be ridiculously fast, as long as your contexts/backing all >> use the same color space and bitmap layout as the view’s context’s backing. >> Definitely make sure they’re using the same color space because converting >> is really slow. > > But how can you do that? There’s no CGContextGetColorspace function, except > for a bitmap context, and the context that’s current when drawRect: is > entered does not seem to be a bitmap context. I would have expected it to be, > but it returns nil for all of the CGBitmapContextxxx functions, so my > assumption is it’s a private variant. Same goes for the format, even if it > has one. I’m using the genericRGB colourspace and premultiplied alpha first > for my own contexts. Offhand I couldn’t tell you. The main thing is to look at the profile and inspect what’s happening within the draw call. It’ll be obvious if it’s doing colorspace conversion. Just thinking out loud: There’s NSView’s bitmapImageRepForCachingDisplayInRect: and you can grab a colorspace from the rep. I would certainly imagine that has the ideal space and you can confirm it’s one or another. You can use that method to create your presumably ideal backing and then create multiple contexts that share the same buffer as that original bitmap rep on your background threads. I can’t say whether it’s better or not, but it’s something that comes to mind. (CATiledLayer still sounds like a good idea to me as well.) -- Seth Willits ___ 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: Please stay awake!
There are also APIs to disable the new “app nap” power-saving feature in OS X 10.9 — look at NSProcessInfo. —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: Please stay awake!
On Dec 9, 2013, at 3:17 PM, Jim Elliott wrote: > I have a program that solves problems that are very computationally intense. > I divide up the work and create an NSOperation for each segment. Then I put > the operations in NSOperationQueue, and start the queue. Expecting the job > to take three or four hours, I go to dinner. > > When I return, and look at my progress screen, I find that processing has > stopped sometime about an hour into the job. My mouse events restart the > job, and it later completes, about four hours later than estimated. > > Apparently, after a give time interval without user intervention, MAC OS just > goes to sleep until some user input is detected. I mean not just screen > saver, but processing shutdown. > > Any ideas as to how I keep my megajob running in my absence? Programmatically: https://developer.apple.com/library/mac/qa/qa1340/_index.html From the command line: man caffeinate -- Greg Parker gpar...@apple.com Runtime Wrangler ___ 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
Please stay awake!
I have a program that solves problems that are very computationally intense. I divide up the work and create an NSOperation for each segment. Then I put the operations in NSOperationQueue, and start the queue. Expecting the job to take three or four hours, I go to dinner. When I return, and look at my progress screen, I find that processing has stopped sometime about an hour into the job. My mouse events restart the job, and it later completes, about four hours later than estimated. Apparently, after a give time interval without user intervention, MAC OS just goes to sleep until some user input is detected. I mean not just screen saver, but processing shutdown. Any ideas as to how I keep my megajob running in my absence? Incidentally, sometimes the work performed by each of the operations (threads) is widely asymmetrical? Any explanations? j Jim Elliott sjameselli...@me.com 2732 NW Thurman Street, Portland, OR 97210 USA Tel. +1 (503) 481-5370 Motzstrasse 83A, 10799 Berlin, Germany +49 (30) 269-47848 +49 (179) 757-9132 ___ 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: Threaded drawing
On Mon, Dec 9, 2013, at 02:04 PM, Jens Alfke wrote: > > >> The single CGContextDrawImage in drawRect: should end up essentially being > >> a memcpy which will be ridiculously fast > > The bottleneck for image blitting is copying the pixels from CPU RAM to > GPU texture RAM. This is often a bottleneck in high-speed image drawing, > and I know that Quartz goes through contortions to try to eliminate it > whenever possible. Which is another reason to seriously consider CATiledLayer… it's plausible that the context it uses is located in shared memory on machines with onboard graphics. --Kyle Sluder ___ 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: Threaded drawing
>> The single CGContextDrawImage in drawRect: should end up essentially being a >> memcpy which will be ridiculously fast The bottleneck for image blitting is copying the pixels from CPU RAM to GPU texture RAM. This is often a bottleneck in high-speed image drawing, and I know that Quartz goes through contortions to try to eliminate it whenever possible. —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: Threaded drawing
On 9 Dec 2013, at 7:03 pm, Seth Willits wrote: > If all the drawRect is doing is making a single call to CGContextDrawImage > then it should rightly be 100% of the time, so that measure isn’t interesting > on its own. :) Yes, that’s true. It’s hard to be totally objective, because running Instruments against the app involves some manual input like scrolling, which is hard to reproduce accurately each time without writing a complicated test, but it looks as if it’s roughly 4 times slower when I enable the threaded code (and there I was hoping it would be 4x faster, being the number of cores I have ;-). > You must be passing in incorrect values. It will work. I’ve done this before > and I just tested it now and I’m not getting any assertions like you are. > > If your backing is 1600 x 800, and you want a context for the left half and > another for the right half both have bytesPerRow values of 1600 * 4, a width > of 800, and heigh of 800. The only thing that is different is the buffer > offset. The first one is at 0 and the second at 800 * 4. It may feel odd > because the second context specifies that the last row is 1600 * 4 bytes > wide, but thanks to initial offset and real buffer size is only 800 * 4 wide, > but CG won't try to read or write to those bytes in rows that are after width > * bytesPerPixel, so it really is safe. This sounds like what I was doing, so I’ll check again and make sure my values are really correct - I may well have made a mistake. > The single CGContextDrawImage in drawRect: should end up essentially being a > memcpy which will be ridiculously fast, as long as your contexts/backing all > use the same color space and bitmap layout as the view’s context’s backing. > Definitely make sure they’re using the same color space because converting is > really slow. But how can you do that? There’s no CGContextGetColorspace function, except for a bitmap context, and the context that’s current when drawRect: is entered does not seem to be a bitmap context. I would have expected it to be, but it returns nil for all of the CGBitmapContextxxx functions, so my assumption is it’s a private variant. Same goes for the format, even if it has one. I’m using the genericRGB colourspace and premultiplied alpha first for my own contexts. —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: Threaded drawing
> I think I’ve explored this as far as I can go. Here’s my wrap-up, for what > it’s worth to anyone. Not a lot, I expect. > > The conclusion is, I don’t think it can be done with the current graphics > APIs with any worthwhile performance. Here’s my summary of why that is… > … This last step is where it all falls down, because this one call, to > CGContextDrawImage, takes a whopping 67% of the overall time for drawRect: to > run, and normal drawing doesn’t need this call (this is testing in a ‘light’ > view, but nevertheless, it makes the view very noticeably laggy). If all the drawRect is doing is making a single call to CGContextDrawImage then it should rightly be 100% of the time, so that measure isn’t interesting on its own. :) > 1. Make one big bitmap instead and create a context for each tile... Even if > this worked, it would still require an image draw, but at least it would be > just one, not one per tile. You must be passing in incorrect values. It will work. I’ve done this before and I just tested it now and I’m not getting any assertions like you are. If your backing is 1600 x 800, and you want a context for the left half and another for the right half both have bytesPerRow values of 1600 * 4, a width of 800, and heigh of 800. The only thing that is different is the buffer offset. The first one is at 0 and the second at 800 * 4. It may feel odd because the second context specifies that the last row is 1600 * 4 bytes wide, but thanks to initial offset and real buffer size is only 800 * 4 wide, but CG won't try to read or write to those bytes in rows that are after width * bytesPerPixel, so it really is safe. The single CGContextDrawImage in drawRect: should end up essentially being a memcpy which will be ridiculously fast, as long as your contexts/backing all use the same color space and bitmap layout as the view’s context’s backing. Definitely make sure they’re using the same color space because converting is really slow. And as a general note separate to the threading, are you sure you can’t cache individual objects’ images? (And this just gets into trying to replicate layers, really, though, and with or without layers you’d have a memory usage concern to analyze.) -- Seth Willits ___ 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: Threaded drawing
On Dec 9, 2013, at 9:23 AM, Kyle Sluder wrote: >> On Dec 9, 2013, at 8:50 AM, Graham Cox wrote: > >> >> >>> On 9 Dec 2013, at 5:45 pm, David Duncan wrote: >>> >>> If you have a buffer to draw into, then you can easily slice that buffer to >>> use between multiple graphics contexts, but you will fundamentally have to >>> draw them all into the source context at the end. >> >> >> I wasn’t able to figure out how to do this, so I haven’t tested to see if >> it’s any faster. >> >> By “slice the buffer”, I assume you mean set up a context on some region of >> that buffer, but when I tried to do that, CGBitmapContextCreate[WithData] >> would not accept my bytesPerRow value because it was inconsistent with the >> ‘width’ value, even though I had calculated the bytesPerRow to be the >> correct offset anyway. >> >> So if you know of a practical way to “slice the buffer”, please do share! > > What if all your contexts used the same backing bitmap, but you were > extremely careful to set up their clipping regions such that they never > touched the same pixels? That should at least mostly work. I might have some concern for effects that should read outside of the clipping region (antialiasing for example), but that may not be an issue. You’d notice immediately if it was. As far as slicing, if CGBitmapContextCreate doesn’t let you use columns & rows, it should at least let you use rows, although I would have expected columns & rows to work. > > But I'd seriously consider Mike Abdullah's suggestion. It sounds like > CATiledLayer does most if not all of this work already. > > --Kyle Sluder -- David Duncan ___ 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: Threaded drawing
> On Dec 9, 2013, at 8:50 AM, Graham Cox wrote: > > >> On 9 Dec 2013, at 5:45 pm, David Duncan wrote: >> >> If you have a buffer to draw into, then you can easily slice that buffer to >> use between multiple graphics contexts, but you will fundamentally have to >> draw them all into the source context at the end. > > > I wasn’t able to figure out how to do this, so I haven’t tested to see if > it’s any faster. > > By “slice the buffer”, I assume you mean set up a context on some region of > that buffer, but when I tried to do that, CGBitmapContextCreate[WithData] > would not accept my bytesPerRow value because it was inconsistent with the > ‘width’ value, even though I had calculated the bytesPerRow to be the correct > offset anyway. > > So if you know of a practical way to “slice the buffer”, please do share! What if all your contexts used the same backing bitmap, but you were extremely careful to set up their clipping regions such that they never touched the same pixels? But I'd seriously consider Mike Abdullah's suggestion. It sounds like CATiledLayer does most if not all of this work already. --Kyle Sluder ___ 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: Threaded drawing
On Dec 9, 2013, at 8:45 AM, David Duncan wrote: > One major impediment to this is that you cannot use the same graphics context > between multiple threads, and as such using the graphics context that AppKit > gives you forces you into a single threaded model. Ah, interesting. What’s the slow part of the drawing, Graham? Is it the CG calls themselves, or your own computations that lead up to them? If the latter, you could farm out those computations to multiple threads, and schedule the actual rendering calls on the single thread that has the graphics context. —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: Threaded drawing
On Dec 9, 2013, at 9:50 AM, Graham Cox wrote: > By “slice the buffer”, I assume you mean set up a context on some region of > that buffer, but when I tried to do that, CGBitmapContextCreate[WithData] > would not accept my bytesPerRow value because it was inconsistent with the > ‘width’ value, even though I had calculated the bytesPerRow to be the correct > offset anyway. What were your actual values and what was the assertion? -- Scott Ribe scott_r...@elevated-dev.com http://www.elevated-dev.com/ (303) 722-0567 voice ___ 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: Threaded drawing
On 9 Dec 2013, at 5:45 pm, David Duncan wrote: > If you have a buffer to draw into, then you can easily slice that buffer to > use between multiple graphics contexts, but you will fundamentally have to > draw them all into the source context at the end. I wasn’t able to figure out how to do this, so I haven’t tested to see if it’s any faster. By “slice the buffer”, I assume you mean set up a context on some region of that buffer, but when I tried to do that, CGBitmapContextCreate[WithData] would not accept my bytesPerRow value because it was inconsistent with the ‘width’ value, even though I had calculated the bytesPerRow to be the correct offset anyway. So if you know of a practical way to “slice the buffer”, please do share! —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: Threaded drawing
On 9 Dec 2013, at 5:17 pm, Kevin Meaney wrote: > Probably a question you don't want at this point, because by now your looking > for closure, but did you try different blend modes when calling DrawImage, > specifically the copy blend mode. I'm wondering if that might be faster as > hopefully then it's just moving memory not doing any calculations. That 67% > is a real killer. Yep, that’s with using the copy mode :( —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: Threaded drawing
On 9 Dec 2013, at 5:36 pm, Jens Alfke wrote: > So if you can avoid it, you shouldn’t be doing your own rendering into > images. I haven’t been following the details of this thread, but my guess is > you’ll get better performance by drawing the tiles directly to the view, just > setting a clipping rect beforehand so the drawing is limited to the tile your > thread is working on. > Indeed, that’s certainly my intuition too, if only there were a way to do it. Trouble is, each thread needs its own context in order to draw into the view without a lock on every set of context drawing calls, and there’s no way to create such a context that doesn’t have its own bitmap image. The image is only there because it’s the only way to make a context (that I could see - maybe using a PDF context might work, I’ll try that). —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: Threaded drawing
On Dec 9, 2013, at 8:36 AM, Jens Alfke wrote: > > On Dec 9, 2013, at 7:47 AM, Graham Cox wrote: > >> This last step is where it all falls down, because this one call, to >> CGContextDrawImage, takes a whopping 67% of the overall time for drawRect: >> to run, and normal drawing doesn’t need this call (this is testing in a >> ‘light’ view, but nevertheless, it makes the view very noticeably laggy). > > A few months ago I saw a great presentation given by Apple engineer Andy > Matuschak about the way rendering works on iOS, the whole pipeline all the > way from the app’s API calls to the pixels appearing onscreen. Its purpose > was to teach some intuition about what rendering techniques will perform > better than others. [This specific talk doesn’t seem to be online, but he has > a WWDC talk* that I think covers similar topics.] > > The big picture is that the actual rendering pipeline is > [your app] —> [graphics server process] —> [OpenGL] —> [GPU] —> [Screen] > and the earlier the graphics calls get converted into pixels, the less > efficient the drawing will be, because it’s more expensive to push pixmaps > through the pipeline than lists of drawing commands. > > So if you can avoid it, you shouldn’t be doing your own rendering into > images. I haven’t been following the details of this thread, but my guess is > you’ll get better performance by drawing the tiles directly to the view, just > setting a clipping rect beforehand so the drawing is limited to the tile your > thread is working on. One major impediment to this is that you cannot use the same graphics context between multiple threads, and as such using the graphics context that AppKit gives you forces you into a single threaded model. If you have a buffer to draw into, then you can easily slice that buffer to use between multiple graphics contexts, but you will fundamentally have to draw them all into the source context at the end. > > —Jens > > * “Understanding UIKit Rendering”: > https://developer.apple.com/itunes/?destination=adc.apple.com.8270634034.08270634040.8367260927?i=1122536585 > ___ > > 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/david.duncan%40apple.com > > This email sent to david.dun...@apple.com -- David Duncan ___ 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: Threaded drawing
On Dec 9, 2013, at 7:47 AM, Graham Cox wrote: > This last step is where it all falls down, because this one call, to > CGContextDrawImage, takes a whopping 67% of the overall time for drawRect: to > run, and normal drawing doesn’t need this call (this is testing in a ‘light’ > view, but nevertheless, it makes the view very noticeably laggy). A few months ago I saw a great presentation given by Apple engineer Andy Matuschak about the way rendering works on iOS, the whole pipeline all the way from the app’s API calls to the pixels appearing onscreen. Its purpose was to teach some intuition about what rendering techniques will perform better than others. [This specific talk doesn’t seem to be online, but he has a WWDC talk* that I think covers similar topics.] The big picture is that the actual rendering pipeline is [your app] —> [graphics server process] —> [OpenGL] —> [GPU] —> [Screen] and the earlier the graphics calls get converted into pixels, the less efficient the drawing will be, because it’s more expensive to push pixmaps through the pipeline than lists of drawing commands. So if you can avoid it, you shouldn’t be doing your own rendering into images. I haven’t been following the details of this thread, but my guess is you’ll get better performance by drawing the tiles directly to the view, just setting a clipping rect beforehand so the drawing is limited to the tile your thread is working on. —Jens * “Understanding UIKit Rendering”: https://developer.apple.com/itunes/?destination=adc.apple.com.8270634034.08270634040.8367260927?i=1122536585 ___ 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: Threaded drawing
I've been impressed with the thought you've put into this. Probably a question you don't want at this point, because by now your looking for closure, but did you try different blend modes when calling DrawImage, specifically the copy blend mode. I'm wondering if that might be faster as hopefully then it's just moving memory not doing any calculations. That 67% is a real killer. Kevin On 9 Dec 2013, at 15:47, Graham Cox wrote: > > On 6 Dec 2013, at 5:46 pm, Graham Cox wrote: > >> OK, I’ve now tried this approach, and it’s much cleaner in that it works >> with scrollers, with and without “responsive” scrolling (which appears to >> buffer its contents) and also zooming. Code follows. In this case, drawing >> overall is slower than the normal case, because the simple drawing I’m doing >> doesn’t tax things much, so the set up and tear down of the bitmaps is >> dominating, but I would expect for very complex drawing it would show a win. > > > > I think I’ve explored this as far as I can go. Here’s my wrap-up, for what > it’s worth to anyone. Not a lot, I expect. > > The conclusion is, I don’t think it can be done with the current graphics > APIs with any worthwhile performance. Here’s my summary of why that is. I > really hope someone who knows the graphics innards could take a look and see > if I’ve overlooked anything, because in principle this *could* dramatically > improve drawing performance *if* there were some support for doing it. > > GOAL: to improve drawing performance in a ‘heavy' view by tiling the visible > rect of the view and rendering each tile on a separate thread. By ‘heavy’ I > mean the view has thousands of objects to draw, which ultimately make a huge > number of Core Graphics calls. > > (n.b. in my previously posted code, I tiled the bounds of the view, which is > not quite the same as what I’m talking about here, which is tiling the > visible rect of the view in such a way that each tile renders the scaled, > translated view content into a fixed backing store region. Having solved that > problem, I don’t think it’s worth posting the code because overall this > technique doesn’t gain any performance). > > APPROACH: Each tile is used to construct an offscreen bitmap and a context > that wraps it. The context is set up so that normal drawing (just as if it > were done by -drawRect:) will render into the tile context. Because each tile > has its own context, each one can be executed on a separate thread. In > principle this should show a drawing performance boost because different > non-overlapping parts of the view are drawn in parallel. > > After capturing the tile content, the resulting image is copied back into the > original current context as part of -drawRect: > > This last step is where it all falls down, because this one call, to > CGContextDrawImage, takes a whopping 67% of the overall time for drawRect: to > run, and normal drawing doesn’t need this call (this is testing in a ‘light’ > view, but nevertheless, it makes the view very noticeably laggy). > > However, it’s the only workable approach I’ve managed to discover, so that’s > why I’m stuck. > > ALTERNATIVES THAT WOULD WORK, IF ONLY: > > Because the final drawing of the image takes so long, if that could be > avoided then the threaded drawing would probably be a win. Here’s what I > tried: > > 1. Make one big bitmap instead and create a context for each tile that > represents just a portion of it. This doesn’t work because the tile width and > the bytesPerRow are not consistent with an image that has an exclusive > context for the entire bitmap. Attempting to create the context fails because > of this, even though the byte offset between rows is actually correct. > Essentially, CGBitmapContextCreate() does not trust your bytesPerRow > calculation, even when it’s right. (I say crash and be damned rather than > assert here). Even if this worked, it would still require an image draw, but > at least it would be just one, not one per tile. > > 2. Make one big bitmap + context and set each tile to focus on one portion of > this at a time. This doesn’t work because each thread must have its own > context so that context state is exclusive per thread. > > 3. Make a copy of the current context and focus it per tile. This doesn’t > work because there is no API to copy a context, and/or to share the backing > store of an existing context. > > 4. Create a tile context from the window’s underlying backing store. This > works for simple views, but does not work with scrollers or other more > complex views that use some intermediate buffering. > > I’ll bet there’s some private API that would help here (NSScrollView appears > to be doing something along these lines for ‘responsive’ scrolling) but as > usual Apple are keeping it out of the hands of us plebs. Even back in the old > days of GWorlds on Mac OS 7.x and later you could do this sort of thing much > more easi
Re: Threaded drawing
On 9 Dec 2013, at 5:01 pm, Mike Abdullah wrote: > Maybe a dumb question: How about using CATiledLayer? Well, I haven’t explored it very much, and certainly not in this context, but it seems to me that it’s solving a different problem. It sounds similar, but it’s not actually useful for buffering vector drawing in the way I’m trying to. The tiles are relative to the view’s bounds, so as you zoom in, they get larger - so large that they soon hit hard limits in OpenGL for texture sizes. What I need are tiles that never change size as you zoom in and out, and are relative to the window’s backing store. (As the window size changes, you have more or fewer tiles, but they never change size). If CATiledLayer can be made to work that way (perhaps in some layer-backed subclass of NSClipView) it might be worth exploring, though for now this exercise has me feeling pretty exhausted. The lack of decent documentation isn’t much help either. —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: Threaded drawing
On 9 Dec 2013, at 15:47, Graham Cox wrote: > > On 6 Dec 2013, at 5:46 pm, Graham Cox wrote: > >> OK, I’ve now tried this approach, and it’s much cleaner in that it works >> with scrollers, with and without “responsive” scrolling (which appears to >> buffer its contents) and also zooming. Code follows. In this case, drawing >> overall is slower than the normal case, because the simple drawing I’m doing >> doesn’t tax things much, so the set up and tear down of the bitmaps is >> dominating, but I would expect for very complex drawing it would show a win. > > > > I think I’ve explored this as far as I can go. Here’s my wrap-up, for what > it’s worth to anyone. Not a lot, I expect. > > The conclusion is, I don’t think it can be done with the current graphics > APIs with any worthwhile performance. Here’s my summary of why that is. I > really hope someone who knows the graphics innards could take a look and see > if I’ve overlooked anything, because in principle this *could* dramatically > improve drawing performance *if* there were some support for doing it. > > GOAL: to improve drawing performance in a ‘heavy' view by tiling the visible > rect of the view and rendering each tile on a separate thread. By ‘heavy’ I > mean the view has thousands of objects to draw, which ultimately make a huge > number of Core Graphics calls. > > (n.b. in my previously posted code, I tiled the bounds of the view, which is > not quite the same as what I’m talking about here, which is tiling the > visible rect of the view in such a way that each tile renders the scaled, > translated view content into a fixed backing store region. Having solved that > problem, I don’t think it’s worth posting the code because overall this > technique doesn’t gain any performance). > > APPROACH: Each tile is used to construct an offscreen bitmap and a context > that wraps it. The context is set up so that normal drawing (just as if it > were done by -drawRect:) will render into the tile context. Because each tile > has its own context, each one can be executed on a separate thread. In > principle this should show a drawing performance boost because different > non-overlapping parts of the view are drawn in parallel. > > After capturing the tile content, the resulting image is copied back into the > original current context as part of -drawRect: > > This last step is where it all falls down, because this one call, to > CGContextDrawImage, takes a whopping 67% of the overall time for drawRect: to > run, and normal drawing doesn’t need this call (this is testing in a ‘light’ > view, but nevertheless, it makes the view very noticeably laggy). > > However, it’s the only workable approach I’ve managed to discover, so that’s > why I’m stuck. > > ALTERNATIVES THAT WOULD WORK, IF ONLY: > > Because the final drawing of the image takes so long, if that could be > avoided then the threaded drawing would probably be a win. Here’s what I > tried: > > 1. Make one big bitmap instead and create a context for each tile that > represents just a portion of it. This doesn’t work because the tile width and > the bytesPerRow are not consistent with an image that has an exclusive > context for the entire bitmap. Attempting to create the context fails because > of this, even though the byte offset between rows is actually correct. > Essentially, CGBitmapContextCreate() does not trust your bytesPerRow > calculation, even when it’s right. (I say crash and be damned rather than > assert here). Even if this worked, it would still require an image draw, but > at least it would be just one, not one per tile. > > 2. Make one big bitmap + context and set each tile to focus on one portion of > this at a time. This doesn’t work because each thread must have its own > context so that context state is exclusive per thread. > > 3. Make a copy of the current context and focus it per tile. This doesn’t > work because there is no API to copy a context, and/or to share the backing > store of an existing context. > > 4. Create a tile context from the window’s underlying backing store. This > works for simple views, but does not work with scrollers or other more > complex views that use some intermediate buffering. > > I’ll bet there’s some private API that would help here (NSScrollView appears > to be doing something along these lines for ‘responsive’ scrolling) but as > usual Apple are keeping it out of the hands of us plebs. Even back in the old > days of GWorlds on Mac OS 7.x and later you could do this sort of thing much > more easily than now. > > BOTTOM LINE: > > Creating multiple contexts that draw into a single shared backing store is > currently not possible. This precludes drawing on multiple threads and so > ultimate drawing performance is unattainable. Maybe a dumb question: How about using CATiledLayer? ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Re: Threaded drawing
On 6 Dec 2013, at 5:46 pm, Graham Cox wrote: > OK, I’ve now tried this approach, and it’s much cleaner in that it works with > scrollers, with and without “responsive” scrolling (which appears to buffer > its contents) and also zooming. Code follows. In this case, drawing overall > is slower than the normal case, because the simple drawing I’m doing doesn’t > tax things much, so the set up and tear down of the bitmaps is dominating, > but I would expect for very complex drawing it would show a win. I think I’ve explored this as far as I can go. Here’s my wrap-up, for what it’s worth to anyone. Not a lot, I expect. The conclusion is, I don’t think it can be done with the current graphics APIs with any worthwhile performance. Here’s my summary of why that is. I really hope someone who knows the graphics innards could take a look and see if I’ve overlooked anything, because in principle this *could* dramatically improve drawing performance *if* there were some support for doing it. GOAL: to improve drawing performance in a ‘heavy' view by tiling the visible rect of the view and rendering each tile on a separate thread. By ‘heavy’ I mean the view has thousands of objects to draw, which ultimately make a huge number of Core Graphics calls. (n.b. in my previously posted code, I tiled the bounds of the view, which is not quite the same as what I’m talking about here, which is tiling the visible rect of the view in such a way that each tile renders the scaled, translated view content into a fixed backing store region. Having solved that problem, I don’t think it’s worth posting the code because overall this technique doesn’t gain any performance). APPROACH: Each tile is used to construct an offscreen bitmap and a context that wraps it. The context is set up so that normal drawing (just as if it were done by -drawRect:) will render into the tile context. Because each tile has its own context, each one can be executed on a separate thread. In principle this should show a drawing performance boost because different non-overlapping parts of the view are drawn in parallel. After capturing the tile content, the resulting image is copied back into the original current context as part of -drawRect: This last step is where it all falls down, because this one call, to CGContextDrawImage, takes a whopping 67% of the overall time for drawRect: to run, and normal drawing doesn’t need this call (this is testing in a ‘light’ view, but nevertheless, it makes the view very noticeably laggy). However, it’s the only workable approach I’ve managed to discover, so that’s why I’m stuck. ALTERNATIVES THAT WOULD WORK, IF ONLY: Because the final drawing of the image takes so long, if that could be avoided then the threaded drawing would probably be a win. Here’s what I tried: 1. Make one big bitmap instead and create a context for each tile that represents just a portion of it. This doesn’t work because the tile width and the bytesPerRow are not consistent with an image that has an exclusive context for the entire bitmap. Attempting to create the context fails because of this, even though the byte offset between rows is actually correct. Essentially, CGBitmapContextCreate() does not trust your bytesPerRow calculation, even when it’s right. (I say crash and be damned rather than assert here). Even if this worked, it would still require an image draw, but at least it would be just one, not one per tile. 2. Make one big bitmap + context and set each tile to focus on one portion of this at a time. This doesn’t work because each thread must have its own context so that context state is exclusive per thread. 3. Make a copy of the current context and focus it per tile. This doesn’t work because there is no API to copy a context, and/or to share the backing store of an existing context. 4. Create a tile context from the window’s underlying backing store. This works for simple views, but does not work with scrollers or other more complex views that use some intermediate buffering. I’ll bet there’s some private API that would help here (NSScrollView appears to be doing something along these lines for ‘responsive’ scrolling) but as usual Apple are keeping it out of the hands of us plebs. Even back in the old days of GWorlds on Mac OS 7.x and later you could do this sort of thing much more easily than now. BOTTOM LINE: Creating multiple contexts that draw into a single shared backing store is currently not possible. This precludes drawing on multiple threads and so ultimate drawing performance is unattainable. —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
Re: rangeOfString behaves wierd
On 9 Dec 2013, at 10:38, Gerriet M. Denkmann wrote: > > On 9 Dec 2013, at 16:53, Stephen J. Butler wrote: > >> Would converting each string to NFD (decomposedStringWithCanonicalMapping) >> be an acceptable work around in this case? > No, it would not. I am changing all my rangeOfString calls to use > NSLiteralSearch, which does not have these strange effects. You sure you want to do that? Have a look through http://en.wikipedia.org/wiki/Unicode_equivalence for some examples of combining characters. It is my understanding that NSLiteralSearch will do string comparison on raw unicode characters, and so potentially tell you that two runs of characters are not equal, even though they appear that way to the user. ___ 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: rangeOfString behaves wierd
On 9 Dec 2013, at 16:53, Stephen J. Butler wrote:
> Would converting each string to NFD (decomposedStringWithCanonicalMapping) be
> an acceptable work around in this case?
No, it would not. I am changing all my rangeOfString calls to use
NSLiteralSearch, which does not have these strange effects.
Gerriet.
>
>
> On Mon, Dec 9, 2013 at 3:43 AM, Stephen J. Butler
> wrote:
> OK, you are right. Copy+paste didn't preserve the compatibility character.
> Does look like a bug of sorts, or at least something a unicode expert should
> explain.
>
>
> On Mon, Dec 9, 2013 at 3:20 AM, Gerriet M. Denkmann
> wrote:
>
> On 9 Dec 2013, at 16:00, Stephen J. Butler wrote:
>
> > I don't get the same result. 10.9.0, Xcode 5.0.2. I created an empty
> > command line utility, copied the code, and I get NSNotFound.
> >
> > 2013-12-09 02:50:19.822 Test[73850:303] main "见≠見" (3 shorts) occurs in
> > "见=見見" (4 shorts) at {9223372036854775807, 0}
>
> Copying might invoke another bug.
> Better check the characters, like:
>
> - (void)printString: (NSString *)line
> {
> NSLog(@"%s \"%@\" has characters:",__FUNCTION__, line);
>
> [ line enumerateSubstringsInRange: NSMakeRange( 0, [ line length
> ] )
> options:
> NSStringEnumerationByComposedCharacterSequences
> usingBlock: ^(NSString *currChar, NSRange
> currCharRange, NSRange enclosingRange, BOOL *stop)
> {
> (void)enclosingRange;
> (void)stop;
>
> #ifdef __LITTLE_ENDIAN__
> NSStringEncoding encoding =
> NSUTF32LittleEndianStringEncoding;
> #else
> NSStringEncoding encoding =
> NSUTF32BigEndianStringEncoding;
> #endif
> NSData *data = [ currChar
> dataUsingEncoding: encoding ];
>
> NSUInteger nbrBytes = [ data length ];
> NSUInteger nbrChars = nbrBytes /
> sizeof(unsigned int);
>
> if ( nbrChars * sizeof(unsigned int)
> != nbrBytes ) // error
> {
> NSLog(@"%s Error: strange nbr
> of bytes %lu",__FUNCTION__, nbrBytes);
> return;
> };
>
> unsigned int codePoint[nbrChars];
> [ data getBytes: &codePoint length:
> nbrBytes ];
>
> NSMutableString *s =[
> NSMutableString stringWithFormat: @"%@ = ",
>
> NSStringFromRange(currCharRange)
>
> ];
> for( NSUInteger i = 0; i < nbrChars;
> i++ )
> {
> [ s appendFormat: @"%#06x ",
> codePoint[i] ];
> };
>
> [ s appendFormat: @"= \"%@\"",
> currChar ];
>
> fprintf(stderr, "%s\n", [ s
> UTF8String]);
> }
> ];
> }
>
> and check for:
> "见=見見" has characters:
> {0, 1} = 0x89c1 = "见"
> {1, 1} = 0x003d = "="
> {2, 1} = 0xfa0a = "見"
> {3, 1} = 0x898b = "見"
> "见≠見" has characters:
> {0, 1} = 0x89c1 = "见"
> {1, 1} = 0x2260 = "≠"
> {2, 1} = 0x898b = "見"
>
> >
> > On Mon, Dec 9, 2013 at 2:43 AM, Gerriet M. Denkmann
> > wrote:
> >
> > On 9 Dec 2013, at 15:05, Quincey Morris
> > wrote:
> >
> > > On Dec 8, 2013, at 23:46 , Gerriet M. Denkmann
> > > wrote:
> > >
> > >> NSString *b = @"见≠見";// 0x89c1 0x2260 0x898b
> > >
> > > So what are the results with:
> > >
> > >> NSString *b = @"见”;
> > >> NSString *b = @"≠”;
> > >> NSString *b = @"見”;
> > > ?
> > >
> > > Does specifying an explicit locale make any difference?
> >
> > Explicit specifying en_US (as probably the best tested and debugged) makes
> > no difference.
> >
>
>
>
___
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
Video bit rate
Hi All, I am taking video on in my iPhone app at 1280x720 this turns out at about 40Mb/min What I want is to drop the bit rate not the size using AVAssetWriter/AVAssetReader, is this possible or even the right way of doing this? I am able to get what I want by dropping the bit rate in an external app so can I achieve this on the phone? Regards Damien ___ 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: rangeOfString behaves wierd
Would converting each string to NFD (decomposedStringWithCanonicalMapping)
be an acceptable work around in this case?
On Mon, Dec 9, 2013 at 3:43 AM, Stephen J. Butler
wrote:
> OK, you are right. Copy+paste didn't preserve the compatibility character.
> Does look like a bug of sorts, or at least something a unicode expert
> should explain.
>
>
> On Mon, Dec 9, 2013 at 3:20 AM, Gerriet M. Denkmann
> wrote:
>
>>
>> On 9 Dec 2013, at 16:00, Stephen J. Butler
>> wrote:
>>
>> > I don't get the same result. 10.9.0, Xcode 5.0.2. I created an empty
>> command line utility, copied the code, and I get NSNotFound.
>> >
>> > 2013-12-09 02:50:19.822 Test[73850:303] main "见≠見" (3 shorts) occurs in
>> "见=見見" (4 shorts) at {9223372036854775807, 0}
>>
>> Copying might invoke another bug.
>> Better check the characters, like:
>>
>> - (void)printString: (NSString *)line
>> {
>> NSLog(@"%s \"%@\" has characters:",__FUNCTION__, line);
>>
>> [ line enumerateSubstringsInRange: NSMakeRange( 0, [ line
>> length ] )
>> options:
>>NSStringEnumerationByComposedCharacterSequences
>> usingBlock: ^(NSString *currChar, NSRange
>> currCharRange, NSRange enclosingRange, BOOL *stop)
>> {
>> (void)enclosingRange;
>> (void)stop;
>>
>> #ifdef __LITTLE_ENDIAN__
>> NSStringEncoding encoding
>> = NSUTF32LittleEndianStringEncoding;
>> #else
>> NSStringEncoding encoding
>> = NSUTF32BigEndianStringEncoding;
>> #endif
>> NSData *data = [ currChar
>> dataUsingEncoding: encoding ];
>>
>> NSUInteger nbrBytes = [ data
>> length ];
>> NSUInteger nbrChars = nbrBytes /
>> sizeof(unsigned int);
>>
>> if ( nbrChars * sizeof(unsigned
>> int) != nbrBytes ) // error
>> {
>> NSLog(@"%s Error: strange
>> nbr of bytes %lu",__FUNCTION__, nbrBytes);
>> return;
>> };
>>
>> unsigned int codePoint[nbrChars];
>> [ data getBytes: &codePoint
>> length: nbrBytes ];
>>
>> NSMutableString *s =[
>> NSMutableString stringWithFormat: @"%@ = ",
>>
>> NSStringFromRange(currCharRange)
>>
>> ];
>> for( NSUInteger i = 0; i <
>> nbrChars; i++ )
>> {
>> [ s appendFormat: @"%#06x
>> ", codePoint[i] ];
>> };
>>
>> [ s appendFormat: @"= \"%@\"",
>> currChar ];
>>
>> fprintf(stderr, "%s\n", [ s
>> UTF8String]);
>> }
>> ];
>> }
>>
>> and check for:
>> "见=見見" has characters:
>> {0, 1} = 0x89c1 = "见"
>> {1, 1} = 0x003d = "="
>> {2, 1} = 0xfa0a = "見"
>> {3, 1} = 0x898b = "見"
>> "见≠見" has characters:
>> {0, 1} = 0x89c1 = "见"
>> {1, 1} = 0x2260 = "≠"
>> {2, 1} = 0x898b = "見"
>>
>> >
>> > On Mon, Dec 9, 2013 at 2:43 AM, Gerriet M. Denkmann <
>> gerr...@mdenkmann.de> wrote:
>> >
>> > On 9 Dec 2013, at 15:05, Quincey Morris <
>> quinceymor...@rivergatesoftware.com> wrote:
>> >
>> > > On Dec 8, 2013, at 23:46 , Gerriet M. Denkmann
>> wrote:
>> > >
>> > >> NSString *b = @"见≠見";// 0x89c1 0x2260 0x898b
>> > >
>> > > So what are the results with:
>> > >
>> > >> NSString *b = @"见”;
>> > >> NSString *b = @"≠”;
>> > >> NSString *b = @"見”;
>> > > ?
>> > >
>> > > Does specifying an explicit locale make any difference?
>> >
>> > Explicit specifying en_US (as probably the best tested and debugged)
>> makes no difference.
>> >
>>
>>
>
___
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: rangeOfString behaves wierd
OK, you are right. Copy+paste didn't preserve the compatibility character.
Does look like a bug of sorts, or at least something a unicode expert
should explain.
On Mon, Dec 9, 2013 at 3:20 AM, Gerriet M. Denkmann wrote:
>
> On 9 Dec 2013, at 16:00, Stephen J. Butler
> wrote:
>
> > I don't get the same result. 10.9.0, Xcode 5.0.2. I created an empty
> command line utility, copied the code, and I get NSNotFound.
> >
> > 2013-12-09 02:50:19.822 Test[73850:303] main "见≠見" (3 shorts) occurs in
> "见=見見" (4 shorts) at {9223372036854775807, 0}
>
> Copying might invoke another bug.
> Better check the characters, like:
>
> - (void)printString: (NSString *)line
> {
> NSLog(@"%s \"%@\" has characters:",__FUNCTION__, line);
>
> [ line enumerateSubstringsInRange: NSMakeRange( 0, [ line
> length ] )
> options:
> NSStringEnumerationByComposedCharacterSequences
> usingBlock: ^(NSString *currChar, NSRange
> currCharRange, NSRange enclosingRange, BOOL *stop)
> {
> (void)enclosingRange;
> (void)stop;
>
> #ifdef __LITTLE_ENDIAN__
> NSStringEncoding encoding
> = NSUTF32LittleEndianStringEncoding;
> #else
> NSStringEncoding encoding
> = NSUTF32BigEndianStringEncoding;
> #endif
> NSData *data = [ currChar
> dataUsingEncoding: encoding ];
>
> NSUInteger nbrBytes = [ data
> length ];
> NSUInteger nbrChars = nbrBytes /
> sizeof(unsigned int);
>
> if ( nbrChars * sizeof(unsigned
> int) != nbrBytes ) // error
> {
> NSLog(@"%s Error: strange
> nbr of bytes %lu",__FUNCTION__, nbrBytes);
> return;
> };
>
> unsigned int codePoint[nbrChars];
> [ data getBytes: &codePoint
> length: nbrBytes ];
>
> NSMutableString *s =[
> NSMutableString stringWithFormat: @"%@ = ",
>
> NSStringFromRange(currCharRange)
>
> ];
> for( NSUInteger i = 0; i <
> nbrChars; i++ )
> {
> [ s appendFormat: @"%#06x
> ", codePoint[i] ];
> };
>
> [ s appendFormat: @"= \"%@\"",
> currChar ];
>
> fprintf(stderr, "%s\n", [ s
> UTF8String]);
> }
> ];
> }
>
> and check for:
> "见=見見" has characters:
> {0, 1} = 0x89c1 = "见"
> {1, 1} = 0x003d = "="
> {2, 1} = 0xfa0a = "見"
> {3, 1} = 0x898b = "見"
> "见≠見" has characters:
> {0, 1} = 0x89c1 = "见"
> {1, 1} = 0x2260 = "≠"
> {2, 1} = 0x898b = "見"
>
> >
> > On Mon, Dec 9, 2013 at 2:43 AM, Gerriet M. Denkmann <
> gerr...@mdenkmann.de> wrote:
> >
> > On 9 Dec 2013, at 15:05, Quincey Morris <
> quinceymor...@rivergatesoftware.com> wrote:
> >
> > > On Dec 8, 2013, at 23:46 , Gerriet M. Denkmann
> wrote:
> > >
> > >> NSString *b = @"见≠見";// 0x89c1 0x2260 0x898b
> > >
> > > So what are the results with:
> > >
> > >> NSString *b = @"见”;
> > >> NSString *b = @"≠”;
> > >> NSString *b = @"見”;
> > > ?
> > >
> > > Does specifying an explicit locale make any difference?
> >
> > Explicit specifying en_US (as probably the best tested and debugged)
> makes no difference.
> >
>
>
___
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: rangeOfString behaves wierd
On Dec 9, 2013, at 01:00 , Stephen J. Butler wrote:
> I don't get the same result. 10.9.0, Xcode 5.0.2. I created an empty
> command line utility, copied the code, and I get NSNotFound.
>
> 2013-12-09 02:50:19.822 Test[73850:303] main "见≠見" (3 shorts) occurs in
> "见=見見" (4 shorts) at {9223372036854775807, 0}
It’s not the same test if you just copy the code. I just tried that, and added
the codepoint dump too:
> -[BPMAppDelegate applicationDidFinishLaunching:] "见≠見" (3 shorts) occurs in
> "见=見見" (4 shorts) at {9223372036854775807, 0}
> -[BPMAppDelegate printString:] "见=見見" has characters:
> {0, 1} = 0x89c1 = "见"
> {1, 1} = 0x003d = "="
> {2, 1} = 0x898b = "見"
> {3, 1} = 0x898b = "見"
> -[BPMAppDelegate printString:] "见≠見" has characters:
> {0, 1} = 0x89c1 = "见"
> {1, 1} = 0x2260 = "≠"
> {2, 1} = 0x898b = “見"
and the compatibility character has been changed to the unified one.
___
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: rangeOfString behaves wierd
On 9 Dec 2013, at 16:00, Stephen J. Butler wrote:
> I don't get the same result. 10.9.0, Xcode 5.0.2. I created an empty command
> line utility, copied the code, and I get NSNotFound.
>
> 2013-12-09 02:50:19.822 Test[73850:303] main "见≠見" (3 shorts) occurs in
> "见=見見" (4 shorts) at {9223372036854775807, 0}
Copying might invoke another bug.
Better check the characters, like:
- (void)printString: (NSString *)line
{
NSLog(@"%s \"%@\" has characters:",__FUNCTION__, line);
[ line enumerateSubstringsInRange: NSMakeRange( 0, [ line length ]
)
options:
NSStringEnumerationByComposedCharacterSequences
usingBlock: ^(NSString *currChar, NSRange
currCharRange, NSRange enclosingRange, BOOL *stop)
{
(void)enclosingRange;
(void)stop;
#ifdef __LITTLE_ENDIAN__
NSStringEncoding encoding =
NSUTF32LittleEndianStringEncoding;
#else
NSStringEncoding encoding =
NSUTF32BigEndianStringEncoding;
#endif
NSData *data = [ currChar
dataUsingEncoding: encoding ];
NSUInteger nbrBytes = [ data length ];
NSUInteger nbrChars = nbrBytes /
sizeof(unsigned int);
if ( nbrChars * sizeof(unsigned int) !=
nbrBytes ) // error
{
NSLog(@"%s Error: strange nbr
of bytes %lu",__FUNCTION__, nbrBytes);
return;
};
unsigned int codePoint[nbrChars];
[ data getBytes: &codePoint length:
nbrBytes ];
NSMutableString *s =[
NSMutableString stringWithFormat: @"%@ = ",
NSStringFromRange(currCharRange)
];
for( NSUInteger i = 0; i < nbrChars;
i++ )
{
[ s appendFormat: @"%#06x ",
codePoint[i] ];
};
[ s appendFormat: @"= \"%@\"", currChar
];
fprintf(stderr, "%s\n", [ s
UTF8String]);
}
];
}
and check for:
"见=見見" has characters:
{0, 1} = 0x89c1 = "见"
{1, 1} = 0x003d = "="
{2, 1} = 0xfa0a = "見"
{3, 1} = 0x898b = "見"
"见≠見" has characters:
{0, 1} = 0x89c1 = "见"
{1, 1} = 0x2260 = "≠"
{2, 1} = 0x898b = "見"
>
> On Mon, Dec 9, 2013 at 2:43 AM, Gerriet M. Denkmann
> wrote:
>
> On 9 Dec 2013, at 15:05, Quincey Morris
> wrote:
>
> > On Dec 8, 2013, at 23:46 , Gerriet M. Denkmann wrote:
> >
> >> NSString *b = @"见≠見";// 0x89c1 0x2260 0x898b
> >
> > So what are the results with:
> >
> >> NSString *b = @"见”;
> >> NSString *b = @"≠”;
> >> NSString *b = @"見”;
> > ?
> >
> > Does specifying an explicit locale make any difference?
>
> Explicit specifying en_US (as probably the best tested and debugged) makes no
> difference.
>
___
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: rangeOfString behaves wierd
I don't get the same result. 10.9.0, Xcode 5.0.2. I created an empty
command line utility, copied the code, and I get NSNotFound.
2013-12-09 02:50:19.822 Test[73850:303] main "见≠見" (3 shorts) occurs in
"见=見見" (4 shorts) at {9223372036854775807, 0}
On Mon, Dec 9, 2013 at 2:43 AM, Gerriet M. Denkmann wrote:
>
> On 9 Dec 2013, at 15:05, Quincey Morris <
> quinceymor...@rivergatesoftware.com> wrote:
>
> > On Dec 8, 2013, at 23:46 , Gerriet M. Denkmann
> wrote:
> >
> >> NSString *b = @"见≠見";// 0x89c1 0x2260 0x898b
> >
> > So what are the results with:
> >
> >> NSString *b = @"见”;
> >> NSString *b = @"≠”;
> >> NSString *b = @"見”;
> > ?
> >
> > Does specifying an explicit locale make any difference?
>
> Explicit specifying en_US (as probably the best tested and debugged) makes
> no difference.
>
> Gerriet.
>
>
>
> ___
>
> 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/stephen.butler%40gmail.com
>
> This email sent to stephen.but...@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: rangeOfString behaves wierd
On Dec 9, 2013, at 00:22 , Gerriet M. Denkmann wrote:
> but I have great difficulties imagining a place on this world where = is the
> same as ≠.
> NSDiacriticInsensitiveSearch → "见≠見" (3 shorts) occurs in "见=見見" (4
> shorts) at {0, 3}
The latter suggests that the bar across the equals sign might be regarded as a
diacritic. In that sense, it might be something similar to an ‘i’ and a dotless
‘i’. In both cases, there might be *some* justification for regarding the
characters as equal in a non-literal search.
Interestingly, this page:
> http://www.fileformat.info/info/unicode/char/fa0a/index.htm
shows 0xfa0a “decomposing” to 0x898b, which if technically correct may well
have some effect on the results you’re seeing.
Clearly, there’s a bug, in at least the range returned by your original
example. It’s unclear whether the match is also a bug.
On Dec 9, 2013, at 00:30 , Gerriet M. Denkmann wrote:
> NSLog(@"%s %@",__FUNCTION__, [ currentLocale localeIdentifier]);
> prints: en_IE
> Explicit specifying en_US (as probably the best tested and debugged) makes no
> difference.
I meant you should try the locale of the language (Japanese?) to which the
characters belong.
___
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: rangeOfString behaves wierd
On 9 Dec 2013, at 15:05, Quincey Morris wrote: > On Dec 8, 2013, at 23:46 , Gerriet M. Denkmann wrote: > >> NSString *b = @"见≠見";// 0x89c1 0x2260 0x898b > > So what are the results with: > >> NSString *b = @"见”; >> NSString *b = @"≠”; >> NSString *b = @"見”; > ? > > Does specifying an explicit locale make any difference? Explicit specifying en_US (as probably the best tested and debugged) makes no difference. Gerriet. ___ 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: rangeOfString behaves wierd
On 9 Dec 2013, at 15:05, Quincey Morris wrote: > On Dec 8, 2013, at 23:46 , Gerriet M. Denkmann wrote: > >> NSString *b = @"见≠見";// 0x89c1 0x2260 0x898b > > So what are the results with: > >> NSString *b = @"见”; >> NSString *b = @"≠”; >> NSString *b = @"見”; > ? > > And what’s the current locale? NSLocale *currentLocale = [ NSLocale currentLocale ]; NSLog(@"%s %@",__FUNCTION__, [ currentLocale localeIdentifier]); prints: en_IE ___ 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: rangeOfString behaves wierd
On 9 Dec 2013, at 15:05, Quincey Morris
wrote:
> On Dec 8, 2013, at 23:46 , Gerriet M. Denkmann wrote:
>
>> NSString *b = @"见≠見";// 0x89c1 0x2260 0x898b
>
> So what are the results with:
>
>> NSString *b = @"见”;
>> NSString *b = @"≠”;
>> NSString *b = @"見”;
> ?
>
> And what’s the current locale? Does specifying an explicit locale make any
> difference?
I don't know (but might test later) - but I have great difficulties imagining a
place on this world where = is the same as ≠.
But then, there are people who have "believed as many as six impossible things
before breakfast.” Maybe I just need practicing.
What does make a difference are options:
NSLiteralSearch → behaves as expected
NSDiacriticInsensitiveSearch → "见≠見" (3 shorts) occurs in "见=見見" (4 shorts) at
{0, 3}
all others: (excluding NSRegularExpressionSearch which does not apply;
including no options) get:
"见≠見" (3 shorts) occurs in "见=見見" (4 shorts) at {0, 4}
Kind regards,
Gerriet.
___
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: rangeOfString behaves wierd
On Dec 8, 2013, at 23:46 , Gerriet M. Denkmann wrote: > NSString *b = @"见≠見"; // 0x89c1 0x2260 0x898b So what are the results with: > NSString *b = @"见”; > NSString *b = @"≠”; > NSString *b = @"見”; ? And what’s the current locale? Does specifying an explicit locale make any difference? ___ 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: rangeOfString behaves wierd
On 9 Dec 2013, at 14:51, Igor Elland wrote:
> Are you taking into account that 见,≠, and 見 are composed character sequences,
> not individual unichars?
>
This method:
- (void)printString: (NSString *)line
{
NSLog(@"%s \"%@\" has characters:",__FUNCTION__, line);
[ line enumerateSubstringsInRange: NSMakeRange( 0, [ line length ]
)
options:
NSStringEnumerationByComposedCharacterSequences
usingBlock: ^(NSString *currChar, NSRange
currCharRange, NSRange enclosingRange, BOOL *stop)
{
(void)enclosingRange;
(void)stop;
unichar u = [ currChar
characterAtIndex: 0 ];
NSString *s = [ NSString
stringWithFormat: @"%@ = %#06x = \"%@\"",
NSStringFromRange(currCharRange), u, currChar
];
fprintf(stderr, "%s\n", [ s
UTF8String]);
}
];
}
prints:
"见=見見" has characters:
{0, 1} = 0x89c1 = "见"
{1, 1} = 0x003d = "="
{2, 1} = 0xfa0a = "見"
{3, 1} = 0x898b = "見"
"见≠見" has characters:
{0, 1} = 0x89c1 = "见"
{1, 1} = 0x2260 = "≠"
{2, 1} = 0x898b = "見"
which shows (to my limited understanding) that there are NO composed character
sequences.
Kind regards,
Gerriet.
> On 09 Dec 2013, at 08:46, Gerriet M. Denkmann wrote:
>
>> In 10.9.0, Xcode 5.0.2 I added these lines to applicationDidFinishLaunching:
>>
>> NSString *a = @"见=見見"; // 0x89c1 0x3d0xfa0a 0x898b
>> NSString *b = @"见≠見";// 0x89c1 0x2260 0x898b
>> NSRange aRange = [ a rangeOfString: b ];
>> NSLog(@"%s \"%@\" (%lu shorts) occurs in \"%@\" (%lu shorts) at
>> %@",__FUNCTION__,
>> b, [b length], a, [a length], NSStringFromRange(aRange));
>>
>> And was told:
>> "见≠見" (3 shorts) occurs in "见=見見" (4 shorts) at {0, 4}
>>
>> This comes somewhat unexpected.
>>
>> What am I doing wrong?
>>
>> Or are my expectations false?
>> I would (maybe naively) expect that the shorter string could at most occur
>> at {0,3}.
>> I would also expect that ≠ is NOT quite the same as =.
>> But then, I was wrong before.
>>
>> Gerriet.
___
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
