In that case, it sounds like the Image Source code is leaving the file
open, which makes some sense for local files, although it's not
explicitly documented anywhere that I've noticed; if I recall correctly,
this also happens with the similarly-named QuickTime-based APIs.
To continue using CGI
Indeed, for me, this is related to file descriptors. While it's still
unclear to me exactly where the problem lies, some quick fiddling with
opening the files as NSData and creating images from those appears to
be bearing fruit. Thanks!
-j
On Fri, Aug 8, 2008 at 5:51 PM, Jean-Daniel Dupas
<[EMAIL
Le 8 août 08 à 20:56, Ken Ferry a écrit :
Hi James, Nicholas,
I still bet it's someone holding too many file descriptors open.
Nicholas, when you said this, "but I have forced the thumbnail
creation to have at most 10 files opened at the same time", what did
you mean? You can see what files
Hi James, Nicholas,
I still bet it's someone holding too many file descriptors open.
Nicholas, when you said this, "but I have forced the thumbnail
creation to have at most 10 files opened at the same time", what did
you mean? You can see what files your process has open using the
lsof command
As I mentioned in my case, the images load fine when running through
XCode, but not as a standalone binary. So, I guess the images
themselves are fine. As producing an isolated test case scenario is
going to be prohibitively difficult in my case, all I would like is a
way to detect this happening s
I'd also try opening all the image files in some Apple-related graphics
programs (e.g., Preview, QuickTime Player, etc.) in order to determine if it's
system-wide or some combination in your own application; of course, there are
other factors that would be involved in using these, but since Appl
Well, I can't speak for James, but I have forced the thumbnail
creation to have at most 10 files opened at the same time, and it
doesn't make a difference...
I could understand a memory allocation issue, if the app didn't take
roughly 100 megs of RAM.
And besides, I can see there's a differen
Off the top of my head, with a number of files being opened so high and
relatively close to the value you get from getrlimit with a parameter of
RLIMIT_NOFILE, I'd suggest checking to see if that's the problem.
>Hi Nicolas, David,
>
>I'm having the exact same problem. Loading collections of smal
Couldn't tell either of you why your having issues without seeing
code, and probably not even then, but this is probably worth a bug
report.
On Aug 6, 2008, at 1:52 PM, James Trankelson wrote:
I'm having the exact same problem. Loading collections of small images
(jpeg in my case).
On Tue,
Hi Nicolas, David,
I'm having the exact same problem. Loading collections of small images
(jpeg in my case).
The only slight difference for me is that if I run my application
under XCode (Debug build), I don't get any errors. All of the images
load fine. However, when I run the (Debug) binary, I'
David,
the images are GIFs, roughly 40KB each, 200x100 (or 100x200).
Nothing fancy.
On 05 Aug 2008, at 01:05, David Duncan wrote:
What types of images are you trying to load?
--
Zino
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Pleas
On Aug 4, 2008, at 3:58 PM, Nicolas Zinovieff wrote:
On 04 Aug 2008, at 18:54, David Duncan wrote:
How is CGImageSourceCreateWithURL failing with any error when its
return value is a CGImageSourceRef and not an OSStatus?
Well, it returns NULL, and prints in the console that it failed with
On 04 Aug 2008, at 18:54, David Duncan wrote:
How is CGImageSourceCreateWithURL failing with any error when its
return value is a CGImageSourceRef and not an OSStatus?
Well, it returns NULL, and prints in the console that it failed with
error -11... And that takes a very long time to retur
On Aug 4, 2008, at 4:00 AM, Nicolas Zinovieff wrote:
I have this app that constantly updates a series of thumbnails in
the background for a Cocoa view.
When I have less than, say, 40 items in there, there is no problem
at all.
If I add three times that many elements, CGImageSourceCreateWithUR
14 matches
Mail list logo