> On 22 Jul 2016, at 14:40, Trygve Inda wrote:
>
>
>> With half an eye on performance, if you *do* strictly need a copy of the
>> bitmap, note that NSBitmapImageRep conforms to NSCopying. You don’t have to
>> turn it into a TIFF and back again.
>>
>> Also, you don’t even need an NSImage - the
> On 22 Jul 2016, at 5:00 PM, Roland King wrote:
>
> Since you need the data to persist for display whilst you write a new image
> that means there’s two separate buffers, there has to be
Not sure there HAS to be. Whether it’s the easiest approach is another matter.
If the thread building ima
>
>> On 22 Jul 2016, at 4:40 PM, Trygve Inda wrote:
>>
>>
>>> With half an eye on performance, if you *do* strictly need a copy of the
>>> bitmap, note that NSBitmapImageRep conforms to NSCopying. You don’t have to
>>> turn it into a TIFF and back again.
>>>
>>> Also, you don’t even need an NS
On Jul 22, 2016, at 00:08 , Graham Cox wrote:
>
> If the thread building images never goes faster than once per second, the
> time to draw the image is a fraction of that - I’m sure 60fps is achievable,
> so making the thread wait for the drawing to be done isn’t going to hold it
> up signific
> On 22 Jul 2016, at 5:30 PM, Quincey Morris
> wrote:
>
> On Jul 22, 2016, at 00:08 , Graham Cox wrote:
>>
>> If the thread building images never goes faster than once per second, the
>> time to draw the image is a fraction of that - I’m sure 60fps is achievable,
>> so making the thread wai
I have an app (macOS 11.6) which uses kCFStreamPropertySSLSettings.
When it gets some streams it will show a panel:
“MyApp wants to sign using key “something” in your keychain” / “Allow” “Deny”
When I click “Deny” the streams get NSOSStatusErrorDomain errSecAuthFailed.
Else (clicked “Allow”) the
Thank you all. I’ll start my research on how to find crash logs.
On Thu, Jul 21, 2016 at 10:30 AM, Roland King wrote:
>
> > On 21 Jul 2016, at 22:15, Steve Bird wrote:
> >
> >
> >> On Jul 21, 2016, at 10:05 AM, Eric E. Dolecki
> wrote:
> >>
> >> I believe that debug apps built directly to hard
>> This is how it works now, but we are running into a rare deadlock situation
>> where the main thread asks the worker thread to end (and waits until it does
>> so) while the worker thread is waiting for the image to be displayed.
>
> If the window has a imageRep property that is (atomic, copy)
>
>> On 22 Jul 2016, at 4:08 PM, Trygve Inda wrote:
>>
>> I don't think the second part will work because of my workflow:
>>
>> At Launch: Create pixel buffer that is 1000 x 1000 pixels
>>
>> Looping thread
>> 1. Fill pixel buffer with pixels based on some algorithm
>> 2. create an NSImage wit
> On 22 Jul 2016, at 11:53 PM, Trygve Inda wrote:
>
> How can I draw the NSImageRep directly into a window?
-[NSImageRep drawInRect:fromRect:operation:fraction:respectFlipped:hints:];
i.e. same as NSImage.
>
> Also, the main pixel buffer is updated slowly (it takes a long time to
> draw).
>> Currently it blocks at this point, but I need to avoid that.
>
> It’s not really clear why this needs to be avoided. The time to draw the
> pixels should be a few milliseconds, a small fraction of the time your thread
> needs to run, even at its fastest.
Because the main thread sometimes nee
Go to Window -> Devices -> View Device Logs
-Carl
> On Jul 22, 2016, at 4:17 AM, Charles Jenkins wrote:
>
> Thank you all. I’ll start my research on how to find crash logs.
>
> On Thu, Jul 21, 2016 at 10:30 AM, Roland King wrote:
>
>>
>>> On 21 Jul 2016, at 22:15, Steve Bird wrote:
>>>
>
> On Jul 22, 2016, at 7:45 AM, Trygve Inda wrote:
>
> Because the main thread sometimes needs to ask the worker threads to
> terminate. If it does this after performOnMainThread has been called by a
> worker thread, but before the main thread has processed it, then the main
> thread will block w
Or better yet, have the termination request come from a thread other than the
main thread.
> On Jul 22, 2016, at 9:38 AM, Alan Snyder wrote:
>
>
>> On Jul 22, 2016, at 7:45 AM, Trygve Inda wrote:
>>
>> Because the main thread sometimes needs to ask the worker threads to
>> terminate. If it d
Debug it some other way than with Xcode. Possibly you have a serious
bug, but running under the debugger alters something so that the bug
isn't stimulated.
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or mode
> On Jul 22, 2016, at 2:46 AM, Gerriet M. Denkmann wrote:
>
> When it gets some streams it will show a panel:
> “MyApp wants to sign using key “something” in your keychain” / “Allow” “Deny”
Presumably this app is either acting as an SSL server, or is sending SSL
clients. Either of those roles
> On 23 Jul 2016, at 12:45 AM, Trygve Inda wrote:
>
> Because the main thread sometimes needs to ask the worker threads to
> terminate. If it does this after performOnMainThread has been called by a
> worker thread, but before the main thread has processed it, then the main
> thread will block w
On Jul 22, 2016, at 19:29 , Graham Cox wrote:
>
> If the worker thread is waiting for -performOnMainThread to complete, it
> *cannot* possibly get a call from the main thread to terminate
I nodded agreement when I first read this, then “but wait!” …
Your logic seems flawed on two counts:
1. T
On Jul 22, 2016, at 9:29 PM, Graham Cox wrote:
>
>
>> On 23 Jul 2016, at 12:45 AM, Trygve Inda wrote:
>>
>> Because the main thread sometimes needs to ask the worker threads to
>> terminate. If it does this after performOnMainThread has been called by a
>> worker thread, but before the main th
> On Jul 22, 2016, at 19:29 , Graham Cox wrote:
>>
>> If the worker thread is waiting for -performOnMainThread to complete, it
>> *cannot* possibly get a call from the main thread to terminate
>
> I nodded agreement when I first read this, then “but wait!” …
>
> Your logic seems flawed on two c
20 matches
Mail list logo
