This way you can find out the build date and time of various bits and pieces. (And the Darwin project that it came from!) It doesn't work for everything, but some it does for some rather significant pieces.
<strong>Are we going to make new threads for each build, now?
*sigh*
Well, I'll leave this open in case anyone actually has some noteworthy comments about 6C106.</strong><hr></blockquote>
Actually, there is a BIG difference today. 6C106 has been officially released to ALL seed key holders via connect.apple.com. This is the FIRST connect.apple.com release of Jaguar - WWDC is not on there, and nor is any other build, to generic seed key holders. A LOT of people have these seed keys (each paid adc acct gets 5 to give out) - so we will be seeing a lot of 6C106.
I don't have a seed key for Jaguar, but I'm hoping that someone could test a rather serious PDF bug for me (please!) -- it will not crash your system or cause any file corruption; it is a display issue only.
The PDF file is a few plots that have a bunch of dots in them. The problem is that when you zoom out, the dots -disappear- in Preview.app !! Now, I have to zoom out *twice* to make this happen and "Screenshot of the problem" is a TIFF file showing the plot after the dots have gone missing. Each little box in the screenshot is supposed to be chock full of blue dots.
If you try this, please include the OS X build number in your reply.
<strong>I don't have a seed key for Jaguar, but I'm hoping that someone could test a rather serious PDF bug for me (please!) -- it will not crash your system or cause any file corruption; it is a display issue only.
The PDF file is a few plots that have a bunch of dots in them. The problem is that when you zoom out, the dots -disappear- in Preview.app !! Now, I have to zoom out *twice* to make this happen and "Screenshot of the problem" is a TIFF file showing the plot after the dots have gone missing. Each little box in the screenshot is supposed to be chock full of blue dots.
If you try this, please include the OS X build number in your reply.</strong><hr></blockquote>
Hmmm. It looks like at some point your dots go below single pixel size, and are hairlined out of existence. If you need to scale this down for a paper, I'd suggest getting it to the smallest size you can that still shows the dots, producing a PNG file, (or GIF) and then scaling that down the rest of the way.
It may be that the original PDF producer made a bad decision in how to encode the dots.
Hmmm. It looks like at some point your dots go below single pixel size, and are hairlined out of existence. If you need to scale this down for a paper, I'd suggest getting it to the smallest size you can that still shows the dots, producing a PNG file, (or GIF) and then scaling that down the rest of the way.
It may be that the original PDF producer made a bad decision in how to encode the dots. </strong><hr></blockquote>
This does not happen in Acrobat Reader on XP. I think he has a valid gripe. I can still see the dots even at 8% of normal size.
An interesting thing about 6C106 that I hadn't noticed before... Finder window resizing is now slower than in 10.1.5!!!
YES!!!
I've hoped for this since 10.1 was released, and it looks like Apple finally removed the 10.1 hack of simply resizing a static image. Resizing in 10.2 is slightly more choppy than 10.1, but using the Quartz Debug app it is apparent that the window is being resized "honestly", instead of caching the desktop area to the right and down of the window. What this means, of course, is that the system itself is now fast enough to resize properly, and this is apparent in some other applications.
<strong>An interesting thing about 6C106 that I hadn't noticed before... Finder window resizing is now slower than in 10.1.5!!!
YES!!!
I've hoped for this since 10.1 was released, and it looks like Apple finally removed the 10.1 hack of simply resizing a static image. Resizing in 10.2 is slightly more choppy than 10.1, but using the Quartz Debug app it is apparent that the window is being resized "honestly", instead of caching the desktop area to the right and down of the window. What this means, of course, is that the system itself is now fast enough to resize properly, and this is apparent in some other applications.
I hope that makes sense...</strong><hr></blockquote>
I'm not at my 6C106 right now but doesn't iTunes 3 do live resizing?
<strong>Resizing in 10.2 is slightly more choppy than 10.1, but using the Quartz Debug app it is apparent that the window is being resized "honestly", instead of caching the desktop area to the right and down of the window. </strong><hr></blockquote>
Ok, I'll bite.
I agree that in itself the fact it isn't caching the window to resize it seems "a good thing". But why implement it until it can be done as fast as or faster than the current implementation - hack or no?
I assume I am not thinking of something important that can happen in a finder window because I personally don't rate the ability to watch a movie in the preview column while resizing the window very high on my list of needed features.
I would also assume that if it is included in the final release it will, once again, be at least as fast as current resizing(?) - a large part of the perceived slowness of X is in the finder and Aqua GUI...
What does this gain us in the short term? (long term means a cleaner finder of course - and acceptable speeds)
<strong>But why implement it until it can be done as fast as or faster than the current implementation - hack or no?</strong><hr></blockquote>
It just means (to me anyway) that Apple realized that their old solution was a hack, and has continued to work on the root problems instead of figuring that the previous solution was good enough. Apple has not always looked at things this way.
Now that's a major improvement. The html rendering is greatly improved as well. I think that my GeForce4 Ti now helps my CPU with all it's power. CPU doesn't need that much juice for graphic rendering as before(GeForce2mx) so everything is waaaay faster!
P.S. I bet that Jared doesn't know that Apple released the new build 6C107. Apparently, from now on, they will be releasing the new builds almost every day so we can expect that the GM will be around 6C125 or so..
Comments
*sigh*
Well, I'll leave this open in case anyone actually has some noteworthy comments about 6C106.
In the terminal, you can use 'what' to find development build information from a binary.
So, for instance, in 10.1.5:
% what /Developer/Applications/Project\\ Builder.app/Contents/MacOS/Project\\ Builder/Developer/Applications/Project\\ Builder.app/Contents/MacOS/Project\\ Builder
PROGRAM: Project_Builder PROJECT: pbxide-90 DEVELOPER: root BUILT: 04/03/02 19:09:38
This way you can find out the build date and time of various bits and pieces. (And the Darwin project that it came from!) It doesn't work for everything, but some it does for some rather significant pieces.
[ 07-23-2002: Message edited by: Kickaha ]</p>
<strong>Are we going to make new threads for each build, now?
*sigh*
Well, I'll leave this open in case anyone actually has some noteworthy comments about 6C106.</strong><hr></blockquote>
Actually, there is a BIG difference today. 6C106 has been officially released to ALL seed key holders via connect.apple.com. This is the FIRST connect.apple.com release of Jaguar - WWDC is not on there, and nor is any other build, to generic seed key holders. A LOT of people have these seed keys (each paid adc acct gets 5 to give out) - so we will be seeing a lot of 6C106.
It also came with a new developer tools release.
download these two files:
<a href="http://homepage.mac.com/troy_goodson/bugs/Picture 1.tiff" target="_blank">Screenshot of the problem</a>
<a href="http://homepage.mac.com/troy_goodson/bugs/ivp_conicUpd_posvel_err_eps.pdf" target="_blank">The offending PDF file</a>
The PDF file is a few plots that have a bunch of dots in them. The problem is that when you zoom out, the dots -disappear- in Preview.app !! Now, I have to zoom out *twice* to make this happen and "Screenshot of the problem" is a TIFF file showing the plot after the dots have gone missing. Each little box in the screenshot is supposed to be chock full of blue dots.
If you try this, please include the OS X build number in your reply.
<strong>I don't have a seed key for Jaguar, but I'm hoping that someone could test a rather serious PDF bug for me (please!) -- it will not crash your system or cause any file corruption; it is a display issue only.
download these two files:
<a href="http://homepage.mac.com/troy_goodson/bugs/Picture 1.tiff" target="_blank">Screenshot of the problem</a>
<a href="http://homepage.mac.com/troy_goodson/bugs/ivp_conicUpd_posvel_err_eps.pdf" target="_blank">The offending PDF file</a>
The PDF file is a few plots that have a bunch of dots in them. The problem is that when you zoom out, the dots -disappear- in Preview.app !! Now, I have to zoom out *twice* to make this happen and "Screenshot of the problem" is a TIFF file showing the plot after the dots have gone missing. Each little box in the screenshot is supposed to be chock full of blue dots.
If you try this, please include the OS X build number in your reply.</strong><hr></blockquote>
Hmmm. It looks like at some point your dots go below single pixel size, and are hairlined out of existence. If you need to scale this down for a paper, I'd suggest getting it to the smallest size you can that still shows the dots, producing a PNG file, (or GIF) and then scaling that down the rest of the way.
It may be that the original PDF producer made a bad decision in how to encode the dots.
<strong>Well... Jareed you look like "fool" of it! </strong><hr></blockquote>
I am sorry? If you think I am unknown_source, I am not
<strong>
Hmmm. It looks like at some point your dots go below single pixel size, and are hairlined out of existence. If you need to scale this down for a paper, I'd suggest getting it to the smallest size you can that still shows the dots, producing a PNG file, (or GIF) and then scaling that down the rest of the way.
It may be that the original PDF producer made a bad decision in how to encode the dots. </strong><hr></blockquote>
This does not happen in Acrobat Reader on XP. I think he has a valid gripe. I can still see the dots even at 8% of normal size.
YES!!!
I've hoped for this since 10.1 was released, and it looks like Apple finally removed the 10.1 hack of simply resizing a static image. Resizing in 10.2 is slightly more choppy than 10.1, but using the Quartz Debug app it is apparent that the window is being resized "honestly", instead of caching the desktop area to the right and down of the window. What this means, of course, is that the system itself is now fast enough to resize properly, and this is apparent in some other applications.
I hope that makes sense...
<strong>An interesting thing about 6C106 that I hadn't noticed before... Finder window resizing is now slower than in 10.1.5!!!
YES!!!
I've hoped for this since 10.1 was released, and it looks like Apple finally removed the 10.1 hack of simply resizing a static image. Resizing in 10.2 is slightly more choppy than 10.1, but using the Quartz Debug app it is apparent that the window is being resized "honestly", instead of caching the desktop area to the right and down of the window. What this means, of course, is that the system itself is now fast enough to resize properly, and this is apparent in some other applications.
I hope that makes sense...</strong><hr></blockquote>
I'm not at my 6C106 right now but doesn't iTunes 3 do live resizing?
<img src="confused.gif" border="0">
<strong>Yes it does... I'm not sure what you're implying though...
</strong><hr></blockquote>
It doesn't in 10.1.5 (at least not on my iBook).
[ 07-24-2002: Message edited by: JLL ]</p>
<strong>Resizing in 10.2 is slightly more choppy than 10.1, but using the Quartz Debug app it is apparent that the window is being resized "honestly", instead of caching the desktop area to the right and down of the window. </strong><hr></blockquote>
Ok, I'll bite.
I agree that in itself the fact it isn't caching the window to resize it seems "a good thing". But why implement it until it can be done as fast as or faster than the current implementation - hack or no?
I assume I am not thinking of something important that can happen in a finder window because I personally don't rate the ability to watch a movie in the preview column while resizing the window very high on my list of needed features.
I would also assume that if it is included in the final release it will, once again, be at least as fast as current resizing(?) - a large part of the perceived slowness of X is in the finder and Aqua GUI...
What does this gain us in the short term? (long term means a cleaner finder of course - and acceptable speeds)
Curious minds want to know...
<strong>
I'm not at my 6C106 right now but doesn't iTunes 3 do live resizing?</strong><hr></blockquote>
iTunes 3 does live resizing on G4s currently.
<strong>
iTunes 3 does live resizing on G4s currently.</strong><hr></blockquote>
OK that must be it
My 6C106 is a G4 (but a slow one).
<strong>But why implement it until it can be done as fast as or faster than the current implementation - hack or no?</strong><hr></blockquote>
It just means (to me anyway) that Apple realized that their old solution was a hack, and has continued to work on the root problems instead of figuring that the previous solution was good enough. Apple has not always looked at things this way.
Now that's a major improvement. The html rendering is greatly improved as well. I think that my GeForce4 Ti now helps my CPU with all it's power. CPU doesn't need that much juice for graphic rendering as before(GeForce2mx) so everything is waaaay faster!
P.S. I bet that Jared doesn't know that Apple released the new build 6C107. Apparently, from now on, they will be releasing the new builds almost every day so we can expect that the GM will be around 6C125 or so..
Note: This info is trustfull source as well.