I am definitely gonna go and try that right now. I'll have to install the Xcode Tools, but this is the solution to my biggest problem. I can deal with the minor drawing flaws and stuff in exchange for more screen real estate.
I wouldn't get too excited about it. I think it's not totally unlikely that Apple won't drop G3 support in Leopard.
That is easily the most confused sentence I've seen since middle school. Sorry, but that confused the heck out of me. It's like a triple negative.
Anyhow, you can probably hack support back in. Someone has 10.3 or 10.4 on a PM 8600. I think in some cases, Apple just doesn't have your computer on a list on the install CD/DVD, so all you'd have to do is rip the DVD, change the file to add your computer model (and remove one other model, as it counts the number of lines), and burn the image onto a new DVD, then install. If you lack a DVD-ROM drive on the iBook, you need to do TDM to install.
Wow, Chucker, that is really interesting. One DOES learn something new everyday on AppleInsider
In any case though resolution independence means a complete vector-based user interface. Along with the challenges of antialiasing on the fly all vector-based user interface elements. I don't think it will be in 10.5 though. 10.6 maybe...
I am definitely gonna go and try that right now. I'll have to install the Xcode Tools, but this is the solution to my biggest problem. I can deal with the minor drawing flaws and stuff in exchange for more screen real estate....
What's really interesting is you still running on 800x600
Wow, Chucker, that is really interesting. One DOES learn something new everyday on AppleInsider
In any case though resolution independence means a complete vector-based user interface. Along with the challenges of antialiasing on the fly all vector-based user interface elements. I don't think it will be in 10.5 though. 10.6 maybe...
Not the way Apple do it. They store bitmaps at various resolutions and scale up and down the nearest bitmap. This is because most GPUs can scale bitmaps incredibly quickly (for games) but not draw vectors quickly at all. It's a compromise but a good one.
I have a hopelessly outdated iBook that maxes out at 800x600, so this feature really interests me....
I wouldn't get too excited about it. I think it's not totally unlikely that Apple won't drop G3 support in Leopard. iLife06 refuses to install on my later G3 dual USB iBook although you can install the apps separately by unpacking their individual installers.
Support for older G3s and ancient GPUs is likely quite slim.
I'm using Quartz Debug, a developer utility that ships with Xcode Tools. It has a slider that lets you go from scale factor 0.5 all the way to 3.0. This change affects applications that launch afterwards; you cannot "live-change" this value. (Currently running applications will continue to use the previous scale factor.)
Didn't know it did it that well. I'mm definitely be running it at .75 or lower with the new Mac just to save space onscreen.
It would be using the Google Maps API which Google supplies so that any webpage or program that wants to can access image, coordinate, and tag data from Google Maps, can.
Yes, I realize that my poor little iBook is terribly old and clunky. But as a student, I don't have NEAR enough cash to shell out for a MacBook, much as I'd like to.
So any little thing helps, and this resoltuion independence is a pretty big thing.
Kasper you noob you made me come out of retirement to debunk your BS. I have bugs to fix and no time to spend cleaning up your trash.
Quote:
One of the rumored features is said to be OS-level integration of a geographical mapping technology, similar to Microsoft's Virtual Earth. In recent months, Microsoft has made several acquisitions aimed at bolstering its Virtual Earth division, including a buyout of Vexcel Corp.
According to sources, Apple has been working on a similar approach, but modeled after Google's Maps feature. The technology will presumably allow Leopard users to scour the globe through satellite imagery and whisk up driving directions on the drop of a dime.
Ok, "OS-level integration" can mean alot and can mean
OS APIs for driving directions + pictures
iApp for driving directions + pictures
Mac friendly App
Sherlock plug in for something else
So speaking as someone who knows more than all of you about google earth/virtual earth and all that stuff, I can say that there is no way that apple has the time/energy/desire to run some mapping web service and expose it as a Web API.
As for an iApp, Apple would have to compete with Google Earth for dock space because GE has a mac version that is probably 100x better than what Apple could whip up.
As for a Mac friendly app, there are basically five competetiors that Apple would have to deal with (in order of the ones you know)
Apple doesn't like doing things poorly and makes software that costs money, so they would have to actually make a product that was good. Apple would be competing against:
Google- bottomless cash and investors who think that GE will conquer the world and one day actually make money, but will throw money into the project anyways.
MS- bottomless cash and a bottomless desire to crush google and without a care for making money on virtual earth.
NASA- someone with federal backing (hence cash) and the open source community backing.
ESRI- the world leader in GIS and the only company who actually makes money with all this 3-D globe stuff.
France- a nation that has makes software to compete with google a matter of Gaulic pride and will throw money at the project in the theory that somehow it makes their tech sector more competetive.
Apple is going to hop into this market? I think not. Maybe at most they might integrate Google maps into sherlock better.
Not the way Apple do it. They store bitmaps at various resolutions and scale up and down the nearest bitmap. This is because most GPUs can scale bitmaps incredibly quickly (for games) but not draw vectors quickly at all. It's a compromise but a good one.
I would contend that true resolution-independence means vector-based. Apple would have to figure out a way to do it well and fast and antialiased well on-the-fly.
Yes, you could have pre-rendered bitmaps, but let's say I want really big icons, I'd have major pixelation eg. when you look at textures up close in 3D games.
Vector-based would mean unlimited scaling while maintaining high image quality.
If using pre-rendered bitmaps, how would Apple decide on the max resolution of an icon? 200x200? 600x600? Yes, perhaps a compromise of some sort may be worked out to get a *start* on something moving towards "resolution-independence"....
Not the way Apple do it. They store bitmaps at various resolutions and scale up and down the nearest bitmap. This is because most GPUs can scale bitmaps incredibly quickly (for games) but not draw vectors quickly at all. It's a compromise but a good one.
I would contend that true resolution-independence means vector-based. Apple would have to figure out a way to do it well and fast and antialiased well on-the-fly.
Yes, you could have pre-rendered bitmaps, but let's say I want really big icons, I'd have major pixelation eg. when you look at textures up close in 3D games.
Vector-based would mean unlimited scaling while maintaining high image quality.
If using pre-rendered bitmaps, how would Apple decide on the max resolution of an icon? 200x200? 600x600? Yes, perhaps a compromise of some sort may be worked out to get a *start* on something moving towards "resolution-independence"....
Yes...true resolution independence would need a fully vector-based GUI. But:
1. No computer today, tomorrow or in 4 years would be able to handle a full-fledged vector-based GUI. A few complex vector images can bring a Quad G5 to it's knees.
2. There's a limit to what the human eye can see. Beyond a certain pixel density, it would be almost stupid to try to pack more pixels inside a square inch. That said, even a 300 ppi screen would yield icons that are slightly smaller than an inch and half in size at 512x512...this is very reasonable...and considering that at 300 ppi, you'd barely see pixels unless your face was right up against the screen, I think it won't be until 15 years from today that we'll see any displays with denser pixels (if we haven't moved to some other means of display computer images such as 3D holograms and such.)
What if the UI *was* vector based, but each time you set the resolution it then pre-renders the UI elements as appropriate for the resolution.
Sort of on-the-fly caching so that you have the speed with pre-rendered bitmaps, but then you have the flexibility of having the vector elements as "templates" -- saves having to have loads of different bitmap resolution elements.
Use the vector "templates" and then pre-render to bitmaps as required during a resolution change... just an idea
A bit silly idea though, cause one would have to render tons of icons and stuff and then write it to disk.
[B]Yep! Obviously, not all applications respect the setting properly, and there's lots of weird drawing bugs, some caused by OS X and some caused by application-specific problems. But:
I'm using Quartz Debug, a developer utility that ships with Xcode Tools. It has a slider that lets you go from scale factor 0.5 all the way to 3.0. This change affects applications that launch afterwards; you cannot "live-change" this value. (Currently running applications will continue to use the previous scale factor.)
So, you can change the factor, then reboot or even just log out and back in, and? tada.
Yes, that's right. There's an awful lot of bugs with this right now, however (mainly in terms of how things are displayed; behaviour is mostly perfectly fine). It's not ready for prime time.
Fun hack to play around with but major drawing bugs.
Yep! Obviously, not all applications respect the setting properly, and there's lots of weird drawing bugs, some caused by OS X and some caused by application-specific problems. But:
I'm using Quartz Debug, a developer utility that ships with Xcode Tools. It has a slider that lets you go from scale factor 0.5 all the way to 3.0. This change affects applications that launch afterwards; you cannot "live-change" this value. (Currently running applications will continue to use the previous scale factor.)
So, you can change the factor, then reboot or even just log out and back in, and? tada.
Yes, that's right. There's an awful lot of bugs with this right now, however (mainly in terms of how things are displayed; behaviour is mostly perfectly fine). It's not ready for prime time.
Fun hack to play around with but major drawing bugs.
What if the UI *was* vector based, but each time you set the resolution it then pre-renders the UI elements as appropriate for the resolution.
Sort of on-the-fly caching so that you have the speed with pre-rendered bitmaps, but then you have the flexibility of having the vector elements as "templates" -- saves having to have loads of different bitmap resolution elements.
Use the vector "templates" and then pre-render to bitmaps as required during a resolution change... just an idea
A bit silly idea though, cause one would have to render tons of icons and stuff and then write it to disk.
Sounds like a decent idea on paper, but would you really put up with waiting .5 to 4 minutes everytime you change the resolution or dpi?
Building GPS/Mapping services into the OS is a great idea. Not to compete directly against Google Earth etc; but to push new innovations in the portable market.
If Apple integrates GPS into the Portable computers, the iPods and an iPhone; they can start developing features like a buddy-discovery service and start mapping and connecting 'people'. The iPod/iPhone would be able to function as a car navigation device and a discovery device for Audio/Text/Video communications.
I'm only scratching the surface here. It could be exploited in many ways the same as the motion sensor and integrated iSight.
Comments
I am definitely gonna go and try that right now. I'll have to install the Xcode Tools, but this is the solution to my biggest problem. I can deal with the minor drawing flaws and stuff in exchange for more screen real estate.
Thanks a TON!
Originally posted by aegisdesign
I wouldn't get too excited about it. I think it's not totally unlikely that Apple won't drop G3 support in Leopard.
That is easily the most confused sentence I've seen since middle school. Sorry, but that confused the heck out of me. It's like a triple negative.
Anyhow, you can probably hack support back in. Someone has 10.3 or 10.4 on a PM 8600. I think in some cases, Apple just doesn't have your computer on a list on the install CD/DVD, so all you'd have to do is rip the DVD, change the file to add your computer model (and remove one other model, as it counts the number of lines), and burn the image onto a new DVD, then install. If you lack a DVD-ROM drive on the iBook, you need to do TDM to install.
In any case though resolution independence means a complete vector-based user interface. Along with the challenges of antialiasing on the fly all vector-based user interface elements. I don't think it will be in 10.5 though. 10.6 maybe...
I am definitely gonna go and try that right now. I'll have to install the Xcode Tools, but this is the solution to my biggest problem. I can deal with the minor drawing flaws and stuff in exchange for more screen real estate....
What's really interesting is you still running on 800x600
Originally posted by sunilraman
Wow, Chucker, that is really interesting. One DOES learn something new everyday on AppleInsider
In any case though resolution independence means a complete vector-based user interface. Along with the challenges of antialiasing on the fly all vector-based user interface elements. I don't think it will be in 10.5 though. 10.6 maybe...
Not the way Apple do it. They store bitmaps at various resolutions and scale up and down the nearest bitmap. This is because most GPUs can scale bitmaps incredibly quickly (for games) but not draw vectors quickly at all. It's a compromise but a good one.
Originally posted by turnwrite
But wait, about this "resolution independence."
I have a hopelessly outdated iBook that maxes out at 800x600, so this feature really interests me....
I wouldn't get too excited about it. I think it's not totally unlikely that Apple won't drop G3 support in Leopard. iLife06 refuses to install on my later G3 dual USB iBook although you can install the apps separately by unpacking their individual installers.
Support for older G3s and ancient GPUs is likely quite slim.
Originally posted by Chucker
I'm using Quartz Debug, a developer utility that ships with Xcode Tools. It has a slider that lets you go from scale factor 0.5 all the way to 3.0. This change affects applications that launch afterwards; you cannot "live-change" this value. (Currently running applications will continue to use the previous scale factor.)
Didn't know it did it that well. I'mm definitely be running it at .75 or lower with the new Mac just to save space onscreen.
So any little thing helps, and this resoltuion independence is a pretty big thing.
One of the rumored features is said to be OS-level integration of a geographical mapping technology, similar to Microsoft's Virtual Earth. In recent months, Microsoft has made several acquisitions aimed at bolstering its Virtual Earth division, including a buyout of Vexcel Corp.
According to sources, Apple has been working on a similar approach, but modeled after Google's Maps feature. The technology will presumably allow Leopard users to scour the globe through satellite imagery and whisk up driving directions on the drop of a dime.
Ok, "OS-level integration" can mean alot and can mean
OS APIs for driving directions + pictures
iApp for driving directions + pictures
Mac friendly App
Sherlock plug in for something else
So speaking as someone who knows more than all of you about google earth/virtual earth and all that stuff, I can say that there is no way that apple has the time/energy/desire to run some mapping web service and expose it as a Web API.
As for an iApp, Apple would have to compete with Google Earth for dock space because GE has a mac version that is probably 100x better than what Apple could whip up.
As for a Mac friendly app, there are basically five competetiors that Apple would have to deal with (in order of the ones you know)
Google Earth
MS Virtual Earth
NASA's World Wind
ESRI's ArcGIS Explorer
France's Geoportal
Apple doesn't like doing things poorly and makes software that costs money, so they would have to actually make a product that was good. Apple would be competing against:
Google- bottomless cash and investors who think that GE will conquer the world and one day actually make money, but will throw money into the project anyways.
MS- bottomless cash and a bottomless desire to crush google and without a care for making money on virtual earth.
NASA- someone with federal backing (hence cash) and the open source community backing.
ESRI- the world leader in GIS and the only company who actually makes money with all this 3-D globe stuff.
France- a nation that has makes software to compete with google a matter of Gaulic pride and will throw money at the project in the theory that somehow it makes their tech sector more competetive.
Apple is going to hop into this market? I think not. Maybe at most they might integrate Google maps into sherlock better.
Not the way Apple do it. They store bitmaps at various resolutions and scale up and down the nearest bitmap. This is because most GPUs can scale bitmaps incredibly quickly (for games) but not draw vectors quickly at all. It's a compromise but a good one.
I would contend that true resolution-independence means vector-based. Apple would have to figure out a way to do it well and fast and antialiased well on-the-fly.
Yes, you could have pre-rendered bitmaps, but let's say I want really big icons, I'd have major pixelation eg. when you look at textures up close in 3D games.
Vector-based would mean unlimited scaling while maintaining high image quality.
If using pre-rendered bitmaps, how would Apple decide on the max resolution of an icon? 200x200? 600x600? Yes, perhaps a compromise of some sort may be worked out to get a *start* on something moving towards "resolution-independence"....
Quote:
Originally posted by aegisdesign
Not the way Apple do it. They store bitmaps at various resolutions and scale up and down the nearest bitmap. This is because most GPUs can scale bitmaps incredibly quickly (for games) but not draw vectors quickly at all. It's a compromise but a good one.
I would contend that true resolution-independence means vector-based. Apple would have to figure out a way to do it well and fast and antialiased well on-the-fly.
Yes, you could have pre-rendered bitmaps, but let's say I want really big icons, I'd have major pixelation eg. when you look at textures up close in 3D games.
Vector-based would mean unlimited scaling while maintaining high image quality.
If using pre-rendered bitmaps, how would Apple decide on the max resolution of an icon? 200x200? 600x600? Yes, perhaps a compromise of some sort may be worked out to get a *start* on something moving towards "resolution-independence"....
Yes...true resolution independence would need a fully vector-based GUI. But:
1. No computer today, tomorrow or in 4 years would be able to handle a full-fledged vector-based GUI. A few complex vector images can bring a Quad G5 to it's knees.
2. There's a limit to what the human eye can see. Beyond a certain pixel density, it would be almost stupid to try to pack more pixels inside a square inch. That said, even a 300 ppi screen would yield icons that are slightly smaller than an inch and half in size at 512x512...this is very reasonable...and considering that at 300 ppi, you'd barely see pixels unless your face was right up against the screen, I think it won't be until 15 years from today that we'll see any displays with denser pixels (if we haven't moved to some other means of display computer images such as 3D holograms and such.)
Sort of on-the-fly caching so that you have the speed with pre-rendered bitmaps, but then you have the flexibility of having the vector elements as "templates" -- saves having to have loads of different bitmap resolution elements.
Use the vector "templates" and then pre-render to bitmaps as required during a resolution change... just an idea
A bit silly idea though, cause one would have to render tons of icons and stuff and then write it to disk.
[B]Yep! Obviously, not all applications respect the setting properly, and there's lots of weird drawing bugs, some caused by OS X and some caused by application-specific problems. But:
I'm using Quartz Debug, a developer utility that ships with Xcode Tools. It has a slider that lets you go from scale factor 0.5 all the way to 3.0. This change affects applications that launch afterwards; you cannot "live-change" this value. (Currently running applications will continue to use the previous scale factor.)
So, you can change the factor, then reboot or even just log out and back in, and? tada.
Yes, that's right. There's an awful lot of bugs with this right now, however (mainly in terms of how things are displayed; behaviour is mostly perfectly fine). It's not ready for prime time.
Fun hack to play around with but major drawing bugs.
Thanks for the info though chucker
Yep! Obviously, not all applications respect the setting properly, and there's lots of weird drawing bugs, some caused by OS X and some caused by application-specific problems. But:
I'm using Quartz Debug, a developer utility that ships with Xcode Tools. It has a slider that lets you go from scale factor 0.5 all the way to 3.0. This change affects applications that launch afterwards; you cannot "live-change" this value. (Currently running applications will continue to use the previous scale factor.)
So, you can change the factor, then reboot or even just log out and back in, and? tada.
Yes, that's right. There's an awful lot of bugs with this right now, however (mainly in terms of how things are displayed; behaviour is mostly perfectly fine). It's not ready for prime time.
Fun hack to play around with but major drawing bugs.
Thanks for the info though chucker
Originally posted by sunilraman
What if the UI *was* vector based, but each time you set the resolution it then pre-renders the UI elements as appropriate for the resolution.
Sort of on-the-fly caching so that you have the speed with pre-rendered bitmaps, but then you have the flexibility of having the vector elements as "templates" -- saves having to have loads of different bitmap resolution elements.
Use the vector "templates" and then pre-render to bitmaps as required during a resolution change... just an idea
A bit silly idea though, cause one would have to render tons of icons and stuff and then write it to disk.
Sounds like a decent idea on paper, but would you really put up with waiting .5 to 4 minutes everytime you change the resolution or dpi?
If Apple integrates GPS into the Portable computers, the iPods and an iPhone; they can start developing features like a buddy-discovery service and start mapping and connecting 'people'. The iPod/iPhone would be able to function as a car navigation device and a discovery device for Audio/Text/Video communications.
I'm only scratching the surface here. It could be exploited in many ways the same as the motion sensor and integrated iSight.
Originally posted by akheron01
Sounds like a decent idea on paper, but would you really put up with waiting .5 to 4 minutes everytime you change the resolution or dpi?
Yeah, because I really do that regularly.
Originally posted by akheron01
Sounds like a decent idea on paper, but would you really put up with waiting .5 to 4 minutes everytime you change the resolution or dpi?
You'd do that, what, once a year?