Re: [Plib-devel] Work outstanding.

[Gil C. <g.c...@ca...>]

At 09:25 AM 8/10/00 +0100, you wrote:
>Gil wrote:
>
> >puTrace
>
>Sounds great! Obviously, the more info on bottlenecks there is, the
>better. For example, it would be GREAT to know how much
>texture-swapping there is going on, but I doubt this can be done
>portably?

Over to Steve for this one, but I suspect that with a little user 
assistance (eg. "How much texture memory does your board have"), we can 
probably have a stab at guessing how much texture swapping from main memory 
to texture memory is occurring.

Anybody know if you can monitor AGP transactions to pick this kind of thing 
up?


>I think the first step should be simply to measure all the things.
>Displaying and(or sending them via TCP/IP is of secondary importance.

Agreed.


> >puFly
>
>Why not use PPE? It has several windows, a hierarchial view, great
>viewing via mouse or keyboard or commands (for example, "view
>everything"). It allows you to edit the model while seeing the
>performance. Of course PPE can load all plib stuff, since it is build
>on plib.

Well, the attraction with perfly is that it really doesn't do anything 
apart from load and display models.  Perfly's ability to change the 
rendering parameters is very nice, and keeping it as a simple but powerful 
program means that the source stays compact - compact enough to go with the 
standard examples tarball for PLIB.

The real win with this is that people can build puFly and load up models 
very easily.  The code will be compact enough that people can see how to 
not only use the loaders, but also exercise all of the rendering 
methods.  Hopefully, puFly will have enough in it that people can use it as 
a basis for their own first tinkerings - I know I'm still using the 
original tux-on-a-box program as my starting point for experiments!

>We could create a new window for puTrace output.

I hadn't thought of puTrace being used inside PPE.  Given that PPE is a 
modelling package not a gaming engine, is this something you would really 
need to do?  Obviously it's possible, but I'm not really clear on what you 
would use it for; I'm open to comments on this.

 >[autmatical docs]

>I am not against them. But I think we need a handcrafted doc for the
>users of plib as well. For example, you have to give an overview of
>plib.This fits nowhere in the code.

Very true.  I guess you can draw the distinction between a programmer's 
guide and an API reference - the API reference is automagically updated 
from source comments, while the programmer's guide is a more static 
document which gets updated when major new features get added.  I'm a big 
fan of nice docs, and I'm more than happy to put the effort into them 
provided other people can point out my errors :-)

Gil