Re: Getting the best frame rate for NSView drawing
Re: Getting the best frame rate for NSView drawing
- Subject: Re: Getting the best frame rate for NSView drawing
- From: Per Bull Holmen <email@hidden>
- Date: Fri, 30 Mar 2012 13:21:07 +0200
Den 11:52 30. mars 2012 skrev email@hidden
<email@hidden> følgende:
>
> On 29 Mar 2012, at 18:04, Kyle Sluder wrote:
>
>> On Mar 29, 2012, at 5:12 AM, lbland <email@hidden> 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 (email@hidden)
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:
This email sent to email@hidden