Re: [OT] Quartz Extreme in developer previews?
Re: [OT] Quartz Extreme in developer previews?
- Subject: Re: [OT] Quartz Extreme in developer previews?
- From: Pierre-Olivier Latour <email@hidden>
- Date: Sat, 13 Jul 2002 20:11:25 +0200
>
Hopefully there will also be hardware support for sub-window operations.
>
For example compositing an image to a point, scrolling a rectangle in a
>
view with NSCopyBits etc. -- all these functions are done by the CPU
>
today (atleast it seems that way), and similar for the developer preview
>
I tested :-(
Of course, it is handled by the CPU. There's no way it can be handled by the
GPU unless the GPU is able to do everything Quartz does.
It's extremely complicated to have stuff partially hw accelerated in a
window. Because there will always be cases where it won't work (like putting
other views on top of it).
Take OpenGL for example. If you have an OpenGL scene being rendered in a
window, and you put another window on top of it. The shadow of the window
has to be drawn correctly on top of the OpenGL view. But the OpenGL view if
rendered in VRAM by the hw, while the shadow is drawn in software by the
CPU, in RAM. So you have to read from VRAM, composite with the shadow and
send back the result to VRAM. See how complicated it is? (However, in this
special case, QE will help).
Cocoa drawing with the NSView and Quartz seems to be extremely well designed
and reliable. As a consequence, it's not really optimized. If you start
optimizing, you will break compatibility.
I've seen some examples: selecting another row in a NSTableView redraw the
whole table instead of re-drawing only the unselected row and the selected
row. If all classes are like this one, it's no surprise Cocoa applications
are slow graphically and unresponsive on low configurations.
>
Take window resizing: an 800x600 window mostly contain a filled
>
background, either just white or a repeated bitmap. If the CPU needs to
>
erase the entire rectangle each time (the window change by a few pixels)
>
and copy it to the graphics card then it takes about 0.02 seconds for
>
each redraw. So definetely window resizing will benefit enourmously from
>
proper hardware usage.
No, because normally you don't have a blank window: you have a window with
graphics, text, buttons, sliders, etc... All of them have to be drawn in an
offscreen buffer in RAM, then sent to the VRAM. Erasing the buffer in VRAM
then draw directly to VRAM all the elements would be way slower (mostly
because reading from VRAM is really slow).
Window resizing would be extremely accelerated _if_ the graphic card was
able to do all this drawing directly in VRAM. Basically, you would only have
to transmit vector data over the PCI bus, not pixel data.
>
Unfortuntaely I cannot confirm that hardware is actually being used, as
>
I can get similar speeds to what I see on Jaguar, by just using the CPU.
If you can have a transparent terminal over the DVD player's window, then QE
is enabled.
>
FYI if I do a memcpy() directly from RAM to VRAM then I can copy 190
>
MB/s. If I instead redraw the contents of an NSView at 800x600 simply
>
using NSFillRect with a white colour and add a timer to repeat this 60
>
times pr. second (which amounts to erasing 109 MB/s) then my view
>
actually only gets redrawn ~40 times pr. second (and the number
>
increase/decrease if I change the size of my view).
That's totally normal: you are comparing 2 things completely different. You
will always be faster if you do your own drawing instead of using Cocoa's
API. That's why games never use OS graphic APIs.
Using memcopy is an extrem case where you have almost no overhead.
NSFillRect is a complicated routine with overhead that takes a NSColor,
converts it to ARGB components, fills the rectangle while applying the
current transformations of the Graphic context, compositing if necessary,
then clipping and so on. Using memcpy will not even allow you to do 0.01% of
these features.
It's like saying: "hey Word opens documents way slower than TextEdit!",
these are 2 different applications, one having way more features than the
other. So of course, opening a documents in Word is slower than in TextEdit.
_____________________________________________________________
Pierre-Olivier Latour email@hidden
Lausanne, Switzerland
http://www.pol-online.net
_______________________________________________
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.