Jecel Assumpcao Jr
jecel at merlintec.com
Thu Jun 26 17:19:44 UTC 2003
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
> 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
> 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
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.
More information about the Self-interest