Re: [Texmacs-dev] Drawing mode notes, vector diagrams, geometric construction

[Henri Lesourd]

Karl Hegbloom wrote:

> On Tue, 2005-11-22 at 00:37 +0100, Henri Lesourd wrote:
>  
>
> > OK, I put that feature on my list, so if no other change is
> > suggested before I start to implement it, it will be as it
> > is described above.
> >    
>
> That looks alright.  What about specifying it as two precise endpoints?
>  
You mean, for defining the rotation ? It appeared to me that the
current problem is that one cannot select the center, which currently,
is automatically set to the barycenter of all the selected objects.

Thus we need to add one more step in the rotation mode : mark
the center (and then, we proceed as before, using a drag & drop
to perform the rotation itself).

Or is it that do you were thinking about something more specific
that I didn't mentioned ?

> The various ways of drawing a vector (and other objects) in Eukleides
> and DrGeo may serve as examples).
>
>  
Currently, we set the first point, then the second one, and then
the vector is drawn. Do they do something better in Eukleides &
DrGeo ?


> > That is the way it should be, editing inside a text box should be
> > exactly the same as when you are outside of a graphics.
> >    
>
> Right.  Thank you (in advance) for fixing it.
>
>  
I just found a way 2 days ago for solving this (not yet in
the CVS, currently).


> > I had the same idea, but I don't know exactly the length of this
> > finer-grained movements (or perhaps should be proportional to the
> > length of the wide-grained movements, let's say 10x finer than the
> > usual movements ?).
> >    
>
> Perhaps, or have it be adjustable, with some reasonable default.  Maybe
> there ought to be a way to type in the bounding box also, from a dialog
> that shows the present values?
>
>  
Something like that is definitely possible. So OK, I will start
with something as simple as possible, then we will see what are
the advantages and the disadvantages of the solution.


> It's still a little slow too.  I hope that you will perform some
> optimization after you get it factored down to what you want it to be.
>
>  
Yes, (before releasing the alpha version) we already met (unbearable)
speed problems. These very problems have been solved, and the soft
is currently quite useable, but in effect, I will keep an eye on
this ; I'm pretty sure there is still room for improvement. I count
on the making of more heavy / complex graphics that people (including
me) will sooner or later start making to get more insights about that.

But as Mr Pike states it (those are even his first 2 rules) :
<<
  Rule 1. You can't tell where a program is going to spend its time.
Bottlenecks occur in surprising places, so don't try to second guess and put
in a speed hack until you've proven that's where the bottleneck is.

Rule 2. Measure. Don't tune for speed until you've measured, and even then
don't unless one part of the code overwhelms the rest.
>>

Thus to prove where the bottlenecks are, and also to do measurements,
we definitely need more experience in using the software. Now you
know where your duty is ;-) !


Best, Henri