kicad-developers team mailing list archive

["Hans Henry von Tresckow" <hvontres@...>]

On Wed, Mar 5, 2008 at 7:54 AM, Alain M. <alainm@...> wrote:

>
> Dick Hollenbeck escreveu:
>
> >>
> > This will be up to the implementor. I would not be in favor of
> > maintaining two strategies, it would clutter the code. A $200 computer
> > from Walmart is probably fast enough, but I am guessing.
>
> Hum..., I believe a pool of some kind would be interesting.
>
> IMHO there could be a limit, say "old" machines can be limited to 500MHz
> Pentium II. Unfortunatly, I don't have such machines for testing. Also
> this will need a compiled package, whick will probably mean windows
> :( :(
>
> >> PS: please inform when SVN has a good version for testing...
> > We are at step 1) below. Guesses are not as helpful as actual tests.
>
> What I mean is not a full version, but a "testable" version, ie. a SVN
> version that has few bugs, and new things like magnetic routing working
> ok.
>
> I already had trouble with buggy SVN versions. As kicad is a big
> project, figuring aout if the bug is in my environment or in the source
> can spend more time than possible at the moment.
>
> Alain
>
> >
> > Dick
> >
> >> Dick Hollenbeck escreveu:
> >>
> >>> I have checked in an experimental patch for deleting a track
> >>> *segment*. It is implemented in just 4 lines or so, and it makes it so
>
> >>> that when deleting a "track segment" there is a clean drawing of the
> >>> screen afterwards. The prior technique, a 1980's technique of XORing
> >>> of the screen might have made sense when computers were not as fast.
> >>> Now I'd like to know if this improves deleting segments (only
> segments,
> >>> not entire tracks) and does not lead to intolerable delays redrawing
> the
> >>> screen.
> >>>
> >>>
> >>> If this is ok, then we should look for a volunteer to go through all
> the
> >>> track deleting code and possibly module delete code and propagate this
>
> >>> idea elsewhere. The idea is this, instead of XORing the old item being
>
> >>> erased from the screen, you simply redraw the entire screen.
> >>>
> >>> I think this is a good project for a new developer to jump in and get
> >>> immediate impact into the project. So I would be looking for a
> >>> volunteer to do this, provided there is near unanimous agreement that
> >>> this change in strategy is a good thing. Note that the strategy I am
> >>> talking about does not include "dragging" objects on screen. In the
> >>> dragging cases, the XOR technique will probably remain best. However
> >>> at end of drag, the entire screen should probably be redrawn.
> >>>
> >>> See the lines at or near line 122 in file pcbnew/deltrack.cpp as the
> >>> sample. So to summarize:
> >>>
> >>> 1) Test this patch, make sure it is fast enough, cast your vote then.
> >>>
> >>> 2) Look for other areas to implement the idea (with modified code as
> >>> appropriate): delete entire track, delete entire net, delete module,
> >>> etc. No dragging.
> >>>
> >>> 3) Get a volunteer to do 2)
> >>>
> >>>
> >>> Thanks,
> >>>
> >>> Dick
>
> 
>

Once the change is in SVN, I can try it on my collection of "elderly"
machines, a dual PII-333 and my old P1-233 Notebook :)

-- 
Henry von Tresckow (hvontres)
 ------=_Part_36115_15372897.1204733791848 Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

<br><br><div class="gmail_quote">On Wed, Mar 5, 2008 at 7:54 AM, Alain M. &lt;<a href="mailto:alainm@...";>alainm@...</a>&gt; wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">








<div style="background-color: rgb(255, 255, 255);">


<div style="width: 655px;">
<div style="padding: 0pt 15px 0pt 0pt; width: 490px; float: left;">


<div>
<p><br>
Dick Hollenbeck escreveu:</p><div class="Ih2E3d"><br>
&gt;&gt; <br>
&gt; This will be up to the implementor. I would not be in favor of <br>
&gt; maintaining two strategies, it would clutter the code. A $200 computer <br>
&gt; from Walmart is probably fast enough, but I am guessing.<br>
<br></div>
Hum..., I believe a pool of some kind would be interesting.<br>
<br>
IMHO there could be a limit, say &quot;old&quot; machines can be limited to 500MHz <br>
Pentium II. Unfortunatly, I don&#39;t have such machines for testing. Also <br>
this will need a compiled package, whick will probably mean windows<br>
:( :(<div class="Ih2E3d"><br>
<br>
&gt;&gt; PS: please inform when SVN has a good version for testing...<br>
&gt; We are at step 1) below. Guesses are not as helpful as actual tests.<br>
<br></div>
What I mean is not a full version, but a &quot;testable&quot; version, ie. a SVN <br>
version that has few bugs, and new things like magnetic routing working ok.<br>
<br>
I already had trouble with buggy SVN versions. As kicad is a big <br>
project, figuring aout if the bug is in my environment or in the source <br>
can spend more time than possible at the moment.<br>
<br>
Alain<div><div></div><div class="Wj3C7c"><br>
&gt; <br>
&gt; Dick<br>
&gt; <br>
&gt;&gt; Dick Hollenbeck escreveu:<br>
&gt;&gt; <br>
&gt;&gt;&gt; I have checked in an experimental patch for deleting a track <br>
&gt;&gt;&gt; *segment*. It is implemented in just 4 lines or so, and it makes it so <br>
&gt;&gt;&gt; that when deleting a &quot;track segment&quot; there is a clean drawing of the <br>
&gt;&gt;&gt; screen afterwards. The prior technique, a 1980&#39;s technique of XORing <br>
&gt;&gt;&gt; of the screen might have made sense when computers were not as fast. <br>
&gt;&gt;&gt; Now I&#39;d like to know if this improves deleting segments (only segments, <br>
&gt;&gt;&gt; not entire tracks) and does not lead to intolerable delays redrawing the <br>
&gt;&gt;&gt; screen.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; If this is ok, then we should look for a volunteer to go through all the <br>
&gt;&gt;&gt; track deleting code and possibly module delete code and propagate this <br>
&gt;&gt;&gt; idea elsewhere. The idea is this, instead of XORing the old item being <br>
&gt;&gt;&gt; erased from the screen, you simply redraw the entire screen.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; I think this is a good project for a new developer to jump in and get <br>
&gt;&gt;&gt; immediate impact into the project. So I would be looking for a <br>
&gt;&gt;&gt; volunteer to do this, provided there is near unanimous agreement that <br>
&gt;&gt;&gt; this change in strategy is a good thing. Note that the strategy I am <br>
&gt;&gt;&gt; talking about does not include &quot;dragging&quot; objects on screen. In the <br>
&gt;&gt;&gt; dragging cases, the XOR technique will probably remain best. However <br>
&gt;&gt;&gt; at end of drag, the entire screen should probably be redrawn.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; See the lines at or near line 122 in file pcbnew/deltrack.cpp as the <br>
&gt;&gt;&gt; sample. So to summarize:<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; 1) Test this patch, make sure it is fast enough, cast your vote then.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; 2) Look for other areas to implement the idea (with modified code as <br>
&gt;&gt;&gt; appropriate): delete entire track, delete entire net, delete module, <br>
&gt;&gt;&gt; etc. No dragging.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; 3) Get a volunteer to do 2)<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; Thanks,<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; Dick<br>
<br>
</div></div>
</div> 


<span width="1" style="color: white;"></span>

</div>













</blockquote></div><br>Once the change is in SVN, I can try it on my collection of &quot;elderly&quot; machines, a dual PII-333 and my old P1-233 Notebook :)<br clear="all"><br>-- <br>Henry von Tresckow (hvontres)
 ------=_Part_36115_15372897.1204733791848--