Re: CABasicAnimation does not animate bounds.origin of a layer

[Steve Christensen via Cocoa-dev]

First guess would be not to explicitly set -anchorPosition. It defaults to 
(0.5, 0.5), which refers to the middle of the bounds, and transforms (like 
scaling) are applied relative to that position.


> On Sep 14, 2019, at 6:25 AM, Gabriel Zachmann via Cocoa-dev 
>  wrote:
> 
> Maybe, I haven't understood how the animation of the bounds property works,
> or the bounds property of a CALayer itself ,
> or I am making a stupid mistake.
> 
> Here is my code:
> 
>CALayer * imgLayer = [CALayer layer];
>imgLayer.contents= (__bridge id) imageRef;
>imgLayer.delegate= nil;
>imgLayer.opacity = 1.0;  
>imgLayer.anchorPoint  = CGPointMake( 0.0, 0.0 );
>imgLayer.zPosition   = -1.0;   
> 
>CABasicAnimation * anim = [CABasicAnimation animationWithKeyPath: 
> @"bounds"];
>anim.timingFunction = [CAMediaTimingFunction functionWithName: 
> kCAMediaTimingFunctionLinear];
>anim.duration  = 5;// sec
>anim.autoreverses  = YES;
>anim.repeatCount  = 100;  // = 
> forever
> 
>NSRect from_rect = NSMakeRect( 100.0, 100.0, 200.0, 200.0 );
>anim.fromValue= [NSValue valueWithRect: from_rect ];
>NSRect to_rect = NSMakeRect( 200.0, 200.0, 300.0, 300.0 );
>anim.toValue = [NSValue valueWithRect: to_rect ];
> 
>[imgLayer addAnimation: anim forKey: @"myBoundsAnim"];
> 
> 
> What I am seeing is that the image gets scaled (from  200 to 300 
> width/height) which is fine,
> but it always sits in the lower left corner of the screen (I am working under 
> macOS).
> 
> I want the lower left corner of the image to be animated , too.
> (Eventually, the animation will be a bit more complex, but for now I am just 
> trying to understand this.)
> 
> What am I missing? or going wrong?
> 
> I guess I could achieve the effect by animating the position property of the 
> layer,
> but I'd rather prefer to understand what is going on.
> I have also re-read the "Core Animation Basics" , but it doesn't explain the 
> meaning of bounds.origin.
> In the drawings, it's always (0,0).
> 
> Thanks a lot in advance for any insights.
> 
> Best regards, Gabriel

___

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

Swift -> Obj-C: return __kindof Something

[Steve Christensen via Cocoa-dev]

I’m working on an Obj-C app that got started a bunch of years ago and thought 
that I would start migrating some of the smaller pieces over to Swift.

Some existing Obj-C methods are of the form:

+ (nullable __kindof NSManagedObject) someFooThing;

Right now I have

class var someFooThing: NSManagedObject?

but that generates a bunch of warnings saying there are incompatible pointer 
type, so Obj-C callers will need to cast the result to the specific subclass 
type:

SonOfFoo sonOfFoo = (SonOfFoo)SonOfFoo.someFooThing;

which was what the original method handled automagically.

I tried the generics route but Xcode complains because it will be used in 
Obj-C. Obviously I can just go through and cast to clean up the warnings, but 
if there’s a nicer solution then I’d rather go that route.

I’ve been searching around this afternoon trying to see if anyone else has run 
across this. I haven’t found anything yet, but I don’t know if that’s due to 
poor search terms, or because someone more experienced with the process would 
say, “well, of course you can’t do that”. Any help?

Thanks,
Steve

___

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: Swift -> Obj-C: return __kindof Something

[Steve Christensen via Cocoa-dev]

Yep, I understand what it does. I’m trying to get the same class-or-subclass 
behavior during compilation. I’d looked at the stack overflow article earlier, 
so I’ll check out the Swift forum to see what’s there. Thanks.

> On Nov 11, 2019, at 4:43 PM, Quincey Morris 
>  wrote:
> 
>> On Nov 11, 2019, at 15:07 , Steve Christensen via Cocoa-dev 
>> mailto:cocoa-dev@lists.apple.com>> wrote:
>> 
>> Some existing Obj-C methods are of the form:
>> 
>>  + (nullable __kindof NSManagedObject) someFooThing;
>> 
>> Right now I have
>> 
>>  class var someFooThing: NSManagedObject?
> 
> AFAIK, “__kindof” only affects the ability to assign one Obj-C class pointer 
> to a variable of a different but compatible (kind of) type. It doesn’t change 
> the actual type of the variable, nor does it (again AFAIK) change the ability 
> to assign without errors in Swift. Also see here for some informative 
> discussion:
> 
>   https://stackoverflow.com/questions/31399208/ios-kindof-nsarray 
> <https://stackoverflow.com/questions/31399208/ios-kindof-nsarray>
> 
> I suggest you ask about this on forums.swift.org <http://forums.swift.org/>. 
> If there’s an alternative, someone there will know.

___

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: Is CGImage... thread-safe?

[Steve Christensen via Cocoa-dev]

> On May 27, 2020, at 3:03 PM, Steve Mills via Cocoa-dev 
>  wrote:
> 
>> I can't recall/reproduce, but it was definitely *inside* 
>> CGImageSourceCreateThumbnailAtIndex().
>> 
>> If there is no image a tinder 0, shouldn't it just return NULL gracefully?
> 
> We don’t know that. There are many routines that throw exceptions when the 
> index is out of bounds. You should be calling CGImageSourceGetCount first to 
> make sure there’s an image at 0.

Right. If you look at the docs 
,
 it says that the result is “A CGImage object. …”. It doesn’t say “A CGImage 
object or NULL. …”. That suggests that you need to provide a valid index.
___

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: Relieving memory pressure

[Steve Christensen via Cocoa-dev]

For slide shows that I’ve seen, they typically display each image for several 
seconds at a time. If that’s the case, why can’t you just load the next image 
from disk on a background queue while the current image is being displayed and 
not have to worry about memory usage needed to cache multiple images? (I am 
assuming that you’ll need to load each image once anyway.)

If caching is required—apologies if I missed the “why” in earlier comments—then 
have you looked at NSCache? From the docs:

The NSCache class incorporates various auto-eviction policies, which ensure 
that a cache doesn’t use too much of the system’s memory. If memory is needed 
by other applications, these policies remove some items from the cache, 
minimizing its memory footprint.


> On Jun 7, 2020, at 5:31 AM, Gabriel Zachmann via Cocoa-dev 
>  wrote:
> 
> Good question.
> 
> Well, some users want to feed my app with image files of 100 MB, even up to 
> 400 MB (mostly jpeg compressed).
> Those images have resolutions of over 8k, sometimes over 10k.
> 
> The slideshow app needs to be able to zoom into those images with at least a 
> factor 2x scaling.
> 
> So I figured that if someone has a 4k monitor, creating thumbnails with 8k 
> resolution maximum should be sufficient.
> 
> An 8k x 8k image needs at least 200 MB (1 byte per channel).
> I don't know how CGImage stores the uncompressed images internally,
> but my experience seems to indicate that it uses significantly more memory 
> than that.
> (maybe it uses two bytes per channel, or even floats, or there is some other 
> aux data)
> 
>> What do you need a 1GB thumbnail for? There is no screen that can display 
>> that. For a slideshow app you could scale your thumbnails at creation time 
>> to the users biggest screen pixel size, don’t you think?
>> 
>> Christos Konidaris

___

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: Points vs pixels in a bash script

[Steve Christensen via Cocoa-dev]

I don’t have an answer for your question, and I know that this doesn’t actually 
answer it below, but it may still provide some info to help you move forward.

The windowing system is always working in points from a coordinates point of 
view. So window.frame and view.frame are in points, not pixels. This allows 
drawing to be abstracted across screens that have different point scales 
(pixel-to-point size ratio). You specify everything in points and what that 
means when it’s time for the actual drawing to occur on a particular screen is 
handled for you.

I would suggest that you check out the NSScreen class, which provides 
properties such as the frame (in points) and backingScaleFactor (pixel-to-point 
ratio), as well as methods to convert between point- and pixel-based NSRects. 
Since it’s possible to, for example, have a 2x Retina display as the main 
screen and plug in an older 1x display, then move the window so it straddles 
the two screens, then there will not be a single scale value when calculating 
the number of pixels per point.

You can do things like iterate over all attached screens and find the largest 
backingScaleFactor, then use that to calculate the pixel size for an image, for 
example.


> On Jun 8, 2020, at 2:43 PM, Gabriel Zachmann via Cocoa-dev 
>  wrote:
> 
> I know this mailing list might not be the perfect fit for my question,
> but maybe someone has an idea.
> 
> I have a problem converting points (I think) to pixels in a bash script.
> I'd rather not write an extra C/Cocoa utility for that.
> 
> Using
>   system_profiler SPDisplaysDataType
> I can retrieve the size of a Mac's display in pixels. 
> 
> However, the command
> 
>   tell application "System Events" to get the size of every window of every 
> process
> 
> (which I execute from my bash script using osascript) apparently does NOT 
> return window sizes in pixels. I guess it's the strange "Apple points" units. 
> According to my experiments, on my MacBook Pro Retina, for instance, a 
> fullscreen app (e.g., Keynote presentation) has a window size of 1680 x 1050.
> By contrast, system_profiler reports 2880 x 1800.
> 
> So, the question is: how can I determine the screen size of a Mac from my 
> bash script in the same units like "System Events" uses? 
> Or, how can I determine the factor by which I have to convert pixels into 
> those other units?
> 
> 
> Many thanks in advance for any insights or hints.
> 
> Best regards, Gabriel

___

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: Retrieving the EXIF date/time from 250k images

[Steve Christensen via Cocoa-dev]

You mentioned creating and managing threads on your own, but that’s what 
NSOperationQueue —and the lower-level DispatchQueue— does. It also will be more 
efficient with thread management since it has an intimate understanding of the 
capabilities of the processor, etc., and will work to do the “right thing” on a 
per-device basis.

By leveraging NSOperationQueue and then keeping each of the queue operations 
focused on a single file then you’re not complicating the management of what to 
do next since most of that is handled for you. Let NSManagedObjectQueue do the 
heavy lifting (scheduling work) and focus on your part of the task (performing 
the work).

Steve

> On Aug 16, 2022, at 8:41 AM, Gabriel Zachmann  wrote:
> 
> That is a good idea.  Thanks a lot!
> 
> Maybe, I can turn this into more fine-grained, dynamic load balancing (or 
> latency hiding), as follows:
> create a number of threads (workers);
> as soon as a worker is finished with their "current" image, it gets the next 
> one (a piece of work) out of the list, processes it, and stores the iso_date 
> in the output array (dates_and_times).
> Both accesses to the pointer to the currently next piece of work, and the 
> output array would need to be made exclusive, of course.
> 
> Best regards, Gabriel

___

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: Retrieving the EXIF date/time from 250k images

[Steve Christensen via Cocoa-dev]

One way to speed it up is to do as much work as possible in parallel. One way 
—and this is just off the top of my head— is:

1. Create a NSOperationQueue, and add a single operation on that queue to 
manage the entire process. (This is because some parts of the process are 
synchronous and might take a while and you don’t want to block the UI thread.)

2. The operation would create another worker NSOperationQueue where operations 
are added that each process a single image file (the contents of your `for` 
loop).

3. The manager operation adds operations to the worker queue to process a 
reasonable chunk of the files (10? 50?) and then waits for those operations to 
complete. (NSOperationQueue has something like a “wait until done” method.) It 
then repeats until all the image files have been processed.

4. As each chunk completes, it can report status to the UI thread via a 
notification or some other means.

Unlike your synchronous implementation, below, the order of updates to that 
array is indeterminate. A way to fix it is to pre-populate it with as many 
placeholder items (NSDate.distantPast?) as are in imagefiles and then store 
iso_date at the same index as its corresponding filename. Another benefit is 
that there is a single memory allocation at the beginning rather than periodic 
resizes of the array (and copying the existing contents) as items are added.

And since all these items are running on different threads then you need to 
protect access to your dates_and_times array because modifying it is not 
thread-safe. One quick way is to create a NSLock and lock it around the array 
update:

[theLock lock];
dates_and_times[index] = iso_date;
[theLock unlock];

Anyway, another way to look at the process.

Steve


> On Aug 14, 2022, at 2:22 PM, Gabriel Zachmann via Cocoa-dev 
>  wrote:
> 
> I would like to collect the date/time stored in an EXIF tag in a bunch of 
> images.
> 
> I thought I could do so with the following procedure
> (some details and error checking omitted for sake of clarity):
> 
> 
>NSMutableArray * dates_and_times = [NSMutableArray arrayWithCapacity: 
> [imagefiles count]];
>CFDictionaryRef exif_dict;
>CFStringRef dateref = NULL;
>for ( NSString* filename in imagefiles )
>{
>NSURL * imgurl = [NSURL fileURLWithPath: filename isDirectory: NO];
> // escapes any chars that are not allowed in URLs (space, &, etc.)
>CGImageSourceRef image = CGImageSourceCreateWithURL( (__bridge 
> CFURLRef) imgurl, NULL );
>CFDictionaryRef fileProps = CGImageSourceCopyPropertiesAtIndex( image, 
> 0, NULL );
>bool success = CFDictionaryGetValueIfPresent( fileProps, 
> kCGImagePropertyExifDictionary, (const void **) & exif_dict );
>success = CFDictionaryGetValueIfPresent( exif_dict, 
> kCGImagePropertyExifDateTimeDigitized, (const void **) & dateref );
>NSString * date_str = [[NSString alloc] initWithString: (__bridge 
> NSString * _Nonnull)( dateref ) ];
>NSDate * iso_date = [isoDateFormatter_ dateFromString: date_str];
>if ( iso_date )
> [dates_and_times addObject: iso_date ];
>CFRelease( fileProps );
>}
> 
> 
> But, I get the impression, this code actually loads each and every image.
> On my Macbook, it takes 3m30s for 250k images (130GB).
> 
> So, the big question is: can it be done faster?
> 
> I know the EXIF tags are part of the image file, but I was hoping it might be 
> possible to load only those EXIF dictionaries.
> Or are the CGImage functions above already clever enough to implement this 
> idea?
> 
> 
> Best regards, Gab.

___

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: Auto-layout, Forcing a top-level view to hug its contents

[Steve Christensen via Cocoa-dev]

The view hierarchy doesn’t go through a layout pass until after it is added to 
a live view or window. At awakeFromNib time it’s still essentially a snapshot 
of the layout in the nib since it hasn’t yet been inserted into the “context” 
that will allow the layout engine to determine how big all the views actually 
need to be.

> On Nov 3, 2022, at 5:39 PM, Eyal Redler via Cocoa-dev 
>  wrote:
> 
> I have a view in a nib, the constraints are setup so that the view should 
> expand/contract to fit the contents and the nib is localized for several 
> languages. When I check the frame size of the view in awakeFromNib the size I 
> get is the same as the size set in the nib.
> I tried forcing the view to resize by calling layout but this didn't change 
> the frame size.
> Is there a way to force the view to resize, before putting it on the screen?
> 
> TIA
> 
> Eyal Redler
> 
> "If Uri Geller bends spoons with divine powers, then he's doing it the hard 
> way."
> --James Randi
> www.eyalredler.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: Auto-layout, Forcing a top-level view to hug its contents

[Steve Christensen via Cocoa-dev]

It should be fine if the view is offscreen as long as it’s part of the active 
view hierarchy. I would also suggest looking at the view controller 
viewDidLayoutSubviews() method to see if you could do what you want there.

> On Nov 4, 2022, at 9:25 PM, Sandor Szatmari  
> wrote:
> 
>> On Nov 4, 2022, at 23:05, Steve Christensen via Cocoa-dev 
>>  wrote:
>> 
>> The view hierarchy doesn’t go through a layout pass until after it is added 
>> to a live view or window. At awakeFromNib time it’s still essentially a 
>> snapshot of the layout in the nib since it hasn’t yet been inserted into the 
>> “context” that will allow the layout engine to determine how big all the 
>> views actually need to be.
> 
> Would an offscreen view or window allow it to be laid out and examine prior 
> to insertion in a live view/window?  Assuming this was necessary… of course.
> 
> 
> Sandor
> 
>>> On Nov 3, 2022, at 5:39 PM, Eyal Redler via Cocoa-dev 
>>>  wrote:
>>> 
>>> I have a view in a nib, the constraints are setup so that the view should 
>>> expand/contract to fit the contents and the nib is localized for several 
>>> languages. When I check the frame size of the view in awakeFromNib the size 
>>> I get is the same as the size set in the nib.
>>> I tried forcing the view to resize by calling layout but this didn't change 
>>> the frame size.
>>> Is there a way to force the view to resize, before putting it on the screen?
>>> 
>>> TIA
>>> 
>>> Eyal Redler
>>> 
>>> "If Uri Geller bends spoons with divine powers, then he's doing it the hard 
>>> way."
>>> --James Randi
>>> www.eyalredler.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