FormCanvas>>transformBy:clippingTo:during:smoothing (How to followup)

FormCanvas>>transformBy:clippingTo:during:smoothing


Hi Hal,

This is terrific.

I've been look into things that make squeak slow and
been somewhat stumped on ways to repair it. This sound
like a major clue.

The best place for this info would be to start a
Mantis report. (You can get a mantis acct freely and
easily).

A good place to start is:

http://bugs.impara.de/my_view_page.php

Mantis provides a patient persistent way to focus on
an issue.
I use it to accumulate data on a problem until a
solution can be found.
It provides a place to alert the community to a
problem;
-accumulate facts and clues from the analysis;
-publish preposed solutions and get feedback;
-get solutions havested and included into the main
stream.





>
>FormCanvas>>transformBy:clippingTo:during:smoothing
>Hal Eden haleden at colorado.edu
>Mon Sep 18 21:19:33 UTC 2006 wrote:

>hi,
>
>i've been puzzling over the slow performance of
Transform*Morphs when  
>their size becomes larger. (haven't found found much
on the web  
>beyond some vague references to slowness and some
defunct threads on  
>related subjects).
>
>doing some profiling, i found that the issue is that
if the  
>transformation is more than just a translation, a new
subcanvas is  
>allocated, the area to be transformed is drawn to
that subcanvas,  
>then the result is warped to the original canvas.
>
>all well and good--for small transformation areas,
but it turns out  
>that allocating the form often takes more time than
is desirable if  
>the form is much larger than 600x600 (x32bits). on my
mac i found it  
>taking 4-6 seconds. definitely enough to put a dent
in smooth  
>interaction.
>
>i've been noodling around with a different approach,
one which stores  
>the transform in the GrafPort, so that when the
actual drawing takes  
>place, the transform is used.
>
>my results are that for a 600x800 image form, the old
way timeToRun  
>is about 4700, with the experimental way, it is round
50.
>
>i only played enough to get images working so far and
can see that it  
>would not be trivial to make it work for everything.
>
>my question is, how would i go about pursuing this
further in a way  
>that might be useful "out there"--is anyone working
on morphic  
>maintenance?

Well yes, I remain interested in improving morphic.
There are others.
There is more to be said on this but thats for another
time.
>
>or is the real culprit my VM's memory allocation?
>
>thanks,
>
>hal


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around
http://mail.yahoo.com 

On 19-Sep-06, at 2:14 PM, Peace Jerome wrote:

>
> I've been look into things that make squeak slow

After many years involvement, my opinion is that the chief thing that  
'makes smalltalk  slow' is that it is so easy to write code that is  
good enough that nobody bothers to revisit it later. Combine that  
with the mindset it supports of 'ooh, lets try this way' and there  
you are; partially finished, almost-good ideas by the dozen.

Smalltalk as a language is not slow; even the very simplistic  
interpreter we use for Squeak is amazingly fast. Smalltalk as a  
system embodying loads of fantastic and scads of horrific code is  
slow. Sometimes.


tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
You forgot to do your backup 16 days ago.  Tomorrow you'll need that  
version.

tim Rowledge wrote:
> On 19-Sep-06, at 2:14 PM, Peace Jerome wrote:
>>
>> I've been look into things that make squeak slow
> After many years involvement, my opinion is that the chief thing that
> 'makes smalltalk  slow' is that it is so easy to write code that is
> good enough that nobody bothers to revisit it later. Combine that with
> the mindset it supports of 'ooh, lets try this way' and there you are;
> partially finished, almost-good ideas by the dozen.
Not suggesting that one should not go back and "finish" code  - but, I'm
sure you agree that one of ST strengths is the prototyping convenience
of the environment. In fact, I wish it was easier and faster to put
ideas together. I'd like to see a system that I can slap things together
quickly to get a better idea of the concept. I particularly don't like
planning ;-)

On 19-Sep-06, at 2:34 PM, Brad Fuller wrote:

Absolutely - but a prototype is just that. It would be nice to see  
something that might just possibly pass muster as 'finished' code.

Real Programmers Remember Rowledge's Rule:
Make it work
Make it work right
Make it work right , fast.

Too much code has just barely got past the 'make it' part of line 1.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Strange OpCodes: DMZ: Divide Memory by Zero

thanks, jerome

i wondered if that wasn't the right place.

i have reported it to mantis, so we'll see where it goes from here.

hal

On Sep 20, 2006, at 4:29 AM, squeak-dev-
[hidden email] wrote:

  Hal,

  Removing unnecessary buffer allocation sounds like a good idea,
especially for a computer with modest resource such as OLPC.

  I actually tried it, (by creating WarpGrafPort, copying all methods
from GrafPort, file in changes.st, and rename the
transform3By:... method to transformBy:.

  In this setting, if you rotate a Morph, it changes its size
depending on the angle.  The bounding rect calculation is wrong (or
not done at all).  What do you think?

-- Yoshiki