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 at lists.squeakfoundation.org 
> [mailto:squeak-dev-admin at lists.squeakfoundation.org] On 
> Behalf Of Henrik Gedenryd
> Sent: Wednesday, May 01, 2002 4:46 PM
> To: squeak-dev at 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
> 
>