Re: NSWindow resizing hack?
Re: NSWindow resizing hack?
- Subject: Re: NSWindow resizing hack?
- From: Wade Tregaskis <email@hidden>
- Date: Tue, 10 Jun 2003 10:27:48 +1000
Anyone know why drawing on OS X is so painfully slow?
At a salty guess:
a) None of the details are hardware accelerated (e.g. you can't just
tell your graphics card to draw a "button", or any other high-level
interface widget). All your $300 graphics card is usually doing is
copying memory around.
b) Every still frame of the resize may reallocate more memory, which
may cause excessive swapping about of memory in VRAM and RAM.
Alternatively, a larger space may be allocated and reused, only being
reallocated when the object within it becomes too big. I'd imagine the
latter method is faster in most cases, but the risk of wasting memory
is probably too much for many coders to bear.
c) MacOS X's drawing system is very layered, and highly
event-orientated/'threaded', compared with Win32 or Classic MacOS.
Meaning, while it may have the same graphics "bandwidth", if I can use
the term here as a metaphor, it tends to have higher latencies -
clicking a button no longer necessarily executes the button's code
immediately. Instead, an event is shuffled through the various
mechanisms and layers, and then the resulting redraw shuffled through
more layers of views and contexts to actually get rendered to screen.
Classic MacOS users were too long spoilt by the luxuries of a
co-operative multitasking system (i.e. one which can focus on one task
devotedly, which is what most power users - video, graphics, audio etc
- really want).
Lastly, in response to your particular gripe - d) Ever drawn a 100
page-per-second flip book, in real time? :)
Wade Tregaskis
-- Sed quis custodiet ipsos custodes?
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.