On Jul 11, 2006, at 6:26 AM, dda wrote:
* Phil may not have/want to support Linux;
For the products that I develop (mostly consumer oriented), I don't
believe that there is any interest in Linux.
* Manipulating memory blocks is way faster than the RGBSurface;
* Reading/Writing MemoryBlock.Byte() is going to be much faster than
RGBSurface.Pixel() and RGB(x,y,z)
Exactly, although I have found that it is very fast to copy the
entire color into a MemoryBlock using the following line of code in
the loop:
m.ColorValue(f, 32) = r.Pixel(x, y)
What seems to be the most expensive is accessing Color.Red,
Color.Green, and Color.Blue and writing it to individual bytes in the
MemoryBlock. So if you don't mind your data interlaced, then the
above code works very well and fast: 0.06 seconds for a 512x512
picture compared to 0.36 seconds dumping each color part (i.e.
Color.Red) into the MemoryBlock (compiled PEF running on OS X 10.4.7
with a PowerBook 1.5 GHz).
The problem is that I would prefer to separate the channels since it
would make my calculations a lot easier and more efficient.
* Plus, of course, access to Apple's VecLib functions, which are
very fast.
Many reasons to do so. Just wish there would be an easier way to do
it.
That is something that I would like to get into at some time... even
using some of the CoreImage effects would be nice. The only issue is
that I would like to have my products cross-platform (Mac and
Windows) and so it would require me to do double the work.
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>
Search the archives of this list here:
<http://support.realsoftware.com/listarchives/lists.html>
