I have to agree with Aquatic. Here we are at 10.2 and soon to be at 10.3, yet still waiting while this modern OS resizes windows? This resize window snail is running out of excuses. All very interesting the reasons why it takes so long but these reasons are begging to show incompetence from those responsible for this area of the OS.
Quote:
Originally posted by Kickaha
I never said they shouldn't consider using another presentation approach.
What I said was that saying that unaccelerated complex 2D drawing, in real-time, with a dynamically changing bounding box, is ANY indication of the 'true speed' of the *OS* is just asinine.
You're welcome to your opinion regarding the resize speed, but that's just a blatant fallacy.
You should re-read his post, he said the slowness to resize a window makes it "feel" like OS X is slow. He is correct. However, by that he does not mean that OS X is slow.
Yeah, thank god for all those programs and other sh*t, otherwise this laptop would be totally useless.
Well, well... A computer without programs is a useless pile of hardware anyway. Be it fast or slow.
Back to the topic. Cocoa is a work in progress. In some aspects it offers developers the most general approach. Like with NSTableViews and NSCells. No one, I think, could make it more flexible in terms of power. This proved to have certain trade-offs like processing overhead. Cocoa devs are aware of the problem because window resizing and text rendering speed are often discussed on Apple's mailing lists in the harshest of words. They can improve it at least by optional caching of everything. Optional because if you cache every element separately, it will take much more memory, which, in turn, means more strain on the virtual memory subsystem, which leads to an overall system slow-down. Something like Windows. It starts up, launches first two apps and redraws windows instantly, but in an hour of work stalls completely, no longer being able to pay attention to the user.
Apple will improve every aspect of OS X guts. Ultimately. Just remember that Apple is a large company and its being large slows down some engineering decisions. We may get angry and feel offended as much as we want; to no avail. The best we can do is polite feedback. Just don't call them idiots because they don't call you so.
"I guess they just wanted to be cool like Windows."
It would be more accurate to say that they created Quartz, which is many times cooler than Windows, and will be copied by Windows in Longhorn. Live window resizing is HARD with current tech when you get all the bells and whistles we get with Quartz--it's ahead of its time. Leading, not following--and that can get you in trouble at times.
I can see Apple's side--they're fighting to make this work w/o graphic card support, and it shows. They WILL win, but I wonder at the cost--I'd much rather have a pref, even a hidden one, which could enable non-live resizing ala iTunes on slow machines a while back.
Gurus--is there any reason why that couldn't be done, as a practical matter?
I'd much rather have a pref, even a hidden one, which could enable non-live resizing ala iTunes on slow machines a while back.
Gurus--is there any reason why that couldn't be done, as a practical matter?
I'm not a guru, but I'll try If you mean to ask if it's possible to turn off live resizing, then, yes, it's possible. Practical? I think so. Elegant? I'm not sure since the most elegant thing is fast live resizing. Will it come officially from Apple? Hardly ever.
it seems to me that every program in OS X has slow 2d redraw from pro tools to archicad to iphoto.
Also it isnt just live window resizing that is a problem.
Yes. The above discussion implies that there are too many CPU-dependent things happening behind the scenes only to support a flexible graphic subsystem. As an example, I recall some early version of BBEdit for OS X, it was barely usable. And it's just a text editor.
Quote:
I dont know what the problem is but i would love to see and OS improvement (panther?) fix up all my other slow redraws applications.
I hope so, too.
Quote:
Maybe we need quartz hyper mega extreme super plus pro
I hate to have to use a 256 MB NVidia XXX card for working in Terminal. It's simply crazy. In fact, ATI Rage 128 Pro is a decent card for most needs. My iMac with it on-board is happy in OS 9, but almost helpless in OS X. I mean Finder, text processors and... <gasp> ...Photoshop 6.
They can improve it at least by optional caching of everything. Optional because if you cache every element separately, it will take much more memory, which, in turn, means more strain on the virtual memory subsystem, which leads to an overall system slow-down.
They could just cache the whole rendered table or rendered column. Cell operations are usually fast enough so I wouldn't cache things on a per cell basis. I don't think that the memory overhead would be too big either, also they can just turn it off if too little memory is installed.
Quote:
Originally posted by costique
Something like Windows. It starts up, launches first two apps and redraws windows instantly, but in an hour of work stalls completely, no longer being able to pay attention to the user.
Most caches have size limits so I don't see this problem. The caches would be LRU of course.
IElegant? I'm not sure since the most elegant thing is fast live resizing.
Yes, and the least elegant thing is terribly slow live resizing (and slow GUI elements in general) that you can't turn off. It perfectly shows Apple's incometence, makes users angry and keeps a lot of people from switching in the first place, be it from OS 9 or Windows, if the UI feels slow and clumsy, the machine is slow. No "World's fastest PC" or "megahertz myth" can help once you use OS X for a few seconds.
To be fair: Panther is finally quite fast with the exception of resizing.
I wonder, could not Apple use OpenGL to resolve definitely the resizing problems? For example, GLTerm has insane performance under Jaguar; and when you scroll, you just cannot separate your mouse arrow from the scroll bar. However, resizing its windows suffers like in any other application, simply since resizing is not handled by OpenGL. I don't know though if this is technically possible.
it seems to me that every program in OS X has slow 2d redraw from pro tools to archicad to iphoto.
Also it isnt just live window resizing that is a problem.
I dont know what the problem is but i would love to see and OS improvement (panther?) fix up all my other slow redraws applications
Maybe we need quartz hyper mega extreme super plus pro
This is excately what im thinking. The slowness of every program from simple jpg viewers to CAD applications and photoshop is the reason why i'm not shifting back to mac yet (I was hoping for the G5 to finally make it fast).
Its not rendering or calculation speeds thats the problem but simple tasks as open/save dialogs, color chooser, wireframe regeneration, scrolling, etc.
Windows is extremely fast at these thing, so it feels alot snappier to work with.
Can anyone explain what is the big difference between windows and mac os in this regard? MAC OS X is afterall a completely re-written OS and should therefore be sort of optimized (user interface wise) from the beginning?
it seems to me that every program in OS X has slow 2d redraw from pro tools to archicad to iphoto.
Also it isnt just live window resizing that is a problem.
One prominent (at least to me) example. Illustrator 10 is double buffered, courtesy Adobe. OSX provides double buffering system wide. Put the two together and you get screen redraw hell. Adobe knew about OSX and still released Illustrator with these performance issues. In fact, they are just getting around to supporting OTF in Illustrator despite the fact the fact that OTF is the MS-Adobe roll-your-own replacement (read betterer fasterer newerer) for Type1 fonts.
Before blaming Apple for all screen redraw issues, a polite email to your favorite app vendor may also be in order.
Its strange that the gripers (yeah you ) place most of the blame on quartz.
Quartz is not the bottleneck on window resizing.
Application specific layout calculations are pretty much
always to blame. With Cocoa apps, the heavyweight nature of
NSCell and NSView incur significant overhead. Also, Cocoa's
dirty region management architecture is unfinished and
doesn't even attempt to do its job. Yep, it is still a
place holder.
From my experience overriding cocoa classes to achieve
textured windows prior to 10.2:
One place where graphics (but not quartz) causes lag is the
lighting gradient found in brushed metal windows.
Fortunately, this is one area where quartz extreme can
intervene if it hasn't already. There are also the
translucent window and control bevels used in some brushed
metal apps. Open up iTunes and take a look at the edges of
the window. They aren't just a gray, they are the same
background texture that has been either lightened or
darkened. This is computationally intense. Yet, the lag
prize still goes to layout and rendering of window content,
something fairly unrelated to quartz.
I disagree...
I'm not an expert in these things, but programmer really seems to be. He has written quite a few interesting posts about this previously.
The problem is indeed quartz. Or rather, the problem is that quartz uses a complex rendering method called spline rendering which current graphics hardware simply cannot do.
MS Windows uses a simpler rendering method and all the rendering is done by the graphics card, thats why it's faster (as Kickaha pointed out earlier). QE manages to do SOME rendering in HW which is why moving windows is instantaneous for example, but it still can't do (because the hardware can't do it) everything it would need to do to make window resizing fast.
My guess is that apple once bet on graphics HW being advanced enough by now, then it didn't turn out that way. maybe ATI or nVidia promised them something and then plans changed. Or maybe apple thought this "bug" would be acceptable enough for users to live with untill the adequate HW finally appears. Cards like this are likely to appear soonish I hear. At least in the high end. Thats probably why apple considers it a waste to change quartz. It would be a fairly huge undertaking, after all.
I'm not an expert in these things, but programmer really seems to be. He has written quite a few interesting posts about this previously.
The problem is indeed quartz. Or rather, the problem is that quartz uses a complex rendering method called spline rendering
Well, splines (b-splines I suppose) certainly have absolutely nothing to do with what we are discussing here at all and if programmer has said something about this, then he's simply wrong, period. However, I doubt that he was talking about window resising when he mentioned splines.
I can't remember how many times I've responded to questions like this, but one thing is for sure:
UI lag is NOT, repeate NOT caused by objective-c runtime overhead. the statement that c is faster than c++ which is faster than Objective-c is a generalization at best, and just plain wrong at worst. reguardless, the amount of time spent on function call/method invocation overhead is a miniscule fraction of the time spent rendering the UI, which is the real culpret. The use of large bitmapped graphics and backing stores, and drawing widgets/text with the CPU over the system bus to main memory are the causes of the UI lethergy affliction OSX seems to have... there are things apple could do to improve the situation TODAY (ie yesterday), but it seems apple is uninterested in doing so (ie uninterested, because they sure as hell can't be unaware).
I'm amazed at the passionate anger this topic generates. I'm not denying that a problem exists for some people, be it from different hardware or simply different expectations, but damn, I certainly don't have any issues with window resizing.
I use both a dual 1.25 GHz Power Mac and an 800 MHz PowerBook, both running Jaguar. Right now, on my Power Mac, I've just resized a bunch of windows -- Finder, iTunes, Mozilla, IE, Safari -- and there just isn't any problem I see. By the time I let go of the mouse, everything's set and ready to go. When trying out resizing some web pages, I looked for pages with complicated layouts too, and even using IE, which is slowest at rendering in most cases, resizing worked well.
Do I just have insufficient expectations? Am I supposed to be expecting, nay, demanding, perfectly fluid, 60 frames-per-second animation of every resize? Is anything less than a new update for every pixel of mouse motion less than acceptable? Or is there some weird system-to-system variation where some users simply get much, much worse performance than I get?
Hell, I don't even remember being particularly bothered by any of the window resizing that I've done on my father's old 350 MHz iMac that's running Jaguar.
Yeah. Because of course new hardware will handle it well. They want to sell you new stuff. Planned obsolescence. They're like Reagan. Oh sure the original iMac is the perfect machine for OS X. Yup.
Not that I'm complaining about that: beige machines and early iMacs and iBooks should be dropped like bricks. This might help Apple make OS X work nice with newer and newish hardware. But if windows don't resize right WITHOUT HARDWARE on a system bought this year, there is something wrong with that. I do NOT care what it is. It's wrong. And it should be fixed or changed.
Quote:
All who are concerned about this issue should be sending Apple feedback. . .
Yes sir once again. I'll be writing. Hope everyone else who wants a faster interface does as well! Maybe Apple will listen to us before they ship Panther 10.3 GM. We are representative of a large group of people. You all may have gotten used to OS X being slow but new people, OS 9 and Windows users, at once say "I thought OS X was supposed to be awesome!!!!!!!!! Yeah right Macs suck." As soon as they see a second of lag. Would be switchers are unforgiving on things like this. Apple has listened to feedback before, to much success. And the Feedback process these days is excellent. Let's all right in. They still have a few months I presume until release.
You do realize of course, that unless you are willing to accept 'border-only' resize, ala 9, or 'fixed image cropping' resize with a final full redraw on mouse up, THIS WILL NOT HAPPEN.
It's about as useful as demanding that the new Beetle do 200mph with the existing engine.
This isn't a programming issue. This is a hardware issue. Until the graphics hardware can meet the demands of Quartz, **2D drawing such as window resizing will never be accelerated**. Period.
Them's the facts, sorry.
So write, yes. Write to let them know you really want to see them push ATI and nVidia like mad, to produce hardware to accelerate Quartz, because that's the only solution available.
Do I just have insufficient expectations? Am I supposed to be expecting, nay, demanding, perfectly fluid, 60 frames-per-second animation of every resize? Is anything less than a new update for every pixel of mouse motion less than acceptable? Or is there some weird system-to-system variation where some users simply get much, much worse performance than I get?
Ever seen IE resize a window on a PC?
It is not possible to move the cursor off of the resize handle.
Now when we talk about resizing, we are not saying that it really interferes that much with getting work done. It is just one of the very few areas of OS X that no matter how much horsepower Apple seems to throw at it, it still isn't as fast as the human hand dragging the mouse. Four gigahertz of CPU power, 1000 mHz frontside bus with aggregate 12 GB per second of bandwidth, and it still can't keep up? Can you imagine how many instructions the dual G5 can execute per second? And it is still not enough for the machine to redraw a window contents in real time? I have looked at the zillion levels of method calls in Cocoa just to draw one glyph on the screen. It's like getting a purchase order approved at a large corporation - level after level of draw_object, which calls draw_string, which calls draw_character, which calls draw_glyph, etc.. Then talk about redrawing 20000 of these objects 60 or 120 times a second - no processor will ever be able to execute that many billions of instructions per second. On the Apple II you had a character generator ROM that took signals in one side and spit out the character's bits on the other. One megahertz handled it; now we are four thousand times faster and the result is slower. It's inconceivable. I mean really, if the dual G5 can't do it, then there is no Apple computer that will ever do it. Maybe instead of having all these frameworks call hundreds of other frameworks over and over, they need to make some optimized higher-level calls to draw a whole string, for example. Or a whole rectangle method that does not have to call draw_line which then calls draw_point which then calls compute_point which calls translate_point which calls getOriginOfLocalGworld, etc, etc. Bill Atkinson's ENTIRE QuickDraw framework was 24 kilobytes of MC68000 code on the Macintosh 128K. And it could do regions, clipping, determine whether a point was in a rectangle, etc.
Perhaps an Apple engineer will be a speaker at a Mac user group and can shed some light on this issue. No one at WWDC had the balls to ask (including me) - the emperor's clothes were gorgeous.
Comments
I paid over 2 grand for a machine that can not resize windows. That is stupid.
Yeah, thank god for all those programs and other sh*t, otherwise this laptop would be totally useless.
Originally posted by Kickaha
I never said they shouldn't consider using another presentation approach.
What I said was that saying that unaccelerated complex 2D drawing, in real-time, with a dynamically changing bounding box, is ANY indication of the 'true speed' of the *OS* is just asinine.
You're welcome to your opinion regarding the resize speed, but that's just a blatant fallacy.
You should re-read his post, he said the slowness to resize a window makes it "feel" like OS X is slow. He is correct. However, by that he does not mean that OS X is slow.
Originally posted by cowerd
Yeah, thank god for all those programs and other sh*t, otherwise this laptop would be totally useless.
Well, well... A computer without programs is a useless pile of hardware anyway. Be it fast or slow.
Back to the topic. Cocoa is a work in progress. In some aspects it offers developers the most general approach. Like with NSTableViews and NSCells. No one, I think, could make it more flexible in terms of power. This proved to have certain trade-offs like processing overhead. Cocoa devs are aware of the problem because window resizing and text rendering speed are often discussed on Apple's mailing lists in the harshest of words. They can improve it at least by optional caching of everything. Optional because if you cache every element separately, it will take much more memory, which, in turn, means more strain on the virtual memory subsystem, which leads to an overall system slow-down. Something like Windows. It starts up, launches first two apps and redraws windows instantly, but in an hour of work stalls completely, no longer being able to pay attention to the user.
Apple will improve every aspect of OS X guts. Ultimately. Just remember that Apple is a large company and its being large slows down some engineering decisions. We may get angry and feel offended as much as we want; to no avail. The best we can do is polite feedback. Just don't call them idiots because they don't call you so.
It would be more accurate to say that they created Quartz, which is many times cooler than Windows, and will be copied by Windows in Longhorn. Live window resizing is HARD with current tech when you get all the bells and whistles we get with Quartz--it's ahead of its time. Leading, not following--and that can get you in trouble at times.
I can see Apple's side--they're fighting to make this work w/o graphic card support, and it shows. They WILL win, but I wonder at the cost--I'd much rather have a pref, even a hidden one, which could enable non-live resizing ala iTunes on slow machines a while back.
Gurus--is there any reason why that couldn't be done, as a practical matter?
Originally posted by mrmister
I'd much rather have a pref, even a hidden one, which could enable non-live resizing ala iTunes on slow machines a while back.
Gurus--is there any reason why that couldn't be done, as a practical matter?
I'm not a guru, but I'll try
Also it isnt just live window resizing that is a problem.
I dont know what the problem is but i would love to see and OS improvement (panther?) fix up all my other slow redraws applications
Maybe we need quartz hyper mega extreme super plus pro
Originally posted by Aussie John
it seems to me that every program in OS X has slow 2d redraw from pro tools to archicad to iphoto.
Also it isnt just live window resizing that is a problem.
Yes. The above discussion implies that there are too many CPU-dependent things happening behind the scenes only to support a flexible graphic subsystem. As an example, I recall some early version of BBEdit for OS X, it was barely usable. And it's just a text editor.
I dont know what the problem is but i would love to see and OS improvement (panther?) fix up all my other slow redraws applications.
I hope so, too.
Maybe we need quartz hyper mega extreme super plus pro
I hate to have to use a 256 MB NVidia XXX card for working in Terminal. It's simply crazy. In fact, ATI Rage 128 Pro is a decent card for most needs. My iMac with it on-board is happy in OS 9, but almost helpless in OS X. I mean Finder, text processors and... <gasp> ...Photoshop 6.
Originally posted by costique
They can improve it at least by optional caching of everything. Optional because if you cache every element separately, it will take much more memory, which, in turn, means more strain on the virtual memory subsystem, which leads to an overall system slow-down.
They could just cache the whole rendered table or rendered column. Cell operations are usually fast enough so I wouldn't cache things on a per cell basis. I don't think that the memory overhead would be too big either, also they can just turn it off if too little memory is installed.
Originally posted by costique
Something like Windows. It starts up, launches first two apps and redraws windows instantly, but in an hour of work stalls completely, no longer being able to pay attention to the user.
Most caches have size limits so I don't see this problem. The caches would be LRU of course.
Originally posted by costique
IElegant? I'm not sure since the most elegant thing is fast live resizing.
Yes, and the least elegant thing is terribly slow live resizing (and slow GUI elements in general) that you can't turn off. It perfectly shows Apple's incometence, makes users angry and keeps a lot of people from switching in the first place, be it from OS 9 or Windows, if the UI feels slow and clumsy, the machine is slow. No "World's fastest PC" or "megahertz myth" can help once you use OS X for a few seconds.
To be fair: Panther is finally quite fast with the exception of resizing.
Originally posted by costique
Will it come officially from Apple? Hardly ever.
I tend to agree. It's a shame, though.
Originally posted by Aussie John
it seems to me that every program in OS X has slow 2d redraw from pro tools to archicad to iphoto.
Also it isnt just live window resizing that is a problem.
I dont know what the problem is but i would love to see and OS improvement (panther?) fix up all my other slow redraws applications
Maybe we need quartz hyper mega extreme super plus pro
This is excately what im thinking. The slowness of every program from simple jpg viewers to CAD applications and photoshop is the reason why i'm not shifting back to mac yet (I was hoping for the G5 to finally make it fast).
Its not rendering or calculation speeds thats the problem but simple tasks as open/save dialogs, color chooser, wireframe regeneration, scrolling, etc.
Windows is extremely fast at these thing, so it feels alot snappier to work with.
Can anyone explain what is the big difference between windows and mac os in this regard? MAC OS X is afterall a completely re-written OS and should therefore be sort of optimized (user interface wise) from the beginning?
ap
it seems to me that every program in OS X has slow 2d redraw from pro tools to archicad to iphoto.
Also it isnt just live window resizing that is a problem.
One prominent (at least to me) example. Illustrator 10 is double buffered, courtesy Adobe. OSX provides double buffering system wide. Put the two together and you get screen redraw hell. Adobe knew about OSX and still released Illustrator with these performance issues. In fact, they are just getting around to supporting OTF in Illustrator despite the fact the fact that OTF is the MS-Adobe roll-your-own replacement (read betterer fasterer newerer) for Type1 fonts.
Before blaming Apple for all screen redraw issues, a polite email to your favorite app vendor may also be in order.
Quartz is not the bottleneck on window resizing.
Application specific layout calculations are pretty much
always to blame. With Cocoa apps, the heavyweight nature of
NSCell and NSView incur significant overhead. Also, Cocoa's
dirty region management architecture is unfinished and
doesn't even attempt to do its job. Yep, it is still a
place holder.
From my experience overriding cocoa classes to achieve
textured windows prior to 10.2:
One place where graphics (but not quartz) causes lag is the
lighting gradient found in brushed metal windows.
Fortunately, this is one area where quartz extreme can
intervene if it hasn't already. There are also the
translucent window and control bevels used in some brushed
metal apps. Open up iTunes and take a look at the edges of
the window. They aren't just a gray, they are the same
background texture that has been either lightened or
darkened. This is computationally intense. Yet, the lag
prize still goes to layout and rendering of window content,
something fairly unrelated to quartz.
Originally posted by dfiler
Its strange that the gripers (yeah you
Quartz is not the bottleneck on window resizing.
Application specific layout calculations are pretty much
always to blame. With Cocoa apps, the heavyweight nature of
NSCell and NSView incur significant overhead. Also, Cocoa's
dirty region management architecture is unfinished and
doesn't even attempt to do its job. Yep, it is still a
place holder.
From my experience overriding cocoa classes to achieve
textured windows prior to 10.2:
One place where graphics (but not quartz) causes lag is the
lighting gradient found in brushed metal windows.
Fortunately, this is one area where quartz extreme can
intervene if it hasn't already. There are also the
translucent window and control bevels used in some brushed
metal apps. Open up iTunes and take a look at the edges of
the window. They aren't just a gray, they are the same
background texture that has been either lightened or
darkened. This is computationally intense. Yet, the lag
prize still goes to layout and rendering of window content,
something fairly unrelated to quartz.
I disagree...
I'm not an expert in these things, but programmer really seems to be. He has written quite a few interesting posts about this previously.
The problem is indeed quartz. Or rather, the problem is that quartz uses a complex rendering method called spline rendering which current graphics hardware simply cannot do.
MS Windows uses a simpler rendering method and all the rendering is done by the graphics card, thats why it's faster (as Kickaha pointed out earlier). QE manages to do SOME rendering in HW which is why moving windows is instantaneous for example, but it still can't do (because the hardware can't do it) everything it would need to do to make window resizing fast.
My guess is that apple once bet on graphics HW being advanced enough by now, then it didn't turn out that way. maybe ATI or nVidia promised them something and then plans changed. Or maybe apple thought this "bug" would be acceptable enough for users to live with untill the adequate HW finally appears. Cards like this are likely to appear soonish I hear. At least in the high end. Thats probably why apple considers it a waste to change quartz. It would be a fairly huge undertaking, after all.
Originally posted by LowB-ing
I disagree...
I'm not an expert in these things, but programmer really seems to be. He has written quite a few interesting posts about this previously.
The problem is indeed quartz. Or rather, the problem is that quartz uses a complex rendering method called spline rendering
Well, splines (b-splines I suppose) certainly have absolutely nothing to do with what we are discussing here at all and if programmer has said something about this, then he's simply wrong, period. However, I doubt that he was talking about window resising when he mentioned splines.
UI lag is NOT, repeate NOT caused by objective-c runtime overhead. the statement that c is faster than c++ which is faster than Objective-c is a generalization at best, and just plain wrong at worst. reguardless, the amount of time spent on function call/method invocation overhead is a miniscule fraction of the time spent rendering the UI, which is the real culpret. The use of large bitmapped graphics and backing stores, and drawing widgets/text with the CPU over the system bus to main memory are the causes of the UI lethergy affliction OSX seems to have... there are things apple could do to improve the situation TODAY (ie yesterday), but it seems apple is uninterested in doing so (ie uninterested, because they sure as hell can't be unaware).
I use both a dual 1.25 GHz Power Mac and an 800 MHz PowerBook, both running Jaguar. Right now, on my Power Mac, I've just resized a bunch of windows -- Finder, iTunes, Mozilla, IE, Safari -- and there just isn't any problem I see. By the time I let go of the mouse, everything's set and ready to go. When trying out resizing some web pages, I looked for pages with complicated layouts too, and even using IE, which is slowest at rendering in most cases, resizing worked well.
Do I just have insufficient expectations? Am I supposed to be expecting, nay, demanding, perfectly fluid, 60 frames-per-second animation of every resize? Is anything less than a new update for every pixel of mouse motion less than acceptable? Or is there some weird system-to-system variation where some users simply get much, much worse performance than I get?
Hell, I don't even remember being particularly bothered by any of the window resizing that I've done on my father's old 350 MHz iMac that's running Jaguar.
Not that I'm complaining about that: beige machines and early iMacs and iBooks should be dropped like bricks. This might help Apple make OS X work nice with newer and newish hardware. But if windows don't resize right WITHOUT HARDWARE on a system bought this year, there is something wrong with that. I do NOT care what it is. It's wrong. And it should be fixed or changed.
All who are concerned about this issue should be sending Apple feedback. . .
Yes sir once again. I'll be writing. Hope everyone else who wants a faster interface does as well! Maybe Apple will listen to us before they ship Panther 10.3 GM. We are representative of a large group of people. You all may have gotten used to OS X being slow but new people, OS 9 and Windows users, at once say "I thought OS X was supposed to be awesome!!!!!!!!! Yeah right Macs suck." As soon as they see a second of lag. Would be switchers are unforgiving on things like this. Apple has listened to feedback before, to much success. And the Feedback process these days is excellent. Let's all right in. They still have a few months I presume until release.
It's about as useful as demanding that the new Beetle do 200mph with the existing engine.
This isn't a programming issue. This is a hardware issue. Until the graphics hardware can meet the demands of Quartz, **2D drawing such as window resizing will never be accelerated**. Period.
Them's the facts, sorry.
So write, yes. Write to let them know you really want to see them push ATI and nVidia like mad, to produce hardware to accelerate Quartz, because that's the only solution available.
Originally posted by shetline
Do I just have insufficient expectations? Am I supposed to be expecting, nay, demanding, perfectly fluid, 60 frames-per-second animation of every resize? Is anything less than a new update for every pixel of mouse motion less than acceptable? Or is there some weird system-to-system variation where some users simply get much, much worse performance than I get?
Ever seen IE resize a window on a PC?
It is not possible to move the cursor off of the resize handle.
Now when we talk about resizing, we are not saying that it really interferes that much with getting work done. It is just one of the very few areas of OS X that no matter how much horsepower Apple seems to throw at it, it still isn't as fast as the human hand dragging the mouse. Four gigahertz of CPU power, 1000 mHz frontside bus with aggregate 12 GB per second of bandwidth, and it still can't keep up? Can you imagine how many instructions the dual G5 can execute per second? And it is still not enough for the machine to redraw a window contents in real time? I have looked at the zillion levels of method calls in Cocoa just to draw one glyph on the screen. It's like getting a purchase order approved at a large corporation - level after level of draw_object, which calls draw_string, which calls draw_character, which calls draw_glyph, etc.. Then talk about redrawing 20000 of these objects 60 or 120 times a second - no processor will ever be able to execute that many billions of instructions per second. On the Apple II you had a character generator ROM that took signals in one side and spit out the character's bits on the other. One megahertz handled it; now we are four thousand times faster and the result is slower. It's inconceivable. I mean really, if the dual G5 can't do it, then there is no Apple computer that will ever do it. Maybe instead of having all these frameworks call hundreds of other frameworks over and over, they need to make some optimized higher-level calls to draw a whole string, for example. Or a whole rectangle method that does not have to call draw_line which then calls draw_point which then calls compute_point which calls translate_point which calls getOriginOfLocalGworld, etc, etc. Bill Atkinson's ENTIRE QuickDraw framework was 24 kilobytes of MC68000 code on the Macintosh 128K. And it could do regions, clipping, determine whether a point was in a rectangle, etc.
Perhaps an Apple engineer will be a speaker at a Mac user group and can shed some light on this issue. No one at WWDC had the balls to ask (including me) - the emperor's clothes were gorgeous.