Re: Xcode - An Apple Embarrassment
On 02.03.2012, at 03:24, Todd Heberlein wrote: > I did find the switch from 3.x to 4.x jarring, but I have adjusted. > > I am still using Version 4.1, and for me it has been fairly stable. Are the > instability issues everyone is complaining about more with versions 4.2 and > 4.3? That's been my experience. I give 4.0 slack because it was a first major revision. It got better for a while, and even 4.2 was still bearable (though had a few compiler/optimizer bugs that caused us trouble), but 4.3 crashes left and right for me, many times a day. I didn't even mind that much when it was still beta, but that they released it as final when it was still so crashy...? Cheers, -- Uli Kusterer "The Witnesses of TeachText are everywhere..." http://www.masters-of-the-void.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: Xcode - An Apple Embarrassment
On 01.03.2012, at 15:01, George Toledo wrote: > Does anyone require devs at Apple to use Xcode 4, or conform to the broken > technologies that are foisted upon outside Developers? I don't know... > totally rhetorical, but I'd hope not, because as bad as it is to have this > put upon us, I'd hate to think they're using this trash across the board. I can't say for Xcode 4, but I've heard from an Apple employee that they had to use the weekly builds of Xcode, and needed to give a *very* good reason if they wanted to skip one. That said, not everyone uses Xcode. I vaguely remember hearing that the Kernel folks mainly use Makefiles. Which makes sense considering how much of that is open source, cross-platform etc. Cheers, -- Uli Kusterer "The Witnesses of TeachText are everywhere..." http://www.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: Xcode - An Apple Embarrassment
On 01.03.2012, at 06:26, Alex Zavatone wrote: > Makes me wonder how AppleScript is still alive at Apple then. What, are > there two people on it internally or only one? Apple tried to kill AppleScript ages ago. But some big groups of users (e.g. pre-press) use it so extensively to automate their workflow that they had to go back on that. My guess is that group is still large enough to take care of that. Also, Apple Events are used extensively for launching applications and documents, handing URLs to applications etc. I'd wager a guess that it would be a lot of work at this point to remove those, and if you have Apple Events, removing AppleScript working on top of it is unlikely to save much manpower. Cheers, -- Uli Kusterer "The Witnesses of TeachText are everywhere..." http://www.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: Xcode - An Apple Embarrassment
Here is my theory… I know that Xcode is used internally at Apple, but not always the same versions we get. I know that Xcode 3.x was still used internally by a lot of teams for some time after Xcode 4.x was pushed on us in the consumer side. Now that Xcode 4.3 is pushing LLDB on us with project level warnings (I RAGE that I can't turn that off), even though LLDB is packed full of bugs, I know Apple has a version that still uses GDB by default. Even at WWDC, the Xcode preview we got was different than the Xcode that was used on stage (menus and buttons in different locations than we get). So I think sometimes we are the Guinea pigs because internally teams do not always use the latest new shinny versions of the same tools we get. Our radars knock out the bugs faster than they do internally at Apple. Not by some grand intention either. Internal teams don't fall under the same rules we do for what version of Xcode we have to use to get into the App Stores. The different teams at Apple can mandate older or other internal builds and never have to drive to use an updated version until later. This is all theory but it's an educated one. -- Zac Bowling On Thursday, March 1, 2012 at 5:27 AM, H. Miersch wrote: > > Xcode is used exhaustively within Apple, > > > makes you think that they have an incentive to get it right, right? so what's > the problem? > ___ > > Cocoa-dev mailing list (Cocoa-dev@lists.apple.com > (mailto: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 > (http://lists.apple.com) > > Help/Unsubscribe/Update your Subscription: > https://lists.apple.com/mailman/options/cocoa-dev/zac%40zacbowling.com > > This email sent to z...@zacbowling.com (mailto:z...@zacbowling.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: Xcode - An Apple Embarrassment
> not everyone uses Xcode. I vaguely remember hearing that the Kernel folks > mainly use Makefiles. Which makes sense considering how much of that is open > source, cross-platform etc. I recently bought a book on OpenCL partly written by some guy at Apple (can’t remember the title right now since I bought it for future reference and put it in my shelf). The first chapter describes the per-platform IDE suitable to use OpenGL. XCode was mentioned, but, obviously, the co-author was using Code::Blocks instead. Vincent ___ 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: How are views supposed to reload after being nillified by memory warnings?
> > How do you know the white view is screen-sized and has no superview? > Actually a UIView which you can see and yet has no superview is probably > just the UIWindow itself. > I write info about it to a log, in viewDidLoad. How about the view which has just been loaded? Does it have a superview? That is the white view. Probably won't at that point, it's only been loaded, not moved into place. > Go override the viewWillAppear:/viewDidAppear: methods and see if they get > called. > I'll try that. One question, there's no non-standard UIViewController usage here right? ie > you have just ONE view controller for each screen Yep. It's a very straightforward structure. Someone taps on a tableview row, and we push the controller onto the navigation stack. What's showing on the screen when this viewcontroller of yours is getting > blown away by a memory warning, and how did that new content get there? > It's the photo-picker (actually a view that presents the photo picker and then lets the user add a caption). It's presented with presentModalViewController and dismissed by the delegate, as is typical. The Apple photo picker often results in memory warnings (based on various forum posts I've seen). It's after the dismissal of the picker's owning controller that the white screen is revealed. Thanks a lot for the follow-up. Gavin ___ 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: Xcode - An Apple Embarrassment - AppleScript
On Mar 2, 2012, at 3:25 AM, Uli Kusterer wrote: > On 01.03.2012, at 06:26, Alex Zavatone wrote: >> Makes me wonder how AppleScript is still alive at Apple then. What, are >> there two people on it internally or only one? > > Apple tried to kill AppleScript ages ago. But some big groups of users (e.g. > pre-press) use it so extensively to automate their workflow that they had to > go back on that. My guess is that group is still large enough to take care of > that. > > Also, Apple Events are used extensively for launching applications and > documents, handing URLs to applications etc. I'd wager a guess that it would > be a lot of work at this point to remove those, and if you have Apple Events, > removing AppleScript working on top of it is unlikely to save much manpower. > > Cheers, > -- Uli Kusterer > "The Witnesses of TeachText are everywhere..." > http://www.zathras.de Thanks Uli. While at Verizon (A big phone and now TV company in the US) I writing a GUI creation system that took structured designs in Illustrator and Photoshop and ended up creating functional screens and layout files in 10 languages and file formats with properly separated and optimized graphics. How did I do this? Mostly Applescript. And then I wrapped it in an Xcode app (thanks Shane). Automation of Illustrator, Photoshop, TextEdit, the Finder, SVN, turned a multi hour process into minutes and the developers were presented with optimized graphics and draw code in C, Javascript, Lua, JSON, XML, HTML, CSS, Excel format, etc…, etc…. Doing it in the interpreted, no compile required, AppleScript allowed me to develop and test faster. Being able to wrap it in an Xcode app allowed it to be a real and protected app that could be serialized to run on certain machines and not be stolen. AppleScript - though weird at times (can we KILL the set statement?) - has many many benefits. A video of it doing its thing is here: http://homepage.mac.com/zav/Zavatone-Production-Tool-Demo.mov In the gig after that, we had to convert 2000 SCOBOL screens into modern HTML, JSON and Javascript. Guess what? The tool we had from a certain vendor ignored certain super important factors. So, out comes the AppleScript again, and 3 months later, in a simple top to bottom parsing process with some REGEX shell scripts, I was able to create a script that would convert up to 400 screens in an hour. Here it is: http://homepage.mac.com/zav/Cobol-to-HTML-demo.m4v Killing AppleScript, though probably expensive for Apple to support, would be really really stupid. Cheers, - Alex Zavatone ___ 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: Xcode - An Apple Embarrassment - AppleScript
Sorry, "I wrote". Not "I writing". On Mar 2, 2012, at 11:00 AM, Alex Zavatone wrote: > While at Verizon (A big phone and now TV company in the US) I writing a GUI > creation system that took structured designs in Illustrator and Photoshop and > ended up creating ___ 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: Round corners of borderless NSWindow without set it transparent
Il giorno 29/feb/2012, alle ore 22:43, Andrea3000 ha scritto: > I'm sorry if you think I'm too lazy to debug it myself. I never intended to > implicitly ask you to download and debug the app for me, believe me. > > I posted a demo project simply because I think that the issue isn't related > to my code; I have always seen this behavior with non opaque window and it's > for this reason that > I'm looking for a way to round corners of an opaque borderless window. > > I can prove my assumption. If you create a new Xcode project choosing the > application template you will have a simple window already created in IB. > Setting that window non opaque is enough to exibit the issue I'm talking > about. > > Anyway, I'm going to analyze this last example with Time Profiler in order to > have a deeper insight of the issue. > > Thank you for your help > Regards > > Andrea Here I am after few hours of testing. I've created a new Xcode project with "Cocoa Application" template and I've added [window setOpaque: ] in the application delegate. I haven't done any other change from the original "Cocoa Application" template project. I've then performed quite all the sampling that I can think of and all of them have been performed twice: first with [window setOpaque:YES] and then with [window setOpaque:NO]. In both of the case the only action that I have performed during sampling has been resizing the window both fast and slow. This is what I've discovered: Instruments doesn't show any noticeable difference between the opaque and transparent window while you can clearly see the difference looking at the screen because with transparent window the resize is sluggish. I was pulling my hair out because of this but finally I've discovered a very strong difference. I've opened "Quartz Debug" and performed the same fast resize; when the window is opaque I get 60fps as refresh rate (which is what my monitor can handle) but when the window is transparent the refresh rate is below 20fps!! This is clearly the cause of the sluggish behavior of the transparent window. But I don't know what to do now. Is this an expected behavior. To me, 18fps are really insufficient.. ___ 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: How are views supposed to reload after being nillified by memory warnings?
On Mar 2, 2012, at 1:28 AM, G S wrote: > It's the photo-picker (actually a view that presents the photo picker and > then lets the user add a caption). It's presented with > presentModalViewController and dismissed by the delegate, as is typical. > > The Apple photo picker often results in memory warnings (based on various > forum posts I've seen). It's after the dismissal of the picker's owning > controller that the white screen is revealed. In the vast majority of cases where I've seen this behavior, it is because in your delegate handler for the UIImagePickerController, you assign the returned image directly to a UIImageView that you have in your view hierarchy. If you've recently gotten a memory warning, then this image view is either nil, or will be released very soon, and you will end up with a view that has no image. If this does turn out to be the case, then lesson learned is "never store critical data in my views". -- 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
Question on handling very large images
Hi Everyone, I find myself in the situation of having to manipulate and display a few very large images in an app running on iOS (potentially in the tens of megapixels at 24 bits/pixel), and I am trying to figure out what the correct pattern for doing so is. I've Googled for solutions, but there seems to be a large amount of variance in the kinds of answers that I've found, so I wanted to ask for some advice before heading out on a wild goose chase. Can anyone share their view or point me in the direction of some good ideas? My first instinct is to use a memory-mapped file (e.g.: using NSMutableData) to hold the data while I work on it, but I worry that it will be very slow and that I'm missing a much simpler solution. All help greatly appreciated! Cheers, Marco ___ 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: Round corners of borderless NSWindow without set it transparent
As written in the last mail, I'm no longer using the example with rounded corner. I'm using an unmodified "Cocoa Application" template project with just the transparent/opacity toggle. Therefore I haven't any auxiliary view and therefore no rounded corners, just the default window. Il giorno 02/mar/2012, alle ore 20:29, Gary L. Wade ha scritto: > If I recall, another difference is you're drawing rounded rectangles during > the slower speed and regular rectangles during the faster one. Rounded > rectangles take longer to draw. > -- > Gary L. Wade (Sent from my iPhone) > http://www.garywade.com/ > > On Mar 2, 2012, at 9:29 AM, Andrea3000 wrote: > >> >> Il giorno 29/feb/2012, alle ore 22:43, Andrea3000 ha scritto: >> >>> I'm sorry if you think I'm too lazy to debug it myself. I never intended >>> to implicitly ask you to download and debug the app for me, believe me. >>> >>> I posted a demo project simply because I think that the issue isn't related >>> to my code; I have always seen this behavior with non opaque window and >>> it's for this reason that >>> I'm looking for a way to round corners of an opaque borderless window. >>> >>> I can prove my assumption. If you create a new Xcode project choosing the >>> application template you will have a simple window already created in IB. >>> Setting that window non opaque is enough to exibit the issue I'm talking >>> about. >>> >>> Anyway, I'm going to analyze this last example with Time Profiler in order >>> to have a deeper insight of the issue. >>> >>> Thank you for your help >>> Regards >>> >>> Andrea >> >> Here I am after few hours of testing. >> I've created a new Xcode project with "Cocoa Application" template and I've >> added [window setOpaque: ] in the application delegate. >> I haven't done any other change from the original "Cocoa Application" >> template project. >> >> I've then performed quite all the sampling that I can think of and all of >> them have been performed twice: first with [window setOpaque:YES] and then >> with [window setOpaque:NO]. >> In both of the case the only action that I have performed during sampling >> has been resizing the window both fast and slow. >> >> This is what I've discovered: >> >> Instruments doesn't show any noticeable difference between the opaque and >> transparent window while you can clearly see the difference looking at the >> screen because with transparent >> window the resize is sluggish. >> I was pulling my hair out because of this but finally I've discovered a very >> strong difference. >> I've opened "Quartz Debug" and performed the same fast resize; when the >> window is opaque I get 60fps as refresh rate (which is what my monitor can >> handle) but when the window is transparent the refresh rate is below 20fps!! >> This is clearly the cause of the sluggish behavior of the transparent window. >> >> But I don't know what to do now. Is this an expected behavior. To me, 18fps >> are really insufficient.. >> >> >> >> ___ >> >> 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/garywade%40desisoftsystems.com >> >> This email sent to garyw...@desisoftsystems.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: Xcode - An Apple Embarrassment
Fri, 02 Mar 2012 16:00:41 +0900 On John Joyce wrote: > I have to agree with Gene. I wasn't going to acknowledge this thread, but it > is good to hear more than just people moaning. > > The initial adjustment to 4.x was jarring, but once you get used to the > changes, they're mostly great! > To the credit of the Xcode dev team, this thing is a HUGE undertaking and > it's only gotten better with each update! > What clang & llvm do for code completion.. and the fix-it mechanism... just > awesome and amazing. > Just think how much work it is to build any IDE or fancy text editor... now > try to do that yourself, even with a team... then you will appreciate how > awesome it is. > … Not sure why this thread is on Coccoa either. I'm probably a more casual user of Xcode than most of you guys. However, I haven't had any problems with Xcode 4.3. As far as I can remember 4.3 has never crashed -- whereas older versions of Xcode 4 did crash. For example just moving files around in the Navigator caused a crash. Also sometimes you couldn't bring up Xcode from the dock. You had to quit and restart. But that doesn't happen in 4.3. I also really like the features of Xcode 4. It takes a little getting used to but it's great after that. Of course if you are having random crashes - not reproducible, that would be annoying. But I'm not seeing that. Jim Merkel ___ 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
textfield problem
hello. i have a problem with a text field that won't accept any input. the textfield is one of three on a panel that appears only when the input is needed. I activate the panel with this line:[app beginSheet:Sheet modalForWindow:mainWindow modalDelegate:self didEndSelector:NULL contextInfo:nil]; in IB, behavior is set to editable, state is enabled. i've tried deleting the textfield and replacing it with a new one, i've tried [textfield setEditable:YES], but no joy. the textfield stubbornly refuses to accept any input. when i click it, nothing happens. when i double-click it, any existing characters are highlighted in grey instead of blue, and if i type anything, that input goes to whatever was active before the double-click. i'm obviously doing something wrong, but i have no idea what. can anyone point me in the right direction? ___ 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: HELP!! Big problem with relationships and saving in iOS core data: RESOLVED
Hi all Thanks to all of you for your answers. Mark just found the source of my problem and I want to publish it since it may help some more people that have that kind of issues, even if I at the same time expose my ignorance of some basic knowledge but hey, that's learning. My Core Data objects have implementation classes. One of those class had a dealloc implemented and this guy was freeing a reference to a member of UIColor type. That was the source of the problem, all those errors on accessing a faulty object occured while deallocating it. And the real source as of why I was not able to spot it: Since all this occurs after all your code is done and because I didn't knew about the Break on exception On Throw... All this time spent of re-re-reading and solidifying code still did a lot of good :). Thanks again, and for all those Core Data apprentices out there, don't forget to always forget to implement dealloc ;). CD is doing a good job in housekeeping. Eric. On 2012-03-01, at 09:12, Eric Giguere wrote: > Hi all > I'm on the verge of loosing my sanity... I've been running after save bugs > and I'm now completely out of ideas, other than to drop Core Data. > > In my model, I have EntityA, wich has an 1-many relationship to EntityB, > which also have a 1-many relationship to EntityC. > Both relationship are bi-directionnal, and I'm using cascade delete from A to > C. > > The only object in that chain that seems to be deletable is EntityB. > As soon as I try to delete an object from EntityC (A -> B -> C), I get this > error: > Terminating app due to uncaught exception 'NSObjectInaccessibleException', > reason: 'CoreData could not fulfill a fault for > > I've been hitting this error for a long time now. I've read that it may be > because I may have a reference in my code to the object that get deleted. So > I cleaned up everything, nothing does. > So out of despair, I've created a small method in my main window that creates > a new tree of object (A contain 1 B, contains 1 C) and try to delete C. No > references anywhere here. > > If I try deleting the C object before saving the new stuff, I get this error: > Domain=NSCocoaErrorDomain Code=134030 "The operation couldn’t be completed. > (Cocoa error 134030.) > NSUnderlyingException = "Cannot update object that was never inserted."; > > And if I save, then delete then save again I get back to the > NSObjectInaccessibleException. > > > Anybody, please, if you have a pointer so that I could find and fix this > error... It does not make sense that such a library fails with such a trivial > case. > I must be doing something wrong, but I've re-re-re check everything and don't > see. > > I've played with the reverse relationship delete rules, made all of the > optional, put them to nil before saving, nothing does :( > > I really don't know what to do next. > > Thanks for any help! > > Eri > > > > > ___ > > 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/eric.giguere%40videotron.ca > > This email sent to eric.gigu...@videotron.ca Eric Giguere eric.gigu...@videotron.ca 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
iOS UI control type terminology/name question
Hi all. I'm currently reviewing some code I'm going to revamp and I'm afraid that my brain emptied out when I needed it most. I'm trying to remember the name of a type of control that is like a UITabBar, but allows the user to drag scroll the buttons to the left and the right to show additional items. Is there a name for such a thing or is this this just a custom yet unnamed UI View Controller? TIA, - Alex Zavatone ___ 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: Question on handling very large images
On Mar 2, 2012, at 11:05 AM, Marco Tabini wrote: > My first instinct is to use a memory-mapped file (e.g.: using NSMutableData) > to hold the data while I work on it, but I worry that it will be very slow > and that I'm missing a much simpler solution. I don’t think you can get around the need to swap pixels in and out of memory from ‘disk’. In general, mmap is a good way to do that because it’s optimized down to the kernel level. The problem is that if you do this in a naive way, with a single huge pixmap, you will have poor locality of reference. Once you get to 1024 RGBA pixels across, every scan-line will occupy its own memory page. So any operation that crosses lots of scan lines but only uses a small fraction of each one (like drawing a vertical line) may involve a lot of paging. The usual workaround to that is to instead break the image up into rectangular tiles, and store each as a separate pixmap. That way most localized graphics operations will only involve a fraction of the total number of tiles. (You can see Photoshop do this, if you run a slow operation or if it’s had to page part of the image out to disk.) I think this will also help with the GPU, because CoreGraphics likes to copy pixmaps to GPU memory so they can be rendered and manipulated faster. (That said, I am not a CoreGraphics guru, and I defer to a better answer from anyone who is.) —Jens 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: textfield problem
On Mar 2, 2012, at 1:35 PM, H. Miersch wrote: > i have a problem with a text field that won't accept any input. the textfield > is one of three on a panel that appears only when the input is needed. I > activate the panel with this line:[app beginSheet:Sheet > modalForWindow:mainWindow modalDelegate:self didEndSelector:NULL > contextInfo:nil]; > > in IB, behavior is set to editable, state is enabled. i've tried deleting the > textfield and replacing it with a new one, i've tried [textfield > setEditable:YES], but no joy. the textfield stubbornly refuses to accept any > input. when i click it, nothing happens. when i double-click it, any existing > characters are highlighted in grey instead of blue, and if i type anything, > that input goes to whatever was active before the double-click. i'm obviously > doing something wrong, but i have no idea what. can anyone point me in the > right direction? Do you have a value binding for the field? If so, is "Conditionally sets editable" checked? Keary Suska Esoteritech, Inc. "Demystifying technology for your home or business" ___ 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: textfield problem
On Mar 2, 2012, at 12:35 , H. Miersch wrote: > i have a problem with a text field that won't accept any input. the textfield > is one of three on a panel that appears only when the input is needed. I > activate the panel with this line:[app beginSheet:Sheet > modalForWindow:mainWindow modalDelegate:self didEndSelector:NULL > contextInfo:nil]; > > in IB, behavior is set to editable, state is enabled. i've tried deleting the > textfield and replacing it with a new one, i've tried [textfield > setEditable:YES], but no joy. the textfield stubbornly refuses to accept any > input. when i click it, nothing happens. when i double-click it, any existing > characters are highlighted in grey instead of blue, and if i type anything, > that input goes to whatever was active before the double-click. i'm obviously > doing something wrong, but i have no idea what. can anyone point me in the > right direction? Did you use a NSPanel for the sheet? Use a NSWindow instead, since NSPanels can have special first-responder behavior. ___ 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
