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, and normal drawing doesn’t need this call (this is testing in a >> ‘light’ view, but nevertheless, it makes the view very noticeably laggy). > > A few months ago I saw a great presentation given by Apple engineer Andy > Matuschak about the way rendering works on iOS, the whole pipeline all the > way from the app’s API calls to the pixels appearing onscreen. Its purpose > was to teach some intuition about what rendering techniques will perform > better than others. [This specific talk doesn’t seem to be online, but he has > a WWDC talk* that I think covers similar topics.] > > The big picture is that the actual rendering pipeline is > [your app] —> [graphics server process] —> [OpenGL] —> [GPU] —> [Screen] > and the earlier the graphics calls get converted into pixels, the less > efficient the drawing will be, because it’s more expensive to push pixmaps > through the pipeline than lists of drawing commands. > > 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 clipping rect beforehand so the drawing is limited to the tile your > thread is working on.
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. 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. > > —Jens > > * “Understanding UIKit Rendering”: > https://developer.apple.com/itunes/?destination=adc.apple.com.8270634034.08270634040.8367260927?i=1122536585 > _______________________________________________ > > 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/david.duncan%40apple.com > > This email sent to david.dun...@apple.com -- David Duncan _______________________________________________ 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
