Jim and all,

The difference between 2.7 and 2.8a didn't go unnoticed. I realized that
with the implementation as is, there is a heavy speed penalty due to the
repeated computation of the pixel ramp (which is >90% of the time for the
120 at 20 example) but I absolutely needed to clean this up for some of the
canvas rework. For those of you interested in speedups here are two things
to do: a) cache the fill style and modify it only when needed (to avoid
recomputation of the pixel ramp). This should help for most of the small
cases. b) Optimize FormCanvas>>fillRectangle:fillStyle: for the special case
of a horizontal / vertical ramp. This not only helps the GradientFillMorph
but it'll help every morph that uses a rectangular gradient fill.

  - Andreas


> -----Original Message-----
> From: Jim Benson [mailto:jb at speed.net]
> Sent: Friday, March 24, 2000 12:24 PM
> To: squeak at cs.uiuc.edu
> Cc: recipient list not shown
> Subject: Re: Back to Code Challenge ( was:[ENH] Bob's World Gradient )
> 
> 
> So,
> 
> Mr. Gradient Morph is pretty tricky. Bob's change of factoring out the
> initialization of the fillStyle is good for about a 20% speedup.
> 
> I also found something semi interesting. Because the method
> GradientFillMorph #drawOn: has changed from 2.7 to 2.8a, I was able to
> measure the difference between the old style and new style gradient
> drawing
> techniques easily.
> 
> Here's the test:
> 
> Display depth set to 16.
> 
> bo _ GradientFillMorph new openInWorld.
> bo extent: ( 500 @ 500 ).
> 
> TimeProfileBrowser onBlock: [50 timesRepeat:
>    [bo drawOn: World canvas]]
> 
> In the 2.7 image, I set the #stepSize method to return 1 to be fair.
> 
> On my machine,
> 
> If you take a 2.7 image and run this test you get: 704 tallies; 11680
> msec
> 
> If you take a 2.8a image and run this test you get: 1575 
> tallies; 26036
> msec.
> 
> So the new one is about twice as slow as the old.
> 
> OK, under 2.8a the Mach banding seems a bit nicer, and we may 
> be willing
> to
> pay some to get that. Unfortunately, if we set the extent to be:
> 
> bo extent: ( 120 @ 20 ).
> 
> Under 2.7              27 tallies:    441 msec.
> Under 2.8a           355 tallies: 6026 msec.
> 
> with very little resulting visual difference. Yeah, the numbers are
> right,
> you can actually see the 2.8a draw. That doesn't seem like as an
> attractive
> of a trade off to me.
> 
> I guess you can tell now that the reason that I want this 
> faster is for
> a 3D
> look push button. Now, the comment in the base 2.7 image says that the
> original can be sped up by a factor of 4. Thus the challenge. I had no
> idea
> that the 2.8a version was > 10x slower than the one I read 
> the comments
> on.
> 
> Why is this important to me?
> 
> Well, I'm planning to use a button about this size. When I 
> press down on
> the
> button, I want to flip the gradient colors to make it appear as if the
> button is depressed. Also, the pesky rounded corner menu just 
> bogs down
> like
> a pig stuck in the mud if I get near a couple of the 2.8a gradient
> buttons.
> 
> The challenge is still on,
> 
> Jim
> 
> 
> 
> 
> ----- Original Message -----
> From: Bert Freudenberg <bert at isgnw.CS.Uni-Magdeburg.De>
> To: <squeak at cs.uiuc.edu>
> Sent: Friday, March 24, 2000 7:52 AM
> Subject: Re: [ENH] Bob's World Gradient (was: Re: Code Challenge !!!)
> 
> 
> > On Fri, 24 Mar 2000, Bert Freudenberg wrote:
> >
> > > On Fri, 24 Mar 2000, Bob Arning wrote:
> > >
> > > > On Fri, 24 Mar 2000 09:27:51 +0100 (CET) Bert Freudenberg
> > > > <bert at isgnw.CS.Uni-Magdeburg.De> wrote:
> > > > >What might be challenging (maybe it's easy) is making the World
> > > > >be able to have a gradient
> > > >
> > > > "Change Set: gradientWorld
> > > > Date: 24 March 2000
> > > > Author: Bob Arning
> > >
> > > Cool! Bob #1 did it again :-)
> > >
> > > Now that the main part is done there is just the UI 
> missing ... I'll
> > > attach the appearance menu extension, along with your changes.
> >
> > ... And now Jim's challenge is in place again - how to make 
> that darn
> > thing fast? Like when having the rounded world menu 
> dragging the mouse
> > over the items is really slow. There is a reason why we have
> FillStyles,
> > one of them being it's *awfully* slow to build the color 
> ramp so we do
> it
> > once and use it thereafter.
> >
> > Any objections to abandoning GradientMorph which saves us 4 (four!)
> > instance variables in the World? And while we are at it, how about
> > requiring that color is indeed a Color? It's extremely ugly 
> to always
> need
> > to test. With the new BitmapFillStyle there's no reason for the
> > InfiniteForm hack anymore ... For example, the tranclucency checks
> become
> > much easier (they're still buggy - check dragging a RectMorph with a
> > gradient fill whose second color is transparent ...).
> >
> >   -Bert-
> >
> >
> >