[self-interest] questions

[Jecel Assumpcao Jr]

On Tue, 24 Jun 2003 19:25:32 -0700, David Ungar wrote:
> Which outliner are you dragging?

My tests used an outliner for 'globals' with the bottom two categories 
expanded.

> Are there other outliners behind it?

No, there is a shell outliner in the corner (this is the BareBones 
snapshot) but I was not moving globals over it.

But on the iBook I used the Demo snapshot which also has a mostly empty 
initial screen but also includes a radarView. I remembered that each 
morph has to be rendered twice (on the world and a smaller version on 
the radarView) and thought that this might have been the reason it was 
slower on the iBook than on the PC (on the Sparc, which is the fastest 
of all, I also used the Demo snapshot). But opening a radarView on the 
PC made no difference since it seems to update only every two seconds 
or so.

> Does the size or amount of text in the outliner matter?

Yes. If the outliner is totally closed or only has the category list 
showing then there is no lag at all. Expanding the last category slows 
things down considerably and expanding a second category causes it to 
be even slower by a slight, but noticeable, amount.

On Wednesday 25 June 2003 02:18, Steve Dekorte wrote:
> The graphics hw is not just for compositing. It has custom logic for
> doing complex operations like polygon rendering, line drawing,
> antialiasing and much more. Right now it's sounds like these
> operations are being done on the CPU which is not designed for doing
> these operations.

The famous "wheel of hardware reincarnation" ;-) You will find that the 
more a graphics processor does, the more it looks just like your main 
CPU. Until you finally say "hey, let's just put a second processor 
there of the same kind for graphics instead of a special one. Then it 
can be use for other stuff when the graphics load is low". Later you 
start to add extra hardware to help the second processor do the most 
basic graphics stuff...

Self just calls the X Window library when it wants to draw a polygon or 
show some text. If the hardware isn't being used then it is the X 
driver's fault. I haven't looked at how things work on the Mac side.

> > If you render to an off-screen buffer and then do an accelerated
> > copy to the screen it will be much faster.
>
> Then the CPU has to process every pixel. As far as I can see, the CPU
> shouldn't need to touch *any* pixels for the type of graphics I see
> in Self.

Ok, so use the graphics processor to render to an off-screen buffer and 
then use the graphics processor to copy to the screen (frame1). Then 
use the graphics processor to copy to another position on the screen 
(frame2).

This was how Microsoft's Talisman system did it and the first version of 
my graphics engine design was like this as well. Then I decided I 
couldn't afford off-screen buffers on a 4MB machine.

> Can you write a demo to see how many polygons per second Self can
> render using it's current system? (stripping away everything but the
> demo itself)

How about a Morph that draws lots of random polygons in its baseDrawOn: 
method? It could time this and add a polygons/second text to itself. By 
dragging it around the screen you would force it to update itself so 
you could see how that number would vary.

> I think that may be a good simple test of Self's rendering engine
> that we can compare to alternate techniques.

But it is X's rendering engine, so I am not sure what we would learn 
from this little experiment.

-- Jecel