OK, OK, point taken.
I think I'll print that list (and Uli’s caveat) and hang it on the wall, right
next to the space I use for banging my head when struggling with Cocoa… :p
On 12 Dec 2013, at 18:46, Uli Kusterer wrote:
> On 11 Dec 2013, at 16:01, Jens Alfke wrote:
>> On Dec 11, 2013, at 4
On 12 Dec 2013, at 11:55, Uli Kusterer wrote:
> On 11 Dec 2013, at 18:53, Steve Sisak wrote:
>> At 10:25 AM -0800 12/10/13, Seth Willits wrote:
>>> On Dec 10, 2013, at 1:32 AM, Graham Cox wrote:
But my situation is that I need to draw VECTOR objects up to 25,000% zoom
with no pixeli
On 11 Dec 2013, at 18:53, Steve Sisak wrote:
> At 10:25 AM -0800 12/10/13, Seth Willits wrote:
>> On Dec 10, 2013, at 1:32 AM, Graham Cox wrote:
>> > But my situation is that I need to draw VECTOR objects up to 25,000% zoom
>> > with no pixelization.
>>
>> You're given a CGContext to draw into;
On 11 Dec 2013, at 16:01, Jens Alfke wrote:
> On Dec 11, 2013, at 4:39 AM, 2551 <2551p...@gmail.com> wrote:
>> It’s certainly seemed the case to me that I would have probably spent less
>> time just writing my own code from scratch than I spend trying to figure out
>> how half the methods I’m tr
On Dec 11, 2013, at 4:17 PM, Dave Fernandes wrote:
> Is there any way to zoom in just one dimension?
Not really. You could put a counter transform before drawing that eliminates
the opposite direction (and the aforementioned sample should show how to find
out the current zoom level) but thats
Is there any way to zoom in just one dimension?
On Dec 11, 2013, at 6:05 PM, David Duncan wrote:
> On Dec 11, 2013, at 8:05 AM, Jeffrey Oleander wrote:
>
>> * (The posted snippet from sample code was as clear as mud to me. Why
>> powers of 4 (and -4) instead of 5 when we're talking about 5 l
On 11 Dec 2013, at 22:43, Greg Parker wrote:
> On Dec 11, 2013, at 9:53 AM, Steve Sisak wrote:
>> Not to hijack the thread, but I'm just getting head into optimizing some
>> code which displays live preview for a number of JPEG streams simultaneously.
>>
>> Most implementations I've tried resu
On Dec 11, 2013, at 8:05 AM, Jeffrey Oleander wrote:
> * (The posted snippet from sample code was as clear as mud to me. Why powers
> of 4 (and -4) instead of 5 when we're talking about 5 levels of detail?
> 1/(2^2) - 2^2 = (1/4) - 4 means "...levelsOfDetail" should be set to 5?!? It
> needs
On Dec 11, 2013, at 9:53 AM, Steve Sisak wrote:
> Not to hijack the thread, but I'm just getting head into optimizing some code
> which displays live preview for a number of JPEG streams simultaneously.
>
> Most implementations I've tried result in being CPU bound in JPEG code on the
> main thr
At 10:25 AM -0800 12/10/13, Seth Willits wrote:
On Dec 10, 2013, at 1:32 AM, Graham Cox wrote:
> But my situation is that I need to draw VECTOR objects up to
25,000% zoom with no pixelization.
You're given a CGContext to draw into; What's the difference? The
tiled drawing is async, so if th
On 11 Dec 2013, at 13:10, Graham Cox wrote:
>
> On 11 Dec 2013, at 1:39 pm, 2551 <2551p...@gmail.com> wrote:
>
>> The commonality of this experience makes me wonder almost with everything I
>> try to do in Cocoa whether it really IS true as advertised that the
>> pre-written APIs make it eas
On 2013 Dec 11, at 10:01, Jens Alfke wrote:
On 2013 Dec 11, at 04:39, 2551 <2551p...@gmail.com> wrote:
Itâs certainly seemed the case to me that I would have probably
spent less time just writing my own code from scratch than I spend
trying to figure out how half the methods Iâm trying to
On Dec 11, 2013, at 4:39 AM, 2551 <2551p...@gmail.com> wrote:
> It’s certainly seemed the case to me that I would have probably spent less
> time just writing my own code from scratch than I spend trying to figure out
> how half the methods I’m trying to use should be implemented.
That’s prob
On 11 Dec 2013, at 12:40 pm, Ken Thomases wrote:
> By searching the docs for "levelsOfDetailBias", I found Apple's
> CALayerEssentials sample code. A section of the AppController.m sets these
> properties and has a comment which explains them fairly well:
Ah, thanks! That makes more sense an
On 11 Dec 2013, at 1:39 pm, 2551 <2551p...@gmail.com> wrote:
> The commonality of this experience makes me wonder almost with everything I
> try to do in Cocoa whether it really IS true as advertised that the
> pre-written APIs make it easier than writing your own raw code all the way
> down i
On 11 Dec 2013, at 17:20, Graham Cox wrote:
> The documentation is sparse though ...That’s my somewhat limited
> understanding, not particularly well-informed by the docs, but appears to
> work by experimentation.
The commonality of this experience makes me wonder almost with everything I try
On Dec 11, 2013, at 4:20 AM, Graham Cox wrote:
> The documentation is sparse though, I’m not quite sure what I should be using
> for -levelsOfDetail and -levelsOfDetailBias. It’s clear I do need to set
> these to something other than their defaults to get the behaviour I need,
> which is not to
On 10 Dec 2013, at 7:39 pm, Kyle Sluder wrote:
>> but more directly, by using CATiledLayer you don't have to handle the tiling
>> and threading yourself, and it avoids the final blit of your buffer into the
>> view because you're (presumably) drawing directly into the layer backing.
>
> Yup,
On Dec 10, 2013, at 10:25 AM, Seth Willits wrote:
>
> The idea is that by using it you push drawing commands into the ether which
> may end up being drawn on the GPU via QE (I don't know that anyone said that,
> but it's something that occurred to me, I'm just not sure on how that's done
> int
On Dec 10, 2013, at 1:32 AM, Graham Cox wrote:
>> Which is another reason to seriously consider CATiledLayer
>
> I”ll consider it, and revisit it…
>
> But my situation is that I need to draw VECTOR objects up to 25,000% zoom
> with no pixelization.
You're given a CGContext to draw into; What'
On Dec 10, 2013, at 2:47 AM, Kevin Meaney wrote:
> I'm probably teaching my grandmother to suck eggs by suggesting this. Have
> you looked at using CGLayers?
They're extremely heavy. You definitely don't want them around if performance
is a consideration.
--
Seth Willits
_
I'm probably teaching my grandmother to suck eggs by suggesting this. Have you
looked at using CGLayers?
Kevin
On 10 Dec 2013, at 10:08, Graham Cox wrote:
>
> On 10 Dec 2013, at 10:52 am, Mike Abdullah wrote:
>
>> Another option to consider is using CAShapeLayer to render individual
>> obj
On 10 Dec 2013, at 10:52 am, Mike Abdullah wrote:
> Another option to consider is using CAShapeLayer to render individual objects
> where reasonable. This should allow Core Animation to efficiently render such
> vectors without a dedicated backing store.
CAShapeLayers really don’t scale much
On 10 Dec 2013, at 09:32, Graham Cox wrote:
>
> On 9 Dec 2013, at 11:12 pm, Kyle Sluder wrote:
>
>> Which is another reason to seriously consider CATiledLayer
>
>
> I”ll consider it, and revisit it…
>
> But my situation is that I need to draw VECTOR objects up to 25,000% zoom
> with no pi
On 10 Dec 2013, at 12:39 am, Seth Willits wrote:
> 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 presu
On 9 Dec 2013, at 11:12 pm, Kyle Sluder wrote:
> Which is another reason to seriously consider CATiledLayer
I”ll consider it, and revisit it…
But my situation is that I need to draw VECTOR objects up to 25,000% zoom with
no pixelization. That means the CATileLayer needs to remain firmly “stu
>> 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 spac
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 bottl
>> 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
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
I
> 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
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 yo
> 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 sou
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
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,
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
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
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 clip
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
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 never
nly 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
> trie
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 buffe
t; 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
On Dec 6, 2013, at 7:27, Graham Cox wrote:
>
> On 6 Dec 2013, at 11:26 am, Graham Cox wrote:
>
>> NSBlockOperation* op = [NSBlockOperation
>> blockOperationWithBlock:^
>> {
>> CGContextClipToRect(
On 7 Dec 2013, at 1:05 am, Roland King wrote:
> And reminded of the comment about how hard block syntax can be to remember, I
> didn't make this page, I'm not a fan of the name, but it's awfully useful and
> I keep it bookmarked, I tinyURLed it to avoid tripping up swear checkers,
> http://t
On Dec 6, 2013, at 6:05 PM, Roland King wrote:
> On 7 Dec, 2013, at 12:46 am, Graham Cox wrote:
>
>>
>>
>> @synchronized( self )
>> {
>> CGContext
On Dec 6, 2013, at 11:37 AM, Jens Alfke wrote:
> On Dec 6, 2013, at 7:27 AM, Graham Cox wrote:
>> Is the value of here captured when the block is created,or when
>> it is run?
>
> It depends on whether tileRect is an instance variable.
> * If it isn’t (i.e. it’s local/static/global), it gets c
On 7 Dec, 2013, at 12:46 am, Graham Cox wrote:
>
>
> @synchronized( self )
> {
> CGContextDrawImage( ctx,
> tileRect, tileImage );
>
On 6 Dec 2013, at 8:37 pm, Jens Alfke wrote:
> It depends on whether tileRect is an instance variable.
It’s not
> (This is one of many reasons why I believe ivar names should be
> distinguished, e.g. by prefixing them with “_”. Their behavior is different
> enough from other variables that i
On Dec 6, 2013, at 7:27 AM, Graham Cox wrote:
> Is the value of here captured when the block is created,or when it
> is run?
It depends on whether tileRect is an instance variable.
* If it isn’t (i.e. it’s local/static/global), it gets captured when the block
is created.
* If it _is_ an ivar
On Dec 6, 2013, at 9:24 AM, Seth Willits wrote:
> On Dec 6, 2013, at 8:05 AM, dangerwillrobinsondan...@gmail.com wrote:
On 6 Dec 2013, at 11:26 am, Graham Cox wrote:
NSBlockOperation* op = [NSBlockOperation
blockOperationWithBlock:^
{
On Dec 6, 2013, at 8:05 AM, dangerwillrobinsondan...@gmail.com wrote:
>>> On 6 Dec 2013, at 11:26 am, Graham Cox wrote:
>>>
>>> NSBlockOperation* op = [NSBlockOperation
>>> blockOperationWithBlock:^
>>> {
>>> CGContextClipToRect( ncx, tileRect );
>>
On 6 Dec 2013, at 2:42 pm, Roland King wrote:
>
>>
>>> That might be another way, by the way, render to your own tiled small
>>> bitmaps on background threads then blit them into the real context.
>>
>> Yep, that was also on my list to try, but for top performance it would make
>> sense no
Sent from my iPhone
> On 2013/12/07, at 0:27, Graham Cox wrote:
>
>
>> On 6 Dec 2013, at 11:26 am, Graham Cox wrote:
>>
>>NSBlockOperation* op = [NSBlockOperation
>> blockOperationWithBlock:^
>>{
>>CGContextClipToRect( ncx, tileRect );
>>
On 6 Dec 2013, at 11:26 am, Graham Cox wrote:
> NSBlockOperation* op = [NSBlockOperation
> blockOperationWithBlock:^
> {
> CGContextClipToRect( ncx, tileRect );
>
>
>
>> That might be another way, by the way, render to your own tiled small
>> bitmaps on background threads then blit them into the real context.
>
> Yep, that was also on my list to try, but for top performance it would make
> sense not to do that if it can be avoided.
>
My WAG would be th
On 6 Dec 2013, at 12:14 pm, Roland King wrote:
> That's very ingenious. Not an OSX expert myself but it does bother me that
> you're not drawing into the context you are given but one you construct
> yourself from a piece of the window. That's not something I think iOS would
> even let you ge
That's very ingenious. Not an OSX expert myself but it does bother me that
you're not drawing into the context you are given but one you construct
yourself from a piece of the window. That's not something I think iOS would
even let you get at.
For a start does that work layer backed?
Is ther
On 4 Dec 2013, at 9:33 pm, Graham Cox wrote:
> But that leaves those annoying cases when you have the whole view to redraw.
> I wondered if it would be worth dividing up the view into rects and rendering
> each one on a separate thread. The problem seems to me to be that they’d all
> be drawi
On Wed, 4 Dec 2013 21:33:16 +0100, Graham Cox said:
>NSView has -setCanDrawConcurrently, which, when you also permit this at
>the window level, will handle its -drawRect refreshes on a background
>thread. I’ve been experimenting with this to see if it yields any
>worthwhile gains,
I looked into t
Another question of a general nature.
NSView has -setCanDrawConcurrently, which, when you also permit this at the
window level, will handle its -drawRect refreshes on a background thread. I’ve
been experimenting with this to see if it yields any worthwhile gains, but it
doesn’t appear so - ther
62 matches
Mail list logo
