Henrik,
This is a pseudo-logical argument. They are not the symptom. They are the cause. The symptom is slowness.
I'm sorry but this is plain nonsense. If you would have ever looked at the current inefficiencies of Morphic drawing operations then you would understand that rounded corners on windows and menus just expose these inefficiencies. Three examples:
#1: The "areasRemaingToFill" are way larger than they need to be for rounded corners.
#2: The top-down drawing method of the world is broken. It has tons of overdraw which could be completely eliminated.
#3: CornerRounder does its work even if some of the rounded corners are completely invisible.
All of the above are particularly bad for overlapping windows since #1 requires (possibly large) regions to be redrawn[*1], #2 means that complex objects need are drawn multiple times] and #3 means that stacked arrangements will pay a much larger price than those that are side by side. Fixing all of the above would make drawing in general faster and fix the apparent slowdown for rounded corners on menus and windows as a side effect.
[*1] Notice that for overlapping windows which are usually more wide than tall the logic in CornerRounder>>rectWithinCorners: is exactly wrong since it returns the larger portion of the rectangle. And in those places where the logic is used (namely areasRemainingToFill) the returned areas should be as small as possible.
Incidentally, I am still waiting for numbers on the subject. Can somebody provide some test cases so we can see what the actual slowdown is like?!
Silliness lies in insisting that they be on without stating what their advantage is.
You didn't get what I was saying: I said it's silly to turn rounding corners off "because it's slow" when - at the same time - we add tons of optional buttons which all have rounded corners. In other words: We trade four rounded corners on a system browser against 32 on the optional button pane. And that _does_ seem a bit silly, doesn't it?!
We all may have opinions about the aesthetics of the rounded corners, but turning them off was concluded on a purely rational basis.
For your own sake, I hope you don't mean what you're implying above. Is it now the case that user experience is judged exlusively on "rational" arguments?! If so, then I'll concede and find a bunch of people who are more in for the fun of it. I can understand Stephane's message (even though I disagree) but claiming that user experience is exclusively determined by rational arguments seems ... a bit silly.
Cheers, - Andreas
-----Original Message----- From: squeak-dev-admin@lists.squeakfoundation.org [mailto:squeak-dev-admin@lists.squeakfoundation.org] On Behalf Of Henrik Gedenryd Sent: Wednesday, May 01, 2002 4:46 PM To: squeak-dev@lists.squeakfoundation.org Subject: Re: rounded corners (was: Re: straw-man 3.2 default preferences)
Andreas Raab wrote:
Yes. I strongly disagree. If the argument is that it eats to many cycles, perhaps it would be useful to see _where_ these
cycles go. With
the recent changes there are many more rounded corners on the screen than ever before (all the optional buttons) and it seems
silly to me to
turn corner rounding on windows off "because it's slow".
Let's look at
the problem (speed) rather than the symptom (rounded corners).
This is a pseudo-logical argument. They are not the symptom. They are the cause. The symptom is slowness. Silliness lies in insisting that they be on without stating what their advantage is.
We all may have opinions about the aesthetics of the rounded corners, but turning them off was concluded on a purely rational basis.
So what is the rational argument for keeping rounded courners on? I.e. what do they improve? If there is some purpose, then this can be traded against the loss in speed. But unless the advantages of rounded corners aren't stated then I can't really see an argument.
The argument for having rounding on at all in the first place should really have nothing to do with speed. But a speed problem would add more weight against them.
Henrik