Den 11:52 30. mars 2012 skrev jonat...@mugginsoft.com <jonat...@mugginsoft.com> følgende: > > On 29 Mar 2012, at 18:04, Kyle Sluder wrote: > >> On Mar 29, 2012, at 5:12 AM, lbland <lbl...@vvi.com> wrote: >> >>> ... look at the call stack. On the Mac fill most likely calls opengl in the >>> end as "Quartz GL" has gotten pretty good. >> >> Quartz GL is not enabled by default. >> >> Also, see this: >> http://cocoawithlove.com/2011/03/mac-quartzgl-2d-drawing-on-graphics.html >> > > This was interesting background. > It leaves me even more curious as to why the OP's NSImage cache > implementation performs so poorly. > > Regards
I haven't seen that implementation, but if the NSImage doesn't know that its buffers won't change, that probably would mean excessive transferring of data between the CPU and GPU. As I've said, I always use OpenGL if I need high performance drawing, and I have found that many approaches that you would think would make OpenGL able to just leave the pixel data on the graphics card, in fact doesn't. After some benchmarking, profiling and testing I've found that OpenGL's frame buffer objects (NOT pixel buffers), are the best approach to avoid transferring data to the GPU, and if no compositing operations are needed, the quickest way to draw the cached image is with glBlitFramebuffer. If you need to use higher level APIs, you need to use glDrawPixels (which is sloooow) to transfer the data from an offscreen NSGraphicsContext/CGContext into the frame buffer object, THEN draw onto the screen using glBlitFramebuffer. Using glDrawPixels directly to the screen, or making a display list to cache the glDrawPixels operation is slow. I have no idea why. I know this isn't much help if you want to use high-level APIs as the main technology, instead of OpenGL together with Cocoa drawing operations as "extra help". But the point is that you need to learn to use the various graphics profiling and optimization tools that comes with the developer package, to find out what ACTUALLY happens, and where the bottlenecks actually are. I believe those tools intended for OpenGL would be usable for QuartzGL too? I don't know. Often, approaches that logically would seem efficient, turn out to be slow. It's hard to find a uniform way of figuring out the most efficient solution for each type of problem, you need to get some diagnostics from the various profiling tools, and try out different solutions. Hopefully, at least, you won't have to implement different solutions for different video cards.... :-/ Per _______________________________________________ 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
