On 11 Dec 2013, at 16:01, Jens Alfke j...@mooseyard.com 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
On 11 Dec 2013, at 18:53, Steve Sisak sgs-li...@codewell.com wrote:
At 10:25 AM -0800 12/10/13, Seth Willits wrote:
On Dec 10, 2013, at 1:32 AM, Graham Cox graham@bigpond.com wrote:
But my situation is that I need to draw VECTOR objects up to 25,000% zoom
with no pixelization.
You're
On 12 Dec 2013, at 11:55, Uli Kusterer witness.of.teacht...@gmx.net wrote:
On 11 Dec 2013, at 18:53, Steve Sisak sgs-li...@codewell.com wrote:
At 10:25 AM -0800 12/10/13, Seth Willits wrote:
On Dec 10, 2013, at 1:32 AM, Graham Cox graham@bigpond.com wrote:
But my situation is that I need
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 witness.of.teacht...@gmx.net wrote:
On 11 Dec 2013, at 16:01, Jens Alfke
On 10 Dec 2013, at 7:39 pm, Kyle Sluder k...@ksluder.com 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.
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 11 Dec 2013, at 17:20, Graham Cox graham@bigpond.com wrote:
The documentation is sparse though SNIP...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
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 in C
On 11 Dec 2013, at 12:40 pm, Ken Thomases k...@codeweavers.com 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
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 probably
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 11 Dec 2013, at 13:10, Graham Cox graham@bigpond.com 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
At 10:25 AM -0800 12/10/13, Seth Willits wrote:
On Dec 10, 2013, at 1:32 AM, Graham Cox graham@bigpond.com 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
On Dec 11, 2013, at 9:53 AM, Steve Sisak sgs-li...@codewell.com 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 Dec 11, 2013, at 8:05 AM, Jeffrey Oleander jgo...@yahoo.com 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?!?
On 11 Dec 2013, at 22:43, Greg Parker gpar...@apple.com wrote:
On Dec 11, 2013, at 9:53 AM, Steve Sisak sgs-li...@codewell.com 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
Is there any way to zoom in just one dimension?
On Dec 11, 2013, at 6:05 PM, David Duncan david.dun...@apple.com wrote:
On Dec 11, 2013, at 8:05 AM, Jeffrey Oleander jgo...@yahoo.com wrote:
* (The posted snippet from sample code was as clear as mud to me. Why
powers of 4 (and -4) instead
On Dec 11, 2013, at 4:17 PM, Dave Fernandes dave.fernan...@utoronto.ca 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
On 9 Dec 2013, at 11:12 pm, Kyle Sluder k...@ksluder.com 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
On 10 Dec 2013, at 12:39 am, Seth Willits sli...@araelium.com 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
On 10 Dec 2013, at 09:32, Graham Cox graham@bigpond.com wrote:
On 9 Dec 2013, at 11:12 pm, Kyle Sluder k...@ksluder.com 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
On 10 Dec 2013, at 10:52 am, Mike Abdullah mabdul...@karelia.com 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
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 graham@bigpond.com wrote:
On 10 Dec 2013, at 10:52 am, Mike Abdullah mabdul...@karelia.com wrote:
Another option to consider is using
On Dec 10, 2013, at 2:47 AM, Kevin Meaney k...@yvs.eu.com 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
On Dec 10, 2013, at 1:32 AM, Graham Cox graham@bigpond.com 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
On Dec 10, 2013, at 10:25 AM, Seth Willits sli...@araelium.com 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
, 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 the tile
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
On 9 Dec 2013, at 5:01 pm, Mike Abdullah mabdul...@karelia.com 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
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 the tile width and
the bytesPerRow are not consistent with an image that has an exclusive
On Dec 9, 2013, at 7:47 AM, Graham Cox graham@bigpond.com 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
On Dec 9, 2013, at 8:36 AM, Jens Alfke j...@mooseyard.com wrote:
On Dec 9, 2013, at 7:47 AM, Graham Cox graham@bigpond.com 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,
On 9 Dec 2013, at 5:36 pm, Jens Alfke j...@mooseyard.com 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
On 9 Dec 2013, at 5:17 pm, Kevin Meaney k...@yvs.eu.com 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
On 9 Dec 2013, at 5:45 pm, David Duncan david.dun...@apple.com 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
On Dec 9, 2013, at 9:50 AM, Graham Cox graham@bigpond.com 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
On Dec 9, 2013, at 8:45 AM, David Duncan david.dun...@apple.com 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,
On Dec 9, 2013, at 8:50 AM, Graham Cox graham@bigpond.com wrote:
On 9 Dec 2013, at 5:45 pm, David Duncan david.dun...@apple.com 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
On Dec 9, 2013, at 9:23 AM, Kyle Sluder k...@ksluder.com wrote:
On Dec 9, 2013, at 8:50 AM, Graham Cox graham@bigpond.com wrote:
On 9 Dec 2013, at 5:45 pm, David Duncan david.dun...@apple.com wrote:
If you have a buffer to draw into, then you can easily slice that buffer to
use
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 is
On 9 Dec 2013, at 7:03 pm, Seth Willits sli...@araelium.com 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,
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 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 bottleneck in
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 space
On 7 Dec 2013, at 1:05 am, Roland King r...@rols.org 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,
On Dec 6, 2013, at 7:27, Graham Cox graham@bigpond.com wrote:
On 6 Dec 2013, at 11:26 am, Graham Cox graham@bigpond.com wrote:
NSBlockOperation* op = [NSBlockOperation
blockOperationWithBlock:^
{
On 4 Dec 2013, at 9:33 pm, Graham Cox graham@bigpond.com 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
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
On 6 Dec 2013, at 12:14 pm, Roland King r...@rols.org 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
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 that works
On 6 Dec 2013, at 11:26 am, Graham Cox graham@bigpond.com wrote:
NSBlockOperation* op = [NSBlockOperation
blockOperationWithBlock:^
{
CGContextClipToRect( ncx, tileRect );
Sent from my iPhone
On 2013/12/07, at 0:27, Graham Cox graham@bigpond.com wrote:
On 6 Dec 2013, at 11:26 am, Graham Cox graham@bigpond.com wrote:
NSBlockOperation* op = [NSBlockOperation
blockOperationWithBlock:^
{
On 6 Dec 2013, at 2:42 pm, Roland King r...@rols.org 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 not
On Dec 6, 2013, at 8:05 AM, dangerwillrobinsondan...@gmail.com wrote:
On 6 Dec 2013, at 11:26 am, Graham Cox graham@bigpond.com wrote:
NSBlockOperation* op = [NSBlockOperation
blockOperationWithBlock:^
{
CGContextClipToRect( ncx, tileRect
On Dec 6, 2013, at 9:24 AM, Seth Willits sli...@araelium.com wrote:
On Dec 6, 2013, at 8:05 AM, dangerwillrobinsondan...@gmail.com wrote:
On 6 Dec 2013, at 11:26 am, Graham Cox graham@bigpond.com wrote:
NSBlockOperation* op = [NSBlockOperation
blockOperationWithBlock:^
On Dec 6, 2013, at 7:27 AM, Graham Cox graham@bigpond.com wrote:
Is the value of tileRect 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
On 6 Dec 2013, at 8:37 pm, Jens Alfke j...@mooseyard.com 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
On 7 Dec, 2013, at 12:46 am, Graham Cox graham@bigpond.com wrote:
@synchronized( self )
{
CGContextDrawImage( ctx,
tileRect,
On Dec 6, 2013, at 11:37 AM, Jens Alfke j...@mooseyard.com wrote:
On Dec 6, 2013, at 7:27 AM, Graham Cox graham@bigpond.com wrote:
Is the value of tileRect 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
On Dec 6, 2013, at 6:05 PM, Roland King wrote:
On 7 Dec, 2013, at 12:46 am, Graham Cox graham@bigpond.com wrote:
@synchronized( self )
{
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 -
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 to
62 matches
Mail list logo
