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 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 the drawing doesn't occur fast enough it'll scale >>> up the low-scale bitmap, but what's evil about that? It's like Apple or >>> Google maps. >> >> 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 thread with the 7 other cores idle. >> >> I've tried variants of NSImageView, CGImage and CIImage and all that's >> needed to render them on alternate threads but Cocoa appears to so good at >> delaying evaluation as long as possible that it seems to end up calling the >> JPEG decoder synchronously from -drawRect of whatever view subclass I've >> chosen on the main thread. >> >> Any suggestions for what technologies to use to run a JPEG through, say >> CIImage w/o blocking the main thread. >> >> This has turned out to be way more complicated than I thought. > > > If you want previews, I think ImageIO has dedicated methods for generating > previews (MacOS definitely has some somewhere, even if I mis-remember them > being in ImageIO). Particularly in the case of JPEG these can be much more > efficient because of the way JPEGs are stored. Essentially, JPEGs often > contain a few small DCTs at the start that can give you a vague, blurry > version of the image, then draw more DCTs on top to add in the detail (I'm > criminally simplifying here). So the preview calls can actually just draw the > blurry version into a smaller destination and stop there, and don't have to > calculate or even load the rest of the image. Yes, ImageIO has highly optimised routines for generating thumbnails. (Which seems a slight misnomer seeing as you can use them to pull out some seriously large images). By default, ImageIO holds off decoding JPEGs etc. until actually needed. iOS devs have run up against this for years, where the decoding kicks in on the main thread at the first draw, and gets in the way. The standard solution most seem to have arrived at is to first — on a worker thread — draw a single pixel of the image into a 1x1 pixel bitmap context. This forces the decoding to kick in, and is now cached ready for drawing on the main thread. As of 10.9, ImageIO adds the option: kCGImageSourceShouldCacheImmediately. Sadly this hasn’t made its way through to the full docs yet, but it should solve the problem you have without the need to faff about with a bitmap context in the background. If you use the thumbnail routines instead, in my experience they perform the decoding upfront for you anyway, so there’s no need for the workaround there. _______________________________________________ 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
