Untar this XCode project directory into the same level
as the "src" directory, then build to generate an Intel
binary which runs great (so far -- call it "Beta").
Thanks Craig. I am happy to hear that building an Intel binary apparently
does not require any changes to the source code.
I will soon try build GrandPerspective using your project file on a friend's Mac
(still a PowerPC, but with a more recent version of OS X than mine). That way,
I hope to be able to release a first Universal Binary of the app (initially as beta)
soon.
Thanks,
Erwin
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Having played with the binary a little more after posting
this last night, it looks like I've actually found 2 issues
with the intel version, both of which seem a little odd:
The full color palette of 8 colors doesn't seem to be
being used -- only green and blue are getting allocated for
some reason. I need to spend a bit more time getting
familiar with the structure of the code to figure out where
it chooses a color to allocate to a file in order to debug
this -- I'm unfamiliar enough with obj-c that it's not
immediately obvious :)
When resizing the window, sometimes all the rectangles
"shear". Often they resize correctly to remain rectangular;
again it's not immediately obvious where the layout of file
rectangles within the window rectangle is done, but there's
clearly something not right in that code.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
So, turns out that changes are needed for Intel. I've
described them more fully in the "Feature requests" ticket
on Universal binaries. Summary:
The way colors were being poked into the raw bitmap doesn't
work so good on intel, since byte-ordering of the colors is
different. This is easily fixed by using bitmap methods to
set pixels to a particular NSColor instead of storing an
array of 32-bit color codes and poking them directly to
addresses in the bitmap (which just assumes too much about
how the bitmap is laid out in memory). Patchfile attached
which does this, plus cleans up one or two other warning
messages.
Caveat: this is the first Obj-C thing of any complexity I've
really looked at, so I could well be doing something which
is leaking memory all over the place. Worth having someone
else look over the code once just to make sure I'm not doing
something dumb. Works for me though :)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks for your patch. Much appreciated. There is still a problem with it
unfortunately, but first a few other comments (also in response to your more
detailed message with RFE 1410140).
1) The auto-release pools worked correctly as they were. The reason that you
got a problem with the color array that you allocated being nuked is that you
should have called "retain" directly after creating it, which prevents it from
being auto-released. The problem with auto-releasing only when the thread
terminates (as was done in your patch) is that all of the temporary objects
that are created during the drawing are only freed when the thread
terminates. The latter only happens when the window is closed, and many re-
drawings of the tree may have happened before that, so you unnecessarily
hang on to unneeded memory if you don't auto-release after each drawing
action.
2) I see you have a newer/better compiler than I do. I don't get any warnings
when I compile, but the fixes you made to make warnings disappear at your
end are all okay, and indeed improve the code.
3) Okay, on to the heart of the patch. Getting it to run properly on Intel
3a). Unfortunately, the setColor:atX:y: method you invoke on the bitmap was
only added in OS X 10.4. It doesn't exist in the version of OS X that I have
(10.3.9), so the patched code does not run on my machine. At the moment
GrandPerspective requires OS X 10.2, and for now I like to stick to that (or at
the very least, it should run on my own machine :-).
3b). If possible, I like to keep the drawing code as fast as possible. For that
reason I like the old drawing routines, which were more low level, better as I
think they should run noticeably faster. Would you mind comparing the
timings on your machine? The application is already logging the time it takes
to draw the tree. You can see these logs, for instance, when you build and run
in XCode. Would you mind running both the original code, and the code
modified by you to find out if there is a difference?
4) Given 3a) and 3b) I would like to try and see if there is a different way to
change the code so that it runs on Intel.
4a). I am attaching a patch, which I hope will solve the color issue. Would you
mind applying it to the original 0.93 code to see if it indeed works?
4b). You also reported a problem with "sheared" rectangles. I don't think the
above patch fixes that. Can you confirm that the problem still exists? I haven't
yet looked at the code to figure out what the cause is. If you could attach a
screenshot where it shows what goes wrong, that could be useful. Obviously,
feel free to have a go yourself.
Cheers,
Erwin
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
1) Good to know about that "retain" method. I thought there
likely was something like that which would work, but I
couldn't find anything in my quick scan of the docs, plus at
least for the calculateGradientColors function, there no
longer were any temporary objects (since I stick all the
NSColors into the array which survives anyway), so that
wasn't an issue. And I figured "Well, how many temporary
objects can there be per directory scan" for the thread
thing. But your way is clearly the right way to do it.
Presumably you need to retain each of the NSColors as well
as the NSArray?
2) There are a bunch of other warnings which I didn't fix --
mostly unused parameters in function prototypes, the fact
that y0 is a symbol defined in math.h which we're therefore
shadowing, and a handful of "control reaches end of non-void
function"s where you have a contructor which just asserts
something which is always false (ie it'll throw an exception
and never reach the end of the constructor anyway, but the
compiler can't tell that about NSAssert). Nothing that
reaches the level of "ought to be fixed" in the way that the
added [super release] calls looked like they ought to be fixed.
3) I'm guessing that when Apple did 10.4 they said "Hmm,
with these bitmaps, we need to provide a cross-platform way
of drawing on a bitmap which takes care of endian stuff for
you". Timings:
For both versions below, I'm scanning my home directory;
248,075 files spread across a tree of 10,785 subdirectories.
For both cases, I launched the app and chose the home
directory, then after initial drawing, I clicked
cmd-maximize to make the window redraw full-screen size. [craig@Pookah:~]$ time find . -type f | wc -l
248077
real 0m12.421s
user 0m1.064s
sys 0m3.616s
First, PPC image from sf.net running under Rosetta
2006-05-03 13:28:43.955 GrandPerspective[4422] Done
scanning. Total size=23807711483, Time taken=20.298965
2006-05-03 13:28:44.364 GrandPerspective[4422] Done drawing.
Time taken=0.343080
2006-05-03 13:28:48.580 GrandPerspective[4422] Done drawing.
Time taken=1.420453
So it take a bit longer to draw in large size, quite a bit
less time at "regular" size. But in all cases, the time
spent scanning the disk is the slow step. I bet that using
some higher-level drawing function than setting each pixel
individually in the bitmap when using the object method (ie
drawing lines at a time, or even I bet there's a "flood fill
shaded rectangle" somewhere in the API) would immediately
close the gap in the large-format drawing. At full screen,
I'm likely blowing up the L2 cache when using the object
method, but not when using the packed-array-of-32-bit colors
approach. One neat thing to notice is that Rosetta is
actually byte-swapping the bitmap pokes automagically.
That's pretty darned cool if you think about it.
4a) I thought of trying a simple byte-swapping solution like
that but didn't go that way, because it seemed like the
poke-pixels-into-the-bitmap solution was not likely the
right approach; that it was micro-optimizing a problem which
isn't the critical path time-wise in the application. And
that moving to an object-based drawing system might actually
end up being faster since it would make it easier to do
higher-level drawing (like the flood-filled shaded rectangle
type approach) which would let the apple graphics-drawing
library wizkids worry about how to optimize blitting pixels
onto the screen. I'll test your patch for sure, and let you
know though how it works out. I'll also take a look through
the APIs now that I've got the basic drawing stuff working,
and look for that "flood fill a shaded rectangle" function
which will I think then blow 1.5s out of the water :) After
all, what is Quartz Extreme for if not to let you easily do
"flood fill a shaded rectangle"? Heck, if I have to split
the rectangles into 2 triangles, that'll work fine too.
4b) The sheared rectangles thing seems to have gone away --
not sure if it's because of the loop rewrite, or due to
pointer arithmetic issues between PPC vs Intel when
traversing the bitmap and/or color palette memory, but with
my new loop code and the setColorAt stuff, it's just gone
away. I'll see if it returns with your
byte-swap-the-color-array patch; if so it's probably because
pointer arithmetic doesn't necessarily port cleanly from CPU
architecture to CPU architecture. In any case, moving to a
"flood fill shaded rectangle" solution would obviate this
issue too :)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
1) When you add objects to an NSArray, the array "retains" them, so there is
no need to retain the NSColors before putting them in the array (it would in
fact be a memory leak).
2) I agree, fixing the code to remove the remaining warnings does not really
improve the code. On the other hand, it is nice to be able to compile without
warnings (so that serious ones do catch your attention immediately).
However, as the warnings don't appear when I compile, I keep things as they
are for now.
3) Even though the time scanning (typically) takes much longer than the
drawing, I still think it is important to optimise the drawing code as well. The
reason is that interactive exploration of the tree map (going up and down the
tree) involves repeated redrawing of the tree. As this is interactive, it does
make a difference if it takes a second or half a second. By the way, timings on
my machine are as follows (different contents of the disk, so cannot directly
compare obviously):
2006-05-03 23:21:12.333 GrandPerspective[3889] Done scanning. Total
size=21318728330, Time taken=90.005739
2006-05-03 23:21:12.814 GrandPerspective[3889] ScanProgressPanelControl
dealloc
2006-05-03 23:21:12.878 GrandPerspective[3889] Done drawing. Time
taken=0.233627
2006-05-03 23:21:19.607 GrandPerspective[3889] Done drawing. Time
taken=1.836518 [...]
2006-05-03 23:22:15.212 GrandPerspective[3889] Done drawing. Time
taken=0.478343 [...]
2006-05-03 23:24:03.767 GrandPerspective[3889] Done drawing. Time
taken=0.436518
The first and second are of the drawing of the default sized window and the
full-sized window respectively (similar to your timings). The third and fourth
timings are also for generating the full-size image of my entire harddrive. So
it's quicker the second and third time around. I'd guess because the
application has claimed enough memory from the OS by now.
4) Obviously, if there is a floodfill option in the API, that would be great.
However, I would be a bit surprised if there is something that resembles that
gradient drawing that is currently done. It would be nice though.
I'd be interested to hear if my patch at least fixes the colouring issue. Also,
let me know if the sheared rectangle problem persists. Then we can try to
attack the problem from opposite ends (you from the high-level API, and I'll
stick with the low level byte-poking for now).
Erwin
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Your patch fixes the color problem, but the shearing problem
is there. I suspect that it's something like the pointer
arithmetic while walking through the bitmap data buffer is
not quite right when you're using intel addressing instead
of PPC addressing. On the plus side, it blazes for speed
-- same directory as before, same normal size then maximize:
2006-05-03 20:35:38.367 GrandPerspective[5621] Done
scanning. Total size=23814880914, Time taken=19.773904
2006-05-03 20:35:38.475 GrandPerspective[5621] Done drawing.
Time taken=0.073623
2006-05-03 20:35:42.950 GrandPerspective[5621] Done drawing.
Time taken=0.146918
My flood-fill-shaded-rectangle code is gonna have to be
pretty good... (or at least not shear things)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Sounds about right. I didn't experiment enough to say 1/2
-- my brief observation was that it was more like 1/4, but
it might well be 1/2. Yes, it is the entire image.
Direction is / not \ -- I was thinking probably struct
alignment/packing or something like that.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I've attached a new patch, which hopefully fixes the colouring issue, as well
as the shearing problem. It's called UntestedUnivBinary2.patch. It should be
applied to the original 0.93 source code.
I would greatly appreciate it if you could give it a try, and let me know if it
works.
Cheers,
Erwin
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Oh, one thing which I forgot -- the "src" directory is
missing a couple of files: the icon, Credits.rtf, some
plists, and the English.proj subdirectory, iirc. I just
copied them out of the downloadable .app, but the project
file I attached originally references them and expects them
to be there.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Great to hear that after these patches GrandPerspective now appears to run
okay on Intel as well. Thanks for your help with this.
Soon I will try building a Universal Binary for GrandPerspective myself, on the
machine of a friend. If that all goes well the new release should run natively
on PPC as well as Intel. I am currently in the midst of adding a few new
features to the app, so I am not entirely sure when the version 0.94 will be
released, but it should be fairly soon.
I am now closing this issue. Should you, however, discover other problems
when running on Intel, just submit it as a new bug report.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
XCode project tarball.
Logged In: YES
user_id=803935
Thanks Craig. I am happy to hear that building an Intel binary apparently
does not require any changes to the source code.
I will soon try build GrandPerspective using your project file on a friend's Mac
(still a PowerPC, but with a more recent version of OS X than mine). That way,
I hope to be able to release a first Universal Binary of the app (initially as beta)
soon.
Thanks,
Erwin
Logged In: YES
user_id=9266
Having played with the binary a little more after posting
this last night, it looks like I've actually found 2 issues
with the intel version, both of which seem a little odd:
The full color palette of 8 colors doesn't seem to be
being used -- only green and blue are getting allocated for
some reason. I need to spend a bit more time getting
familiar with the structure of the code to figure out where
it chooses a color to allocate to a file in order to debug
this -- I'm unfamiliar enough with obj-c that it's not
immediately obvious :)
When resizing the window, sometimes all the rectangles
"shear". Often they resize correctly to remain rectangular;
again it's not immediately obvious where the layout of file
rectangles within the window rectangle is done, but there's
clearly something not right in that code.
Logged In: YES
user_id=9266
So, turns out that changes are needed for Intel. I've
described them more fully in the "Feature requests" ticket
on Universal binaries. Summary:
The way colors were being poked into the raw bitmap doesn't
work so good on intel, since byte-ordering of the colors is
different. This is easily fixed by using bitmap methods to
set pixels to a particular NSColor instead of storing an
array of 32-bit color codes and poking them directly to
addresses in the bitmap (which just assumes too much about
how the bitmap is laid out in memory). Patchfile attached
which does this, plus cleans up one or two other warning
messages.
Caveat: this is the first Obj-C thing of any complexity I've
really looked at, so I could well be doing something which
is leaking memory all over the place. Worth having someone
else look over the code once just to make sure I'm not doing
something dumb. Works for me though :)
Patchfile to fix problems with GrandPerspective for intel compatibility
Logged In: YES
user_id=803935
Hi Craig,
Thanks for your patch. Much appreciated. There is still a problem with it
unfortunately, but first a few other comments (also in response to your more
detailed message with RFE 1410140).
1) The auto-release pools worked correctly as they were. The reason that you
got a problem with the color array that you allocated being nuked is that you
should have called "retain" directly after creating it, which prevents it from
being auto-released. The problem with auto-releasing only when the thread
terminates (as was done in your patch) is that all of the temporary objects
that are created during the drawing are only freed when the thread
terminates. The latter only happens when the window is closed, and many re-
drawings of the tree may have happened before that, so you unnecessarily
hang on to unneeded memory if you don't auto-release after each drawing
action.
2) I see you have a newer/better compiler than I do. I don't get any warnings
when I compile, but the fixes you made to make warnings disappear at your
end are all okay, and indeed improve the code.
3) Okay, on to the heart of the patch. Getting it to run properly on Intel
3a). Unfortunately, the setColor:atX:y: method you invoke on the bitmap was
only added in OS X 10.4. It doesn't exist in the version of OS X that I have
(10.3.9), so the patched code does not run on my machine. At the moment
GrandPerspective requires OS X 10.2, and for now I like to stick to that (or at
the very least, it should run on my own machine :-).
3b). If possible, I like to keep the drawing code as fast as possible. For that
reason I like the old drawing routines, which were more low level, better as I
think they should run noticeably faster. Would you mind comparing the
timings on your machine? The application is already logging the time it takes
to draw the tree. You can see these logs, for instance, when you build and run
in XCode. Would you mind running both the original code, and the code
modified by you to find out if there is a difference?
4) Given 3a) and 3b) I would like to try and see if there is a different way to
change the code so that it runs on Intel.
4a). I am attaching a patch, which I hope will solve the color issue. Would you
mind applying it to the original 0.93 code to see if it indeed works?
4b). You also reported a problem with "sheared" rectangles. I don't think the
above patch fixes that. Can you confirm that the problem still exists? I haven't
yet looked at the code to figure out what the cause is. If you could attach a
screenshot where it shows what goes wrong, that could be useful. Obviously,
feel free to have a go yourself.
Cheers,
Erwin
Possibly fixes color problem (apply to 0.93)
Logged In: YES
user_id=9266
My numbering to match yours:
1) Good to know about that "retain" method. I thought there
likely was something like that which would work, but I
couldn't find anything in my quick scan of the docs, plus at
least for the calculateGradientColors function, there no
longer were any temporary objects (since I stick all the
NSColors into the array which survives anyway), so that
wasn't an issue. And I figured "Well, how many temporary
objects can there be per directory scan" for the thread
thing. But your way is clearly the right way to do it.
Presumably you need to retain each of the NSColors as well
as the NSArray?
2) There are a bunch of other warnings which I didn't fix --
mostly unused parameters in function prototypes, the fact
that y0 is a symbol defined in math.h which we're therefore
shadowing, and a handful of "control reaches end of non-void
function"s where you have a contructor which just asserts
something which is always false (ie it'll throw an exception
and never reach the end of the constructor anyway, but the
compiler can't tell that about NSAssert). Nothing that
reaches the level of "ought to be fixed" in the way that the
added [super release] calls looked like they ought to be fixed.
3) I'm guessing that when Apple did 10.4 they said "Hmm,
with these bitmaps, we need to provide a cross-platform way
of drawing on a bitmap which takes care of endian stuff for
you". Timings:
For both versions below, I'm scanning my home directory;
248,075 files spread across a tree of 10,785 subdirectories.
For both cases, I launched the app and chose the home
directory, then after initial drawing, I clicked
cmd-maximize to make the window redraw full-screen size.
[craig@Pookah:~]$ time find . -type f | wc -l
248077
real 0m12.421s
user 0m1.064s
sys 0m3.616s
First, PPC image from sf.net running under Rosetta
[craig@Pookah:~]$
/Volumes/GrandPerspective-0_93/GrandPerspective.app/Contents/MacOS/GrandPerspective
2006-05-03 13:27:52.772 GrandPerspective[4419] Done
scanning. Total size=23807715369, Time taken=27.079997
2006-05-03 13:27:53.435 GrandPerspective[4419] Done drawing.
Time taken=0.514033
2006-05-03 13:27:57.757 GrandPerspective[4419] Done drawing.
Time taken=1.067728
Repeat with my compiled Intel binary using object-based
bitmap drawing
[craig@Pookah:~]$
/Applications/GrandPerspective.app/Contents/MacOS/GrandPerspective
2006-05-03 13:28:43.955 GrandPerspective[4422] Done
scanning. Total size=23807711483, Time taken=20.298965
2006-05-03 13:28:44.364 GrandPerspective[4422] Done drawing.
Time taken=0.343080
2006-05-03 13:28:48.580 GrandPerspective[4422] Done drawing.
Time taken=1.420453
So it take a bit longer to draw in large size, quite a bit
less time at "regular" size. But in all cases, the time
spent scanning the disk is the slow step. I bet that using
some higher-level drawing function than setting each pixel
individually in the bitmap when using the object method (ie
drawing lines at a time, or even I bet there's a "flood fill
shaded rectangle" somewhere in the API) would immediately
close the gap in the large-format drawing. At full screen,
I'm likely blowing up the L2 cache when using the object
method, but not when using the packed-array-of-32-bit colors
approach. One neat thing to notice is that Rosetta is
actually byte-swapping the bitmap pokes automagically.
That's pretty darned cool if you think about it.
4a) I thought of trying a simple byte-swapping solution like
that but didn't go that way, because it seemed like the
poke-pixels-into-the-bitmap solution was not likely the
right approach; that it was micro-optimizing a problem which
isn't the critical path time-wise in the application. And
that moving to an object-based drawing system might actually
end up being faster since it would make it easier to do
higher-level drawing (like the flood-filled shaded rectangle
type approach) which would let the apple graphics-drawing
library wizkids worry about how to optimize blitting pixels
onto the screen. I'll test your patch for sure, and let you
know though how it works out. I'll also take a look through
the APIs now that I've got the basic drawing stuff working,
and look for that "flood fill a shaded rectangle" function
which will I think then blow 1.5s out of the water :) After
all, what is Quartz Extreme for if not to let you easily do
"flood fill a shaded rectangle"? Heck, if I have to split
the rectangles into 2 triangles, that'll work fine too.
4b) The sheared rectangles thing seems to have gone away --
not sure if it's because of the loop rewrite, or due to
pointer arithmetic issues between PPC vs Intel when
traversing the bitmap and/or color palette memory, but with
my new loop code and the setColorAt stuff, it's just gone
away. I'll see if it returns with your
byte-swap-the-color-array patch; if so it's probably because
pointer arithmetic doesn't necessarily port cleanly from CPU
architecture to CPU architecture. In any case, moving to a
"flood fill shaded rectangle" solution would obviate this
issue too :)
Logged In: YES
user_id=803935
Hi Craig,
Still keeping the same numbering.
1) When you add objects to an NSArray, the array "retains" them, so there is
no need to retain the NSColors before putting them in the array (it would in
fact be a memory leak).
2) I agree, fixing the code to remove the remaining warnings does not really
improve the code. On the other hand, it is nice to be able to compile without
warnings (so that serious ones do catch your attention immediately).
However, as the warnings don't appear when I compile, I keep things as they
are for now.
3) Even though the time scanning (typically) takes much longer than the
drawing, I still think it is important to optimise the drawing code as well. The
reason is that interactive exploration of the tree map (going up and down the
tree) involves repeated redrawing of the tree. As this is interactive, it does
make a difference if it takes a second or half a second. By the way, timings on
my machine are as follows (different contents of the disk, so cannot directly
compare obviously):
2006-05-03 23:21:12.333 GrandPerspective[3889] Done scanning. Total
size=21318728330, Time taken=90.005739
2006-05-03 23:21:12.814 GrandPerspective[3889] ScanProgressPanelControl
dealloc
2006-05-03 23:21:12.878 GrandPerspective[3889] Done drawing. Time
taken=0.233627
2006-05-03 23:21:19.607 GrandPerspective[3889] Done drawing. Time
taken=1.836518
[...]
2006-05-03 23:22:15.212 GrandPerspective[3889] Done drawing. Time
taken=0.478343
[...]
2006-05-03 23:24:03.767 GrandPerspective[3889] Done drawing. Time
taken=0.436518
The first and second are of the drawing of the default sized window and the
full-sized window respectively (similar to your timings). The third and fourth
timings are also for generating the full-size image of my entire harddrive. So
it's quicker the second and third time around. I'd guess because the
application has claimed enough memory from the OS by now.
4) Obviously, if there is a floodfill option in the API, that would be great.
However, I would be a bit surprised if there is something that resembles that
gradient drawing that is currently done. It would be nice though.
I'd be interested to hear if my patch at least fixes the colouring issue. Also,
let me know if the sheared rectangle problem persists. Then we can try to
attack the problem from opposite ends (you from the high-level API, and I'll
stick with the low level byte-poking for now).
Erwin
Logged In: YES
user_id=9266
Your patch fixes the color problem, but the shearing problem
is there. I suspect that it's something like the pointer
arithmetic while walking through the bitmap data buffer is
not quite right when you're using intel addressing instead
of PPC addressing. On the plus side, it blazes for speed
-- same directory as before, same normal size then maximize:
2006-05-03 20:35:38.367 GrandPerspective[5621] Done
scanning. Total size=23814880914, Time taken=19.773904
2006-05-03 20:35:38.475 GrandPerspective[5621] Done drawing.
Time taken=0.073623
2006-05-03 20:35:42.950 GrandPerspective[5621] Done drawing.
Time taken=0.146918
My flood-fill-shaded-rectangle code is gonna have to be
pretty good... (or at least not shear things)
Logged In: YES
user_id=803935
Hi Craig,
I think I know how to fix the shearing issue. Let me guess:
about half the time.
I will attach a simple patch later today, which I think should fix it.
Unfortunately, I don't have time for that just now. Must dash....
Logged In: YES
user_id=9266
Sounds about right. I didn't experiment enough to say 1/2
-- my brief observation was that it was more like 1/4, but
it might well be 1/2. Yes, it is the entire image.
Direction is / not \ -- I was thinking probably struct
alignment/packing or something like that.
Possibly fixes color and shearing problem (apply to 0.93)
Logged In: YES
user_id=803935
Hi Craig,
I've attached a new patch, which hopefully fixes the colouring issue, as well
as the shearing problem. It's called UntestedUnivBinary2.patch. It should be
applied to the original 0.93 source code.
I would greatly appreciate it if you could give it a try, and let me know if it
works.
Cheers,
Erwin
Logged In: YES
user_id=9266
Yup, works great now:
2006-05-05 11:26:28.036 GrandPerspective[9862] Done
scanning. Total size=23761298528, Time taken=25.508179
2006-05-05 11:26:28.223 GrandPerspective[9862] Done drawing.
Time taken=0.082571
2006-05-05 11:26:38.925 GrandPerspective[9862] Done drawing.
Time taken=0.127371
Logged In: YES
user_id=9266
Oh, one thing which I forgot -- the "src" directory is
missing a couple of files: the icon, Credits.rtf, some
plists, and the English.proj subdirectory, iirc. I just
copied them out of the downloadable .app, but the project
file I attached originally references them and expects them
to be there.
Logged In: YES
user_id=803935
Hi Craig,
Great to hear that after these patches GrandPerspective now appears to run
okay on Intel as well. Thanks for your help with this.
Soon I will try building a Universal Binary for GrandPerspective myself, on the
machine of a friend. If that all goes well the new release should run natively
on PPC as well as Intel. I am currently in the midst of adding a few new
features to the app, so I am not entirely sure when the version 0.94 will be
released, but it should be fairly soon.
I am now closing this issue. Should you, however, discover other problems
when running on Intel, just submit it as a new bug report.