pythoncad-developer Mailing List for PythonCAD (Page 16)

CAD Application entire developed in Python

Status: Beta

Brought to you by: matteoboscolo

pythoncad-developer — Developer Mailing List

You can subscribe to this list here.

Flat | Threaded

<< < 1 .. 14 15 16 17 > >> (Page 16 of 17)

Re: [Pythoncad-developer] [PythonCAD] URGENT: Pythoncad's new home at Sourceforge needs gr8 attention.

From: Yagnesh D. <yn...@gm...> - 2010-01-19 08:12:14

Dear Matteo;

Thanks for the prompt action.

In install instruction we must also say
that till we have beta release one can
start pythoncad by just doing

$ python gtkpycad.py

in the relevant directory. Also in ubuntu I find that
R35 is only available

[Pythoncad-developer] Fwd: Pythoncad

From: Yagnesh D. <yn...@gm...> - 2010-01-18 12:37:26

Attachments: functions.html

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML>
<HEAD>
	<META HTTP-EQUIV="CONTENT-TYPE" CONTENT="text/html; charset=utf-8">
	<TITLE></TITLE>
	<META NAME="GENERATOR" CONTENT="OpenOffice.org 3.0  (Linux)">
	<META NAME="CREATED" CONTENT="20100109;20120500">
	<META NAME="CHANGED" CONTENT="20100109;20583000">
	<META NAME="Info 1" CONTENT="">
	<META NAME="Info 2" CONTENT="">
	<META NAME="Info 3" CONTENT="">
	<META NAME="Info 4" CONTENT="">
</HEAD>
<BODY LANG="en-GB" DIR="LTR">
<P>Cadam 14 feature list as a guide to useful software</P>
<P><BR><BR>
</P>
<TABLE WIDTH=100% BORDER=0 CELLPADDING=0 CELLSPACING=0>
	<COL WIDTH=37*>
	<COL WIDTH=108*>
	<COL WIDTH=111*>
	<TR VALIGN=TOP>
		<TD WIDTH=15%>
			<P>Create</P>
		</TD>
		<TD WIDTH=42%>
			<P><BR>
			</P>
		</TD>
		<TD WIDTH=43%>
			<P>methods/actions</P>
		</TD>
	</TR>
	<TR VALIGN=TOP>
		<TD WIDTH=15%>
			<P>Point</P>
		</TD>
		<TD WIDTH=42%>
			<P>point</P>
		</TD>
		<TD WIDTH=43%>
			<P>9</P>
		</TD>
	</TR>
	<TR VALIGN=TOP>
		<TD WIDTH=15%>
			<P><BR>
			</P>
		</TD>
		<TD WIDTH=42%>
			<P>space</P>
		</TD>
		<TD WIDTH=43%>
			<P>8</P>
		</TD>
	</TR>
	<TR VALIGN=TOP>
		<TD WIDTH=15%>
			<P><BR>
			</P>
		</TD>
		<TD WIDTH=42%>
			<P>Defining points</P>
		</TD>
		<TD WIDTH=43%>
			<P>2</P>
		</TD>
	</TR>
	<TR VALIGN=TOP>
		<TD WIDTH=15%>
			<P><BR>
			</P>
		</TD>
		<TD WIDTH=42%>
			<P>grid</P>
		</TD>
		<TD WIDTH=43%>
			<P>5</P>
		</TD>
	</TR>
	<TR VALIGN=TOP>
		<TD WIDTH=15%>
			<P>Line</P>
		</TD>
		<TD WIDTH=42%>
			<P><BR>
			</P>
		</TD>
		<TD WIDTH=43%>
			<P>26 with 31 sub-itemss</P>
		</TD>
	</TR>
	<TR VALIGN=TOP>
		<TD WIDTH=15%>
			<P>Circle</P>
		</TD>
		<TD WIDTH=42%>
			<P>Includes ellipse</P>
		</TD>
		<TD WIDTH=43%>
			<P>14 with 3 sub-items</P>
		</TD>
	</TR>
	<TR VALIGN=TOP>
		<TD WIDTH=15%>
			<P>Spline</P>
		</TD>
		<TD WIDTH=42%>
			<P><BR>
			</P>
		</TD>
		<TD WIDTH=43%>
			<P>12 with 3 sub-items</P>
		</TD>
	</TR>
	<TR VALIGN=TOP>
		<TD WIDTH=15%>
			<P>Raster</P>
		</TD>
		<TD WIDTH=42%>
			<P><BR>
			</P>
		</TD>
		<TD WIDTH=43%>
			<P>5</P>
		</TD>
	</TR>
	<TR VALIGN=TOP>
		<TD WIDTH=15%>
			<P><BR>
			</P>
		</TD>
		<TD WIDTH=42%>
			<P><BR>
			</P>
		</TD>
		<TD WIDTH=43%>
			<P><BR>
			</P>
		</TD>
	</TR>
	<TR VALIGN=TOP>
		<TD WIDTH=15%>
			<P>Modify geometry</P>
		</TD>
		<TD WIDTH=42%>
			<P><BR>
			</P>
		</TD>
		<TD WIDTH=43%>
			<P><BR>
			</P>
		</TD>
	</TR>
	<TR VALIGN=TOP>
		<TD WIDTH=15%>
			<P>Corner</P>
		</TD>
		<TD WIDTH=42%>
			<P><BR>
			</P>
		</TD>
		<TD WIDTH=43%>
			<P>3 with 2 sub-items</P>
		</TD>
	</TR>
	<TR VALIGN=TOP>
		<TD WIDTH=15%>
			<P>Offset</P>
		</TD>
		<TD WIDTH=42%>
			<P><BR>
			</P>
		</TD>
		<TD WIDTH=43%>
			<P>2 with 3 sub-items</P>
		</TD>
	</TR>
	<TR VALIGN=TOP>
		<TD WIDTH=15%>
			<P>Relimit</P>
		</TD>
		<TD WIDTH=42%>
			<P><BR>
			</P>
		</TD>
		<TD WIDTH=43%>
			<P>8 with 3 sub-items</P>
		</TD>
	</TR>
	<TR VALIGN=TOP>
		<TD WIDTH=15%>
			<P>Show</P>
		</TD>
		<TD WIDTH=42%>
			<P>Erase, display etc</P>
		</TD>
		<TD WIDTH=43%>
			<P>8 with 6 sub-items</P>
		</TD>
	</TR>
	<TR VALIGN=TOP>
		<TD WIDTH=15%>
			<P>Type</P>
		</TD>
		<TD WIDTH=42%>
			<P>Style, colour etc</P>
		</TD>
		<TD WIDTH=43%>
			<P>31 with 14 sub-items</P>
		</TD>
	</TR>
	<TR VALIGN=TOP>
		<TD WIDTH=15%>
			<P>Group</P>
		</TD>
		<TD WIDTH=42%>
			<P><BR>
			</P>
		</TD>
		<TD WIDTH=43%>
			<P>35 with 20 sub-items</P>
		</TD>
	</TR>
	<TR VALIGN=TOP>
		<TD WIDTH=15%>
			<P><BR>
			</P>
		</TD>
		<TD WIDTH=42%>
			<P><BR>
			</P>
		</TD>
		<TD WIDTH=43%>
			<P><BR>
			</P>
		</TD>
	</TR>
	<TR VALIGN=TOP>
		<TD WIDTH=15%>
			<P>Annotation</P>
		</TD>
		<TD WIDTH=42%>
			<P><BR>
			</P>
		</TD>
		<TD WIDTH=43%>
			<P><BR>
			</P>
		</TD>
	</TR>
	<TR VALIGN=TOP>
		<TD WIDTH=15%>
			<P>Dimension</P>
		</TD>
		<TD WIDTH=42%>
			<P><BR>
			</P>
		</TD>
		<TD WIDTH=43%>
			<P>37 with 11 sub-items</P>
		</TD>
	</TR>
	<TR VALIGN=TOP>
		<TD WIDTH=15%>
			<P>Note</P>
		</TD>
		<TD WIDTH=42%>
			<P><BR>
			</P>
		</TD>
		<TD WIDTH=43%>
			<P>27 with 9 sub-items</P>
		</TD>
	</TR>
	<TR VALIGN=TOP>
		<TD WIDTH=15%>
			<P>(character sets)</P>
		</TD>
		<TD WIDTH=42%>
			<P><BR>
			</P>
		</TD>
		<TD WIDTH=43%>
			<P><BR>
			</P>
		</TD>
	</TR>
	<TR VALIGN=TOP>
		<TD WIDTH=15%>
			<P>Analysis</P>
		</TD>
		<TD WIDTH=42%>
			<P><BR>
			</P>
		</TD>
		<TD WIDTH=43%>
			<P>11 with 3 sub-items</P>
		</TD>
	</TR>
	<TR VALIGN=TOP>
		<TD WIDTH=15%>
			<P>Symbol</P>
		</TD>
		<TD WIDTH=42%>
			<P><BR>
			</P>
		</TD>
		<TD WIDTH=43%>
			<P>35 with 10 sub-items</P>
		</TD>
	</TR>
	<TR VALIGN=TOP>
		<TD WIDTH=15%>
			<P><BR>
			</P>
		</TD>
		<TD WIDTH=42%>
			<P><BR>
			</P>
		</TD>
		<TD WIDTH=43%>
			<P><BR>
			</P>
		</TD>
	</TR>
	<TR VALIGN=TOP>
		<TD WIDTH=15%>
			<P>Auxiliary views, origins &amp; details</P>
		</TD>
		<TD WIDTH=42%>
			<P><BR>
			</P>
		</TD>
		<TD WIDTH=43%>
			<P><BR>
			</P>
		</TD>
	</TR>
	<TR VALIGN=TOP>
		<TD WIDTH=15%>
			<P>(Auxiliary views)</P>
		</TD>
		<TD WIDTH=42%>
			<P>Some similarities to layers; enables projections of ie plan to
			be drawn directly on elevation or section. Helps getting work
			accurate. Individual orientation and scale on screen</P>
		</TD>
		<TD WIDTH=43%>
			<P><BR>
			</P>
		</TD>
	</TR>
	<TR VALIGN=TOP>
		<TD WIDTH=15%>
			<P>Origin</P>
		</TD>
		<TD WIDTH=42%>
			<P><BR>
			</P>
		</TD>
		<TD WIDTH=43%>
			<P>6 with 1 sub-item</P>
		</TD>
	</TR>
	<TR VALIGN=TOP>
		<TD WIDTH=15%>
			<P>Details</P>
		</TD>
		<TD WIDTH=42%>
			<P>Detail pages as part of the drawing: similarities to blocks</P>
		</TD>
		<TD WIDTH=43%>
			<P>17 with 11 sub-items</P>
		</TD>
	</TR>
	<TR VALIGN=TOP>
		<TD WIDTH=15%>
			<P><BR>
			</P>
		</TD>
		<TD WIDTH=42%>
			<P><BR>
			</P>
		</TD>
		<TD WIDTH=43%>
			<P><BR>
			</P>
		</TD>
	</TR>
	<TR VALIGN=TOP>
		<TD WIDTH=15%>
			<P>Advanced functions</P>
		</TD>
		<TD WIDTH=42%>
			<P><BR>
			</P>
		</TD>
		<TD WIDTH=43%>
			<P><BR>
			</P>
		</TD>
	</TR>
	<TR VALIGN=TOP>
		<TD WIDTH=15%>
			<P>(Electrical)</P>
		</TD>
		<TD WIDTH=42%>
			<P>Includes some items more usefully covered in symbol and detail</P>
		</TD>
		<TD WIDTH=43%>
			<P><BR>
			</P>
		</TD>
	</TR>
	<TR VALIGN=TOP>
		<TD WIDTH=15%>
			<P>Overlay</P>
		</TD>
		<TD WIDTH=42%>
			<P>Work with multiple drawing files (ie separate xml.gzs) laid
			over each other on the screen and able to interact in some ways:
			simple example is having a title block drawing which is overlaid
			on each drawing for plotting, without needing to carry the title
			block data in every drawing</P>
		</TD>
		<TD WIDTH=43%>
			<P>17</P>
		</TD>
	</TR>
	<TR VALIGN=TOP>
		<TD WIDTH=15%>
			<P><BR>
			</P>
		</TD>
		<TD WIDTH=42%>
			<P><BR>
			</P>
		</TD>
		<TD WIDTH=43%>
			<P><BR>
			</P>
		</TD>
	</TR>
</TABLE>
<P><BR><BR>
</P>
</BODY>
</HTML>

Re: [Pythoncad-developer] PythonCAD elements and the xml schema.

From: <ger...@gm...> - 2010-01-14 20:57:52

Hi Matteo,

Thank you for the link I didn't knew this, it is interesting.

What do you mean with:
> I .net i strongly use serialization, and I use to load very
> huge xml file and this file will be loaded in a very short
> time ..


I did not want to use oracle, I was looking for a generic way to describe  
geometric primitives.
If we have a generic way to describe a geometric primitives we can create  
new entities that are based on or use a compound of standard geometric  
primitives.
My idea was to define a way to describe geometric primitives based on the  
oracle sdo_geometry datatype, not use oracle itself.

Here is a short description of the sdo_geometry datatype and what I had in  
mind
We can adjust the sdo_geometry datatype so that it suits us well.
I think this is a condensed way to describe a geometry, it is used for very  
large amounts of spatial data in databases
Maybe this can help us to keep our files as small as possible meaning less  
time to load or save them.

In the beginning the sdo_geometric datatype looks a little bit difficult  
but it is very easy to write functions that (for instance) split the  
geometry in multiple parts or reverse the geometry.


This is how current points are described in PythonCAD xml.
I don't want to change it, it is file.
<image:Points>
<image:Point id="0" x="200.51097480092585" y="261.42252735360762"/>
<image:Point id="1" x="554.89312420833494" y="115.73893005580049"/>
<image:Point id="2" x="516.37339427737993" y="151.8821720888912"/>
<image:Point id="3" x="863.48937127348472" y="234.35641810861949"/>
<image:Point id="4" x="254.3827367855306" y="351.33464277268638"/>
</image:Points>


<Geometry>
<GType>03</GType>
<ElemInfo>
<Number>1</Number>
<Number>1003</Number>
<Number>2</Number>
</ElemInfo>
<Points>
<Point id="0"/> <= reference to the point in the list above.
<Point id="1"/>
<Point id="2"/>
<Point id="3"/>
<Point id="4"/>
</Points>
</Geometry>

The <GType>03</GType> describes the geometry type which is used.
It can be:
01 POINT (we do not need this).
02 LINE or CURVE Geometry contains one line string that can contain  
straight or circular arc segments, or both. (LINE and CURVE are synonymous  
in this context.)
03 POLYGON Geometry contains one polygon with or without holes.
04 COLLECTION Geometry is a heterogeneous collection of elements.
05 MULTIPOINT Geometry has one or more points. (MULTIPOINT is a superset of  
POINT.)
06 MULTILINE or MULTICURVE Geometry has one or more line strings.
07 MULTIPOLYGON Geometry can have multiple, disjoint polygons (more than  
one exterior boundary).

A ElemInfo is a series of triplets (tuples with 3 values) which describes  
how the points are interpreted:
<ElemInfo>
<Number>1</Number>
<Number>1003</Number>
<Number>2</Number>
</ElemInfo>

The first number (1) indicates the index of the first point this ElemInfo  
describes.

The second number (1003) indicates this is a exterior polygon ring.
Possible values are:
1= point, we do not need the, point is already there.
2= line string, is used for circular and linear connections.
1003= exterior polygon ring.
2003= interior polygon ring.

The third number (2) indicates that the points are connected by circular  
arcs.

Example ElemInfo triplets which descibes a exterior and a interior ring  
(hole):
(1,1003,1)(9,2003,2)

The first (1,1003,1) describes a exterior ring which starts at point 1 and  
has linear connections between points.
The second (9.2003,2) describes the interior ring which starts at point 9  
and has circular connections between points.
There can be any number of triplets.

The list of points are references to the point list as it current exist in  
the PythonCAD xml file.

This way we can also describe the boundary of a hatch which can exist of  
multiple exterior and interior rings.
We can not describe ellipses or splines with this standard sdo_geometry  
construct but we can think how to extend it.

My goal with this is to find a generic way to describe element geometry.
All the other tags and attributes that describes entities stays as it is  
now.

Regards,
Gertwin

Op schreef "mat...@bo..." <mat...@bo...>:
> Hi Gertwin,



> We can create object structure starting from an xsd schema.



> I .net i strongly use serialization, and I use to load very

> huge xml file and this file will be loaded in a very short

> time ..



> In this link there is a proget that create some classes

> starting from xml schema:

> http://www.rexx.com/~dkuhlman/generateDS.html

> I know that in python thare is the abiliti to load and write

> object directly from file.



> I don't whant to use the oracle db (It's not open source).



> In the following days i will do some test and let you know

> if we can do some improvments in this direction.



> Regards,

> Matteo

> ----- Original Message -----

> Da : Gertwin Groen ger...@gm...>

> A : pythoncad-developer

> Pyt...@li...>, Matteo Boscolo

> mat...@bo...>, Yagnesh Desai

> yn...@ln...>

> Oggetto : PythonCAD elements and the xml schema.

> Data : Wed, 13 Jan 2010 22:55:35 +0100



> > Hello all,

> >

> > I want to define a list of elements (entities) and their

> > geometry primitives we want to provide in PythonCAD that

> > are not yet supported. The file format of PythonCAD is

> > described in the pythoncad.xsd schema, this the base of

> > what a PythonCAD drawing can contain.

> >

> > I think it is time to review this schema because it has an

> > influence on everything we want to do with PythonCAD.

> > This is very necessary because changes in the

> > schema/drawing format are time consuming to implement in

> > PythonCAD.

> >

> > What we have:

> > Current supported list of elements (from the pythoncad.xsd

> > schema): - Points

> > - Segments

> > - Circles

> > - Arcs

> > - HCLines

> > - VCLines

> > - ACLines

> > - CLines

> > - CCircles

> > - LDims

> > - HDims

> > - VDims

> > - RDims

> > - ADims

> >

> > In PythonCAD there are more elements which are not

> > described in the schema:

> >

> > - TextBlock

> > - Polyline

> > - Fillets?

> > - Chamfer?

> >

> > What we want:

> > Current unsupported list of elements/entities:

> > - polylines with arcs

> > - block definition and reference

> > - ellipse arc

> > - ellipse

> > - hatch

> > - polygon (as AutoCAD MPolygon, very similar to hatch)

> > - ...

> >

> > In the current schema all the elements are described and

> > each of them has his own description of its geometry.

> > If you give the schema a second look you see that multiple

> > elements have a similar geometric primitive.

> > For instance:

> > A segment is a polyline with 2 points.

> > A circle is a arc with the start angle == end angle

> > etc.

> >

> > It would be better to have one geometric primitive where

> > all the entities make use of it (if possible).

> > Future elements can also make use of this geometric

> > primitive or a group of primitives.

> > If we have only one geometric datatype the drawing of the

> > entities is much simpler (to maintain and for new

> > elements).

> >

> > Maybe a candidate for a geometric datatype is the oracle

> > SDO_GEOMETRY datatype (I have a GIS background thats why I

> > chose this). The only thing that is not directly supported

> > is a ellipse.

> >

> > The supported geometric types by the SDO_GEOMETRY datatype

> > are (from the oracle documentation):

> >

> > POINT

> > Geometry contains one point.

> > * PythonCAD element Point

> >

> > LINE or CURVE

> > Geometry contains one line string that can contain

> > straight or circular arc segments, or both. (LINE and

> > CURVE are synonymous in this context.)

> > * PythonCAD element Segment, Polyline (with and without

> > arcs)

> >

> > POLYGON

> > Geometry contains one polygon with or without holes.

> > * PythonCAD element Hatch and Polygon

> >

> > COLLECTION

> > Geometry is a heterogeneous collection of elements.

> > COLLECTION is a superset that includes all other types.

> >

> > MULTIPOINT

> > Geometry has one or more points. (MULTIPOINT is a superset

> > of POINT.)

> >

> > MULTILINE or MULTICURVE

> > Geometry has one or more line strings. (MULTILINE and

> > MULTICURVE are synonymous in this context, and each is a

> > superset of both LINE and CURVE.)

> > * PythonCAD element ellipse can be presented as a

> > collection of arcs

> >

> > MULTIPOLYGON

> > Geometry can have multiple, disjoint polygons (more than

> > one exterior boundary). (MULTIPOLYGON is a superset of

> > POLYGON.) * PythonCAD element Hatch and Polygon

> >

> > I think this datatype is not suited for describing 3D

> > elements but I have no/very limited knowledge of 3D

> >

> > Any thoughts on this?

> > Better, other ideas?

> >

> > Regards,

> > Gertwin

Re: [Pythoncad-developer] PythonCAD elements and the xml schema.

From: <mat...@bo...> - 2010-01-14 15:34:28

Hi Gertwin,

We can create object structure starting from an xsd schema.

I .net i strongly use serialization, and I use to load very
huge xml file and this file will be loaded in a very short
time ..

In this link there is a proget that create some classes
starting from xml schema:
http://www.rexx.com/~dkuhlman/generateDS.html
I know that in python thare is the abiliti to load and write
object directly from file.

I don't whant to use the oracle db (It's not open source).

In the following days i will do some test and let you know
if we can do some improvments in this direction.

Regards,
Matteo
----- Original Message -----
Da : Gertwin Groen <ger...@gm...>
A : pythoncad-developer
<Pyt...@li...>,  Matteo Boscolo
<mat...@bo...>, Yagnesh Desai
<yn...@ln...>
Oggetto : PythonCAD elements and the xml schema.
Data : Wed, 13 Jan 2010 22:55:35 +0100

> Hello all,
> 
> I want to define a list of elements (entities) and their
> geometry primitives we want to provide in PythonCAD that
> are not yet supported. The file format of PythonCAD is
> described in the pythoncad.xsd schema, this the base of
> what a PythonCAD drawing can contain.
> 
> I think it is time to review this schema because it has an
> influence on everything we want to do with PythonCAD.
> This is very necessary because changes in the
> schema/drawing format are time consuming to implement in
> PythonCAD.
> 
> What we have:
> Current supported list of elements (from the pythoncad.xsd
> schema): - Points
> - Segments
> - Circles
> - Arcs
> - HCLines
> - VCLines
> - ACLines
> - CLines
> - CCircles
> - LDims
> - HDims
> - VDims
> - RDims
> - ADims
> 
> In PythonCAD there are more elements which are not
> described in the schema:
> 
> - TextBlock
> - Polyline
> - Fillets?
> - Chamfer?
> 
> What we want:
> Current unsupported list of elements/entities:
> - polylines with arcs
> - block definition and reference
> - ellipse arc
> - ellipse
> - hatch
> - polygon (as AutoCAD MPolygon, very similar to hatch)
> - ...
> 
> In the current schema all the elements are described and
> each of them has his own description of its geometry.
> If you give the schema a second look you see that multiple
> elements have a similar  geometric primitive.
> For instance:
> A segment is a polyline with 2 points.
> A circle is a arc with the start angle == end angle
> etc.
> 
> It would be better to have one geometric primitive where
> all the entities make use of it (if possible).
> Future elements can also make use of this geometric
> primitive or a group of primitives.
> If we have only one geometric datatype the drawing of the
> entities is much simpler (to maintain and for new
> elements).
> 
> Maybe a candidate for a geometric datatype is the oracle
> SDO_GEOMETRY datatype (I have a GIS background thats why I
> chose this). The only thing that is not directly supported
> is a ellipse.
> 
> The supported geometric types by the SDO_GEOMETRY datatype
> are (from the oracle documentation):
> 
> POINT
> Geometry contains one point.
> * PythonCAD element Point
> 
> LINE or CURVE
> Geometry contains one line string that can contain
> straight or circular arc segments, or both. (LINE and
> CURVE are synonymous in this context.)
> * PythonCAD element Segment, Polyline (with and without
> arcs)
> 
> POLYGON
> Geometry contains one polygon with or without holes.
> * PythonCAD element Hatch and Polygon
> 
> COLLECTION
> Geometry is a heterogeneous collection of elements.
> COLLECTION is a superset that includes all other types.
> 
> MULTIPOINT
> Geometry has one or more points. (MULTIPOINT is a superset
> of POINT.)
> 
> MULTILINE or MULTICURVE
> Geometry has one or more line strings. (MULTILINE and
> MULTICURVE are synonymous in this context, and each is a
> superset of both LINE and CURVE.)
> * PythonCAD element ellipse can be presented as a
> collection of arcs
> 
> MULTIPOLYGON
> Geometry can have multiple, disjoint polygons (more than
> one exterior boundary). (MULTIPOLYGON is a superset of
> POLYGON.) * PythonCAD element Hatch and Polygon
> 
> I think this datatype is not suited for describing 3D
> elements but I have no/very limited knowledge of 3D
> 
> Any thoughts on this?
> Better, other ideas?
> 
> Regards,
> Gertwin

[Pythoncad-developer] PythonCAD elements and the xml schema.

From: Gertwin G. <ger...@gm...> - 2010-01-13 21:55:42

Hello all,

I want to define a list of elements (entities) and their geometry
primitives we want to provide in PythonCAD that are not yet supported.
The file format of PythonCAD is described in the pythoncad.xsd schema,
this the base of what a PythonCAD drawing can contain.

I think it is time to review this schema because it has an influence
on everything we want to do with PythonCAD.
This is very necessary because changes in the schema/drawing format
are time consuming to implement in PythonCAD.

What we have:
Current supported list of elements (from the pythoncad.xsd schema):
- Points
- Segments
- Circles
- Arcs
- HCLines
- VCLines
- ACLines
- CLines
- CCircles
- LDims
- HDims
- VDims
- RDims
- ADims

In PythonCAD there are more elements which are not described in the schema:

- TextBlock
- Polyline
- Fillets?
- Chamfer?

What we want:
Current unsupported list of elements/entities:
- polylines with arcs
- block definition and reference
- ellipse arc
- ellipse
- hatch
- polygon (as AutoCAD MPolygon, very similar to hatch)
- ...

In the current schema all the elements are described and each of them
has his own description of its geometry.
If you give the schema a second look you see that multiple elements
have a similar  geometric primitive.
For instance:
A segment is a polyline with 2 points.
A circle is a arc with the start angle == end angle
etc.

It would be better to have one geometric primitive where all the
entities make use of it (if possible).
Future elements can also make use of this geometric primitive or a
group of primitives.
If we have only one geometric datatype the drawing of the entities is
much simpler (to maintain and for new elements).

Maybe a candidate for a geometric datatype is the oracle SDO_GEOMETRY
datatype (I have a GIS background thats why I chose this).
The only thing that is not directly supported is a ellipse.

The supported geometric types by the SDO_GEOMETRY datatype are (from
the oracle documentation):

POINT
Geometry contains one point.
* PythonCAD element Point

LINE or CURVE
Geometry contains one line string that can contain straight or
circular arc segments, or both. (LINE and CURVE are synonymous in this
context.)
* PythonCAD element Segment, Polyline (with and without arcs)

POLYGON
Geometry contains one polygon with or without holes.
* PythonCAD element Hatch and Polygon

COLLECTION
Geometry is a heterogeneous collection of elements. COLLECTION is a
superset that includes all other types.

MULTIPOINT
Geometry has one or more points. (MULTIPOINT is a superset of POINT.)

MULTILINE or MULTICURVE
Geometry has one or more line strings. (MULTILINE and MULTICURVE are
synonymous in this context, and each is a superset of both LINE and
CURVE.)
* PythonCAD element ellipse can be presented as a collection of arcs

MULTIPOLYGON
Geometry can have multiple, disjoint polygons (more than one exterior
boundary). (MULTIPOLYGON is a superset of POLYGON.)
* PythonCAD element Hatch and Polygon

I think this datatype is not suited for describing 3D elements but I
have no/very limited knowledge of 3D

Any thoughts on this?
Better, other ideas?

Regards,
Gertwin

[Pythoncad-developer] R: [PythonCAD] URGENT: Pythoncad's new home at Sourceforge needs gr8 attention.

From: <eu...@li...> - 2010-01-13 12:52:12

Hi Yagnesh,

I will remove the file from the website and i will replace it as 
soon we have a good installation pakage.

Regards,
Matteo
>----Messaggio 
originale----
>Da: yn...@gm...
>Data: 13/01/2010 11.02
>A: <pythoncad-
dev...@li...>, <Pyt...@py...>
>Ogg: [PythonCAD] 
URGENT: Pythoncad&#39;s new home at Sourceforge needs gr8	attention.
>
>Dear 
Matteo;
>
>Following needs your URGENT attention:
>
>If a visitor visits 
pythoncad page on sourceforge.net
>he has a link to download :
>PythonCAD-DS1-
R37.linux-i686.zip
>
>I downloaded this file and to my surprise it is 
impossible
>to start pythoncad with available files in this zip. It does not

>even includes the readme & install files or the gtkpycad.py.
>
>I suggest we 
need not ask people to install the pythoncad
>we must give a download ZIP which 
contains a folder
>which can be exploded to desktop  as a file and a folder.

>New user should be able to start pythoncad just by running only
>file in that 
folder.
>
>I believe that none of 160 downloads per day is resulting
>in a 
satisfactory trial by user. Which means more and more
>users are getting first 
impression that pythoncad is not
>working.
>
>- - - - -
>Best regards
>

>Yagnesh Desai
>Save a tree...please don't print this e-mail.

>_______________________________________________
>PythonCAD mailing list

>Pyt...@py...
>http://mail.python.org/mailman/listinfo/pythoncad
>

[Pythoncad-developer] URGENT: Pythoncad's new home at Sourceforge needs gr8 attention.

From: Yagnesh D. <yn...@gm...> - 2010-01-13 10:03:06

Dear Matteo;

Following needs your URGENT attention:

If a visitor visits pythoncad page on sourceforge.net
he has a link to download :
PythonCAD-DS1-R37.linux-i686.zip

I downloaded this file and to my surprise it is impossible
to start pythoncad with available files in this zip. It does not
even includes the readme & install files or the gtkpycad.py.

I suggest we need not ask people to install the pythoncad
we must give a download ZIP which contains a folder
which can be exploded to desktop  as a file and a folder.
New user should be able to start pythoncad just by running only
file in that folder.

I believe that none of 160 downloads per day is resulting
in a satisfactory trial by user. Which means more and more
users are getting first impression that pythoncad is not
working.

- - - - -
Best regards

Yagnesh Desai
Save a tree...please don't print this e-mail.

[Pythoncad-developer] Notes on Pythoncad and drawing

From: Yagnesh D. <yn...@gm...> - 2010-01-13 02:05:20

Dear Friends;

Following is the note from Mr David Young whose request I
found received by email and helped him download pythoncad
ver R38 for testing, I am trying to have him on our group but
till then following is his note for the record

Quote:

Notes on Pythoncad and drawing


David Young


I am a professional architect (building design and construction),
having completed my degree in 1976. I started electronic drawing in
1989, and have used Cadam (originally from Lockheed) and its later
Helix version for most of my technical drawings since 1989. An
offshoot went into Catia (Dassault Systemes) when Cadam and Helix
support terminated outside Japan. I have been trying to learn to use
Blender, and have done some translation of manuals for gCAD3D. I had
started looking at Python (I have done some web and intranet work with
PHP) when I came across the Pythoncad site, and thought the idea was
interesting.


Some asides:

There are a number of FOSS and similar CAD and modelling programmes
around, but each seems to be incomplete in various ways, or perhaps I
do not have sufficient understanding of how they work.

The idea of a standard type of file format (OCA) seems good, in that
the aim is not to work around the Autocads, but to make a useful
product which stands on its own and can import and export readily.


Pythoncad communications:

>From what I have seen, there seems to be a need for better
communication for the project. The Sourceforge site is fine for
downloads and development, but it seems to me that there needs to be a
current web site and wiki type facility (I get a dead end clicking on
the wiki link on Sourceforge, and the link to the web site which
points back to Sourceforge is not helpful).


The download packages need to be complete, with instructions, and with
pointers to help. Without this, the project creates a bad impression.


Drawing in general

The least moves and clicks to get the most accurate data on to each
drawing is the aim.


I can only try to generalise from my experience.


Interface:

Needs to be as customisable as possible.


More useful items need to appear on the display. One feature with
Cadam is that a short list of next possible actions is given on
screen.


The three-button mouse gives a potential six actions, plus scaling
using the wheel. Must work for left and right hands. Inner button,
middle mouse, outer button, inner+outer, inner+middle and
outer+middle.

Cadam uses 5 of these, and has its own consistent usage of 'select'
(inner), 'indicate' (middle) and 'yes/no' (outer) plus 'window' (one
2-button combination) and 'pop-up menu' (another 2-button
combination).


Because the list of functions and actions neccessarily gets long in
order for the software to be useful, one potential thing from Cadam is
that each main function appears on the pop-up menu, with sub-menus
appearing in context relative to the function.


Output must be plottable to scale on paper for the software to be usable.


It is necessary for a drawing to be able to include a variety of
scales and rotations of work, and plotting must handle these
correctly.


Analysis of existing points, lines etc must be quick and easy.


There must be access to standard symbols and details. 1989+ Cadam
allows dipping in to any drawing on the network to extract details for
use in your current drawing.


And things like area fills are essential for use of the software. I
will give a detailed list of Cadam functionality when time permits,
just as a checklist of things needed in useful software, as well as a
bare-bones minimum list.


Backward compatibilty is highly desirable for me. Cadam has removed
limits and added features, but one can open the oldest drawing and
save it as a current model.


There is no end to what is needed to make CAD simpler to use and more
productive. It goes on from 2D to 2.5D (Cadam) to 3D to models with
extraction of 2D and 3D sheets (Archicad etc). And we are just at the
beginning.



Other comments will follow. All is hopefully seen as positive comment.


David

:UnQuote

-- 
Best regards

Yagnesh Desai

[Pythoncad-developer] PythonCAD performance

From: Gertwin G. <ger...@gm...> - 2010-01-12 21:57:17

Hi Matteo,

I think I have found the part that is (for a large part) responsible
for the bad performance.

The file imageio.py contain a function:

def load_image(image, filehandle):
    ...
    _doc = xml.dom.minidom.parse(filehandle)
    ...

Processing large xml files with a dom parser gives a very bad
performance and costs lost of memory.
It is better to use the expat parser (or an sax parser) for large files.

At work I have a very good experience with the expat parser.
I have written an arx (C++) program under AutoCAD which processes a
200+ mb xml file containing over 200.000 entities in a few (3 to 4)
minutes.

Before and after the call to _doc = xml.dom.minidom.parse(filehandle):
Memory before: ~ 30 mb.
Memory after: ~535 mb.

This was done when opening the 850 kb "8th floor furniture.xml.gz"
file (translated from dxf).
I think this call alone is responsible for more than half the total
memory usage.

At this moment I think that the chosen dom parser and the complex way
entities are stored in the image/layer are responsible for the bad
performance.

So question is what are we going to do:
1. Replace the dom parser by the expat parser.
2. Simplify the entity storage in the image/layer objects.
3. Other?

What are your or anyone else thoughts on this?

Regards,
Gertwin

Re: [Pythoncad-developer] Some working on pythoncad

From: <ger...@gm...> - 2010-01-12 20:42:17

Hi Yagnesh,

Matteo and I also had difficulties to understand the PythonCAD code, this  
(and performance) initiated the restructuring.

I agree with you on layer management.

We can also use the new cairo draw functions for plotting.
Just a thought:
Maybe we can define a special layer for plot layout (something like paper  
space).
On this plot layout the user can define multiple viewports with a different  
visual portion of the model/image/scene.

Pen assignment sounds like using a pen plotter and plotting with hpgl.
I don't know there exists such back end for cairo.

Regards,
Gertwin

On Jan 12, 2010 2:41am, Yagnesh Desai <yn...@gm...> wrote:
> Dear Gertwin;

> Offset Command :

> I am not very gr8 at OOP and have bit of difficulty

> understanding the total structure of PythonCAD.

> I will help on writing the descriptions of newer

> commands, till we find further help.

> Linetype:

> If some external file can help it would be highly

> customizable and we and ship few standard lib

> along with pythoncad.

> Better Layer management:

> - on/off of layer

> - default color and linetype of layer. (currently all the layers

> other than current are having same color)

> - freezing of layer (currently all the layers other than

> current are frozen)

> Print:

> to PDF will be always useful we can focus on high end

> plotter/printer later

> Pen asignment:

> I am more used to managing print with line color

> since changing lineweight of every object at later

> date when we decide to take print on different size

> of paper becomes difficult. But using entities lineweight

> can also help.

> --

> Best regards

> Yagnesh Desai

> Save a tree...please don't print this e-mail.

Re: [Pythoncad-developer] Pushed many changes to the R38 branch

From: <ger...@gm...> - 2010-01-12 20:29:54

Hi Yagnesh,

There are not many changes made in the Generic part of PythonCAD.
I think you can still push your modified code into the repository.

A while ago I had a discussion with Matteo about blocks.
The idea was to create some special layers, each of the layer could contain  
a block definition.
The layers are not shown in the layer manager, they just have a block  
definition function.
This is just an idea an has not been worked out yet.

The hatch, ellipse and other entities are also on the list.

You are right it is easier to work with standard fonts.
Otherwise we can look at the *.cxf font definition files used by QCad (I  
don't know the license of this format), this is a vector format.
QCad uses dxf as its native file format so these fonts has to mimic the  
AutoCAD fonts as good as possible.

Regards,
Gertwin

On Jan 12, 2010 2:54am, Yagnesh Desai <yn...@gm...> wrote:
> I understand that you are in middle of reorganizing of

> code for better performance.

> I have started writing the code for import/export of color

> to & from dxf. I am writing it on my earlier git download

> hope should have no issue with the new organized code.

> On the loss of blocks and entities during the import if

> pythoncad can support similar blocks it would be lot

> more easier. (block is handy tool for the CAD user too)

> (Hatch, ellipse & splines are few entities currently

> not available in pythoncad)

> Issue with text is multifold :

> 1. Autocad fonts are proprietary and we will have to leave

> with some adjustment of width and height (by the way AutoCAD

> supports width-factor adjustment if that can be supported

> life becomes a lot more easier with the truetype fonts also)

> 2. Autocad formating is a bit funny since it was taken from

> older way of doing it ie %%u is a tag in text for underlining

> %%b & many more and now with newer version of dxf they

> even have tags in between to change fonts for few words

> in para.

> 3. Dimension text also has some such issues as they have

> some block like behavior. (This I have not yet gone in depth

> since I have not come on dimension).

[Pythoncad-developer] Fwd: Some working on pythoncad

From: Yagnesh D. <yn...@gm...> - 2010-01-12 04:42:07

---------- Forwarded message ----------
From: Yagnesh Desai <yn...@gm...>
Date: Tue, Jan 12, 2010 at 7:11 AM
Subject: Re: [Pythoncad-developer] Some working on pythoncad
To: Gertwin Groen <ger...@gm...>

Dear Gertwin;

Offset Command :
I am not very gr8 at OOP and have bit of difficulty
understanding the total structure of PythonCAD.
I will help on writing the descriptions of newer
commands, till we find further help.

Linetype:
If some external file can help it would be highly
customizable and we and ship few standard lib
along with pythoncad.

Better Layer management:
- on/off of layer
- default color and linetype of layer. (currently all the layers
other than current are having same color)
- freezing of layer (currently all the layers other than
current are frozen)

Print:
to PDF will be always useful we can focus on high end
plotter/printer later

Pen asignment:
I am more used to managing print with line color
since changing lineweight of every object at later
date when we decide to take print on different size
of paper becomes difficult. But using entities lineweight
can also help.
--
Best regards

Yagnesh Desai
Save a tree...please don't print this e-mail.

-- 
Best regards

Yagnesh Desai

Save a tree...please don't print this e-mail.

Re: [Pythoncad-developer] Some working on pythoncad

From: Gertwin G. <ger...@gm...> - 2010-01-11 21:53:12

Hi Yagnesh,

> I tried to create a drawing in pythoncad
> and was testing what is it which will make
> it more useful for me.
>
> Following deficiencies was very much striking:
>
> 1. Offset command.
Yes and a lot more commands I presume (continues todo).
Would be nice if we had a person who wants to describe the commands.
We could use these descriptions for developing, testing and a user manual.
I personally prefer a all command user interface as in AutoCAD (but
not a AutoCAD clone written in python).

>
> 2. Linetype (Center, hidden, phantom, dotted).
Some external definition file which the user can define?

>
> 3. Better Layer Management.
Better in what way?
Adding layers, setting layer properties?
Mimic of AutoCAD layers?

>
> 4. Auto focus of keyboard to command line
> "any time a keyboard is hit it should
> be considered as command being given"
Correct.

>
> 5. Print. !
To what?
Paper, pdf, raster files?
Do we need a plot manager or just plot the current visible area?

>
> 6. Color wise pen assignment.
A pen?
Is it not better to use the line weights on screen and on the plot.
Than we can produce color plots.

>
> I thought of posting them before registering
> on the bugtracker.
>
> - - - - - - - - -
> Best regards
>
> Yagnesh Desai
> Save a tree...please don't print this e-mail.

Regards,
Gertwin

Re: [Pythoncad-developer] Some small points

From: Gertwin G. <ger...@gm...> - 2010-01-11 21:32:02

Hi Yagnesh,

> Matteo;
>
> If we are changing the angle measured from deg to rad
> I might need to change the code of dxf import/export of
> ARC entity as it has start angle and end angle parameters.
>
> Just infrom and it will be done.
I think the angles in dxf are also measured in degrees.
It will eliminate useless calculations if we change it to radians.

Question for you, if we want PythonCAD to have the best dxf import as
possible what do we need to change in the internal data structures.
I am not only talking about entities, also block definitions, model-,
and paperspace objects, *style and layer tables etc.
For instance PythonCAD has no blocks yet, do translate each
blockreference into a set of PythonCAD entities or is the information
lost.
Also the AutoCAD vector fonts (standard, iso etc.) if we translate
them to true type fonts the will have a shorter or longer length with
all the related problem of overlapping other objects.

It is maybe for each one of us different but what are the minimum
requirements for a good dxf import routine?
For me at least the result of the import must be visible equal, no
loss of visible elements.

Any thoughts?

>
> - - - - - -
> Best regards
>
> Yagnesh Desai
>
> Save a tree...please don't print this e-mail.

Regards,
Gertwin

Re: [Pythoncad-developer] Pushed many changes to the R38 branch

From: Gertwin G. <ger...@gm...> - 2010-01-11 21:07:56

Hi Yagnesh,

> Was testing new code pushed in R38. I found
>
> 1. The CADing area turned grey.
You are right, I have to change that.
I used this grey color to make a difference between the old drawing
methods and the new viewport drawing methods.

>
> 2. Realtime visibility of newly created entities
> is poor. ie if I create a segment or a circle I need to
> do some pan or change layers to see them.
I did not notice this, I think this is a bug.
Each object is drawn after it is added to the current layer.
I think a event is not send or handled in your situation.

>
> 3. Tried changing color of the entity it throws
> error and do not select the entity. further testing
> found I cannot select the entity to move or copy
> either.
We are in the middle of a huge code restructuring.
Do not expect PythonCAD to work as it should during this process.
I pushed the code back to the repository as soon as possible.
Entity drawing and creation of entities should work, all other must
still be adjusted.

In the previous version drawing and rubber banding was done anywhere
in the code.
It is now all concentrated in the viewport package.
All drawing is done by cairo and is easier to maintain.
It is not complete and I introduced a number of bugs, I am aware of that.

>
> I use CELERON laptop with 512 RAM.
>
> My suggestion is that python inherently would have
> some speed issue. So dynamic zoom / pan may
> be kept as user preference to switch on and off.
> I am not good at understanding this performance
> related problem and do not know if it is related
> to python or gtk.
I think the PythonCAD performance can be much better even with only python code.
I noticed a issue in the Generic package where a large amount of
memory is allocated even for a small drawing.
For me it is a challenge to get the best performance out of python.
The dynamic snap is very good at this point, now we have to streamline
the rest of PythonCAD before adding new functionality.

>
> - - - - - -
> Best regards
>
> Yagnesh Desai
> Save a tree...please don't print this e-mail.

Please continue posting your remarks.

Regrads,
Gertwin

Re: [Pythoncad-developer] Some small points

From: Yagnesh D. <yn...@gm...> - 2010-01-11 03:36:19

Matteo;

If we are changing the angle measured from deg to rad
I might need to change the code of dxf import/export of
ARC entity as it has start angle and end angle parameters.

Just infrom and it will be done.

- - - - - -
Best regards

Yagnesh Desai

Save a tree...please don't print this e-mail.

Re: [Pythoncad-developer] Pushed many changes to the R38 branch

From: Yagnesh D. <yn...@gm...> - 2010-01-11 01:55:15

Friends;

Was testing new code pushed in R38. I found

1. The CADing area turned grey.

2. Realtime visibility of newly created entities
is poor. ie if I create a segment or a circle I need to
do some pan or change layers to see them.

3. Tried changing color of the entity it throws
error and do not select the entity. further testing
found I cannot select the entity to move or copy
either.

I use CELERON laptop with 512 RAM.

My suggestion is that python inherently would have
some speed issue. So dynamic zoom / pan may
be kept as user preference to switch on and off.
I am not good at understanding this performance
related problem and do not know if it is related
to python or gtk.

- - - - - -
Best regards

Yagnesh Desai
Save a tree...please don't print this e-mail.

Re: [Pythoncad-developer] Some small points

From: Matteo B. <mat...@bo...> - 2010-01-10 21:06:17

Hi Gertwin,

> 1) In the repository there is a gtkError.py and a gtkerror.py
> (http://pythoncad.git.sourceforge.net/git/gitweb.cgi?p=pythoncad/pythoncad;a=tree;f=PythonCAD/Interface/Gtk;h=f0c84bcb2e94d8ff2a1229d922f96399bbb2cc30;hb=R38).
> On windows this can give problems, maybe it is better to give all the
> source files lower case filenames.
gtkError.py could be deleted it's an error i will do it ..
of course the file have to be all in lowercase to avoid error.

> 
> 2) Angles are internally measured in degrees, I think that this should
> be radians.
> All the math/cairo functions take radians as input parameters,
> maintaining degrees as internal values causes constant calculation
> from degrees to radians.
> If we maintain radians as the internal value only in the user
> interface a translation has to be done.

ok for me it's ok 
let the user use the degrees, internally we will convert all in radiants
and use the radiants as stadard angle mesure.

> 3) Sometimes points are defined as a tuple of two doubles and
> sometimes as a Point (object).
> This also leads to unnecessary conversions between the two.
> For me I think alway use the Point object for point is the most
> convenient.
> The point object contains functions for distance, equality etc. which
> are handy.

I notice this problem the first time i sow the pythoncad code...
using Point it's right.

but we need to modifie a lot of code.. and somtimes the touple is very
light..
may be is better to think of it before convert the touple in point.
What do you think?

Regards,
Matteo

[Pythoncad-developer] Some small points

From: <ger...@gm...> - 2010-01-10 14:40:18

Hi Matteo,

A have some small points to discuss.

1) In the repository there is a gtkError.py and a gtkerror.py  
(http://pythoncad.git.sourceforge.net/git/gitweb.cgi?p=pythoncad/pythoncad;a=tree;f=PythonCAD/Interface/Gtk;h=f0c84bcb2e94d8ff2a1229d922f96399bbb2cc30;hb=R38).
On windows this can give problems, maybe it is better to give all the  
source files lower case filenames.

2) Angles are internally measured in degrees, I think that this should be  
radians.
All the math/cairo functions take radians as input parameters, maintaining  
degrees as internal values causes constant calculation from degrees to  
radians.
If we maintain radians as the internal value only in the user interface a  
translation has to be done.

3) Sometimes points are defined as a tuple of two doubles and sometimes as  
a Point (object).
This also leads to unnecessary conversions between the two.
For me I think alway use the Point object for point is the most convenient.
The point object contains functions for distance, equality etc. which are  
handy.


Regards,
Gertwin

[Pythoncad-developer] Debugin message

From: Matteo B. <mat...@bo...> - 2010-01-10 07:41:20

Hi All,

Every time we need to have a print on the sell, please use:

print "Debug : your message"

this help the other people to understand that the message that came from
the shell is a debug and not an error.

Regards,
Matteo

[Pythoncad-developer] Some working on pythoncad

From: Yagnesh D. <yn...@gm...> - 2010-01-09 15:54:53

Friends;

I tried to create a drawing in pythoncad
and was testing what is it which will make
it more useful for me.

Following deficiencies was very much striking:

1. Offset command.

2. Linetype (Center, hidden, phantom, dotted).

3. Better Layer Management.

4. Auto focus of keyboard to command line
"any time a keyboard is hit it should
be considered as command being given"

5. Print. !

6. Color wise pen assignment.

I thought of posting them before registering
on the bugtracker.

- - - - - - - - -
Best regards

Yagnesh Desai
Save a tree...please don't print this e-mail.

Re: [Pythoncad-developer] Pushed many changes to the R38 branch

From: <ger...@gm...> - 2010-01-09 13:09:11

Hi Matteo,

I did not do a thorough test on my submitted code, so there are bugs in it.
If you find a bug and repaired it please push the changes back to the  
repository.

The file which gives me performance problems is "8th floor furniture.dxf",  
it is already in git.
I don't think the import of dxf is the problem, the problem remains even  
after saving to the PythonCAD xml format.
In native PythonCAD format the file "8th floor furniture.xml.gz" has a  
filesize of 850 kb (and still the same memory usage).
I will also push a larger dxf file (9 mb) to the repository, it contain  
xdata which gives an exception while loading.
Maybe you can use this file to test dxf import.

We can start with two threads, one separate for background processes like  
loading drawings/dxf and rendering and one for the user interface.
This will keep the user interface "alive" during long processes.

Maybe scaling of the image is a solution for mouse wheel zoom.
But a redraw is needed at the end just like with pan.

I looked into the way the entites are stored within the image/layer, this  
is very complex with many callback functions, relations and undo objects  
bound to every entity.
I have to investigate this more but maybe this is the source of the memory  
consumption.
If I have a clear view of how the image/layer/entity structures are  
organized I make a document of it and push it to the repository.
After that we can discuss where we think the bottle neck is.

Your remark about using a db is interesting.
A sqlite db can be used in memory and we have to write/maintain less code.

Regards,
Gertwin








On Jan 9, 2010 9:29am, Matteo Boscolo <mat...@bo...> wrote:
> Hi Gertwin,



> >

> > Draw functionality like segment, circle, polyline etc. should work,

> > text and dimension not.

> >

> I found an error in the gtkImage:

> the init collection is defined as

> __inittool = {

> Tools.PasteTool : cmd.paste_mode_init,

> this is not right,

> the method that set the tool:



> def __imageToolChanged(self, obj, *args):

> _tool = self.__image.getTool()

> if _tool is not None:

> _init = GTKImage.__inittool.get(type(_tool))

> #here the _init is none because the tool is

> #Tools.paste_tool.PasteTool

> if _init is not None:

> _init(self)



> __inittool = {

> Tools.paste_tool.PasteTool : cmd.paste_mode_init,



> I have done this fix in my local repository and now it works well.

> let me know witch is the difference in your code ...

> I wold like to commit this change but i do not understand why your code

> works fine en i get this errors !?!?



> >

> > At this point I did not expect a performance improvement for redraw.

> > The method of drawing is basically the same as it was except that is

> > now done by a few functions in viewport.py.

> ok me too





> > Panning works only from the menu at this point, not with the mouse

> > buttons.

> After some tests it look very fast even if with a lot of entity in the

> drawing.



> > The rendering is now done to a pixmap and not directly to the screen.

> > When panning the pixmap is moved around the screen without the need of

> > a redraw.

> > When panning stops a redraw is needed for the visible area of the

> > drawing.

> >

> > The only thing I did until now was a rewrite of the rendering, all it

> > is now all done by cairo.

> > I did not expect the dxf import was faster (except maybe for rendering

> > at the end).

> me to ..



> > The strange messages when closing PythonCAD I don't know where the

> > came from.

> I still have some strange message even if i draw entity and zooming ...

> may be we have to make some fix on it ..



> > I am not aware of any changes in that area.

> > I think they are from the image class disposing entities from layers,

> > this cost a very long time with large drawings.

> >

> > Last night I did some more thinking on how display performance can be

> > improved.

> > One thing is that when a redraw is done all entites are queried from

> > the image class and rendered on the pixmap canvas.

> > I think getting the coordinates from the entities and translate them

> > to cairo paths cost some time.

> > Also PythonCAD itself does the mapping from world to screen

> > coordinates (without the use of the cairo matrix).

> > Maybe a large performance gain can be achieved if we once query the

> > entities and store the cairo rendering paths in lists.

> > If we make use of the cairo transformation matrix for zooming and

> > translation we only have to replay the paths in the lists without

> > accessing the individual entities.

> > This is a little like the opengl display lists work.

> It seems an clever idea we can do some tests on it ..

> I can look in deep to the pytoncad entity and try to find a solution.

> may be we can optimize the way haw pythoncad get the entity.

> Using a db will be a solution !?!?!



> >

> > At this point I am most concerned about the large memory consumption

> > and the time needed to unload (garbage collection?) a drawing from

> > PytonCAD.

> > I posted this a week ago on the pythoncad-developer list, a small dxf

> > file leads to a memory use of almost 1GB.

> Witch dxf file ? could you please commit it in the doc folder on git ?

> I would like to make some tests.



> During dxf import I create an array to store all the error that we find

> in the dxf file. may be we do not destroy in a well manner the obj that

> read the dxf..





> >

> > I know PythonCAD is now a single threaded application which uses only

> > one of my the available cpu cores.

> > But don't you think stuff will be much more difficult when we go multi

> > threaded?

> >

> Of course but all the new cad system works with multi tread ..

> so it will be nice to have such a functionality .. so we can have batch

> working ..es (When Solidworks create the drawing view or open a big 3d

> assembly it use the multitread system for generete the view or the

> hystory tree of the assembly).

> I'm not so skilled in multi thread application, but i can do some test..





> > I think first we must get the core (generic + rendering) right before

> > adding new functionality.

> right

> > Maybe we can first look at this and decide what to do to get this

> > right.

> ok.



> I think that the pan is very fast .

> I did some test importing more then one dxf file(it means a lot of

> entity) and the pan working fast.

> The well zoom is still working slow may be there is to match redraw (one

> for each step?).

> It's possible to scale the pixmap insted of redraw the entire drawing

> area?





> > We can always rewrite the package Generic + rendering in C/C++ as an

> > dynamic python extension library (just a thought).

> I agree with you, but we need to have all the basic feature ready ..

> and a well defined structure of the core application before translate

> the code in c/c++.



> > The Interface package and the dxf/dwg import/export can remain in

> > python.

> >

> > If you find some time the next days please look the the performance

> > and memory consumption of loading/unloading drawings.

> ok i will do some test an let you know

> > I will do the same, we can discuss these things on the

> > python-developer mailing list and hopefully also get some input from

> > others.



> Regards,

> Matteo

Re: [Pythoncad-developer] Pushed many changes to the R38 branch

From: Matteo B. <mat...@bo...> - 2010-01-09 08:30:07

Hi Gertwin,

> 
> Draw functionality like segment, circle, polyline etc. should work,
> text and dimension not.
> 
I found an error in the gtkImage:
the init collection is defined as 
__inittool = {
        Tools.PasteTool : cmd.paste_mode_init,
this is not right, 
the method that set the tool:

    def __imageToolChanged(self, obj, *args):
        _tool = self.__image.getTool()
        if _tool is not None:
            _init = GTKImage.__inittool.get(type(_tool))
            #here the _init is none because the tool is 
            #Tools.paste_tool.PasteTool
     if _init is not None:
                _init(self)

__inittool = {
        Tools.paste_tool.PasteTool : cmd.paste_mode_init,

I have done this fix in my local repository and now it works well.
let me know witch is the difference in your  code ... 
I wold like to commit this change but i do not understand why your code
works fine en i get this errors !?!?

> 
> At this point I did not expect a performance improvement for redraw.
> The method of drawing is basically the same as it was except that is
> now done by a few functions in viewport.py.
ok me too


> Panning works only from the menu at this point, not with the mouse
> buttons.
After some tests it look very fast even if with a lot of entity in the
drawing.

> The rendering is now done to a pixmap and not directly to the screen.
> When panning the pixmap is moved around the screen without the need of
> a redraw.
> When panning stops a redraw is needed for the visible area of the
> drawing.
> 
> The only thing I did until now was a rewrite of the rendering, all it
> is now all done by cairo.
> I did not expect the dxf import was faster (except maybe for rendering
> at the end).
me to .. 

> The strange messages when closing PythonCAD I don't know where the
> came from.
I still have some strange message even if i draw entity and zooming ...
may be we have to make some fix on it ..

> I am not aware of any changes in that area.
> I think they are from the image class disposing entities from layers,
> this cost a very long time with large drawings.
> 
> Last night I did some more thinking on how display performance can be
> improved.
> One thing is that when a redraw is done all entites are queried from
> the image class and rendered on the pixmap canvas.
> I think getting the coordinates from the entities and translate them
> to cairo paths cost some time.
> Also PythonCAD itself does the mapping from world to screen
> coordinates (without the use of the cairo matrix).
> Maybe a large performance gain can be achieved if we once query the
> entities and store the cairo rendering paths in lists.
> If we make use of the cairo transformation matrix for zooming and
> translation we only have to replay the paths in the lists without
> accessing the individual entities.
> This is a little like the opengl display lists work.
It seems an clever idea we can do some tests on it ..
I can look in deep  to the pytoncad entity and try to find a solution.
may be we can optimize the way haw pythoncad get the entity.
Using a db will be a solution !?!?!

> 
> At this point I am most concerned about the large memory consumption
> and the time needed to unload (garbage collection?) a drawing from
> PytonCAD.
> I posted this a week ago on the pythoncad-developer list, a small dxf
> file leads to a memory use of almost 1GB.
Witch dxf file ? could you please commit it in the doc folder on git ?
I would like to make some tests.

During dxf import I create an array to store all the error that we find
in the dxf file. may be we do not destroy in a well manner the obj that
read the dxf..


> 
> I know PythonCAD is now a single threaded application which uses only
> one of my the available cpu cores.
> But don't you think stuff will be much more difficult when we go multi
> threaded?
> 
Of course but all the new cad system works with multi tread ..
so it will be nice to have such a functionality .. so we can have batch
working ..es (When Solidworks create the drawing view or open a big 3d
assembly it use the multitread system for generete the view or the
hystory tree of the assembly).
I'm not so skilled in multi thread application, but i can do some test..


> I think first we must get the core (generic + rendering) right before
> adding new functionality.
right
> Maybe we can first look at this and decide what to do to get this
> right.
ok.

I think that the pan is very fast .
I did some test importing more then one dxf file(it means a lot of
entity) and the pan working fast.
The well zoom is still working slow may be there is to match redraw (one
for each step?).
It's possible to scale the pixmap insted of redraw the entire drawing
area?


> We can always rewrite the package Generic + rendering in C/C++ as an
> dynamic python extension library (just a thought).
I agree with you, but we need to have all the basic feature ready ..
and a well defined structure of the core application before translate
the code in c/c++.

> The Interface package and the dxf/dwg import/export can remain in
> python.
> 
> If you find some time the next days please look the the performance
> and memory consumption of loading/unloading drawings.
ok i will do some test an let you know
> I will do the same, we can discuss these things on the
> python-developer mailing list and hopefully also get some input from
> others.

Regards,
Matteo

Re: [Pythoncad-developer] Pushed many changes to the R38 branch

From: <ger...@gm...> - 2010-01-08 15:33:06

Hi Matteo,

Draw functionality like segment, circle, polyline etc. should work, text  
and dimension not.

At this point I did not expect a performance improvement for redraw.
The method of drawing is basically the same as it was except that is now  
done by a few functions in viewport.py.

Panning works only from the menu at this point, not with the mouse buttons.
The rendering is now done to a pixmap and not directly to the screen.
When panning the pixmap is moved around the screen without the need of a  
redraw.
When panning stops a redraw is needed for the visible area of the drawing.

The only thing I did until now was a rewrite of the rendering, all it is  
now all done by cairo.
I did not expect the dxf import was faster (except maybe for rendering at  
the end).

The strange messages when closing PythonCAD I don't know where the came  
from.
I am not aware of any changes in that area.
I think they are from the image class disposing entities from layers, this  
cost a very long time with large drawings.

Last night I did some more thinking on how display performance can be  
improved.
One thing is that when a redraw is done all entites are queried from the  
image class and rendered on the pixmap canvas.
I think getting the coordinates from the entities and translate them to  
cairo paths cost some time.
Also PythonCAD itself does the mapping from world to screen coordinates  
(without the use of the cairo matrix).
Maybe a large performance gain can be achieved if we once query the  
entities and store the cairo rendering paths in lists.
If we make use of the cairo transformation matrix for zooming and  
translation we only have to replay the paths in the lists without accessing  
the individual entities.
This is a little like the opengl display lists work.

At this point I am most concerned about the large memory consumption and  
the time needed to unload (garbage collection?) a drawing from PytonCAD.
I posted this a week ago on the pythoncad-developer list, a small dxf file  
leads to a memory use of almost 1GB.

I know PythonCAD is now a single threaded application which uses only one  
of my the available cpu cores.
But don't you think stuff will be much more difficult when we go multi  
threaded?

I think first we must get the core (generic + rendering) right before  
adding new functionality.
Maybe we can first look at this and decide what to do to get this right.

We can always rewrite the package Generic + rendering in C/C++ as an  
dynamic python extension library (just a thought).
The Interface package and the dxf/dwg import/export can remain in python.

If you find some time the next days please look the the performance and  
memory consumption of loading/unloading drawings.
I will do the same, we can discuss these things on the python-developer  
mailing list and hopefully also get some input from others.

Regards,
Gertwin

Op schreef Matteo Boscolo <mat...@bo...>:
> Hi Gertwin,

> I've done some test and is seems to go faster then the previous version.

> It's hard to make some test without some drawing functionality like

> lines circles ....

> I've done some tests importing the dxf files under doc folder and it

> seems faster then the older system but not as much as I expected.

> In my installation the pan mouse functionality dose not work.

> And i get some strange message when i close PythonCad

> __imageRemovedChild

> remaining connections for obj:
> 0x97a1d6c>

> message: added_child

> connected to obj:
> 0x97ab68c>

> message: removed_child

> connected to obj:
> 0x97ab68c>

> >At least the panning is faster now (but after pan a redraw it needed

> >which can be slow for large drawings).

> Could be use Tread for beach Redraw ? so the user can work and in the

> batch mode we get the redraw.

> I made some Test with treading while importing dxf file but i get some

> bad error and i stop developing it.

> I can make some test on it to get it work ..

> >I think for really good performance you need display lists as used in

> >opengl.

> We can think of it .. i like to do e good job and performance in

> zooming/redrawing are very important in a cad program.

> So if you think that the display list will be the right choice.. we can

> work on it we can share the work.

> Regards,

> Matteo

> On Thu, 2010-01-07 at 22:26 +0000, ger...@gm... wrote:

> > Hello,

> >

> > I just pushed many changed into the R38 repository.

> >

> > This means the old drawing methods are mostly replaced by the new

> > cairo ones.

> > All draw functions (entity draw and rubberbanding and future selection

> > draw) are now in the draw.py modules.

> >

> > Not all entity draw functions are replaced by new ones, I will convert

> > them one by one the next days.

> > There are issues with drawings when a very large part of the entity is

> > off screen (maybe need some clipping).

> > There are issues with rubberbanding which can be slow at some times

> > (after dynamic zoom with mouse wheel while drawing).

> > Mouse wheel zoom is pointer position sensitive, zooming is done around

> > the mouse pointer and not screen center.

> >

> > At this stage the cairo drawing should give a good indication of the

> > performance which can be achieved.

> > I have not done any optimizations but I don't think it will be more

> > than 1.5x faster as it is now.

> > At least the panning is faster now (but after pan a redraw it needed

> > which can be slow for large drawings).

> > Also each dynamic zoom with the wheel mouse button requires a redraw.

> > When zoomed into a small part of the drawing less entities are drawn

> > than redraw is faster, whole drawing redraw is still slow.

> >

> > Please look at the drawing performance and share your feelings (is it

> > fast enough, does it need changes).

> > I think for really good performance you need display lists as used in

> > opengl.

> >

> > Regards,

> > Gertwin

Re: [Pythoncad-developer] Pushed many changes to the R38 branch

From: Matteo B. <mat...@bo...> - 2010-01-08 09:57:46

Hi Gertwin,
I've done some test and is seems to go faster then the previous version.

It's hard to make some test without some drawing functionality like
lines circles ....

I've done some tests importing the dxf files under doc folder and it
seems faster then the older system but not as much as I expected.

In my installation the pan mouse functionality dose not work.
And i get some strange message when i close PythonCad

__imageRemovedChild
remaining connections for obj: <PythonCAD.Generic.layer.Layer object at
0x97a1d6c>
message: added_child
connected to obj: <PythonCAD.Interface.Gtk.gtkimage.GTKImage object at
0x97ab68c>
message: removed_child
connected to obj: <PythonCAD.Interface.Gtk.gtkimage.GTKImage object at
0x97ab68c>

>At least the panning is faster now (but after pan a redraw it needed
>which can be slow for large drawings).

Could be use Tread for beach Redraw ? so the user can work and in the
batch mode we get the redraw.
I made some Test with treading while importing dxf file but i get some
bad error and i stop developing it.
I can make some test on it to get it work ..

>I think for really good performance you need display lists as used in
>opengl.

We can think of it .. i like to do e good job and performance in
zooming/redrawing are very important in a cad program.
So if you think that the display list will be the right choice.. we can
work on it we can share the work.

Regards,
Matteo

On Thu, 2010-01-07 at 22:26 +0000, ger...@gm... wrote:
> Hello,
> 
> I just pushed many changed into the R38 repository.
> 
> This means the old drawing methods are mostly replaced by the new
> cairo ones.
> All draw functions (entity draw and rubberbanding and future selection
> draw) are now in the <entity>draw.py modules.
> 
> Not all entity draw functions are replaced by new ones, I will convert
> them one by one the next days.
> There are issues with drawings when a very large part of the entity is
> off screen (maybe need some clipping).
> There are issues with rubberbanding which can be slow at some times
> (after dynamic zoom with mouse wheel while drawing).
> Mouse wheel zoom is pointer position sensitive, zooming is done around
> the mouse pointer and not screen center. 
> 
> At this stage the cairo drawing should give a good indication of the
> performance which can be achieved.
> I have not done any optimizations but I don't think it will be more
> than 1.5x faster as it is now.
> At least the panning is faster now (but after pan a redraw it needed
> which can be slow for large drawings).
> Also each dynamic zoom with the wheel mouse button requires a redraw.
> When zoomed into a small part of the drawing less entities are drawn
> than redraw is faster, whole drawing redraw is still slow.
> 
> Please look at the drawing performance and share your feelings (is it
> fast enough, does it need changes).
> I think for really good performance you need display lists as used in
> opengl.
> 
> Regards,
> Gertwin

2 messages has been excluded from this view by a project administrator.

Flat | Threaded

<< < 1 .. 14 15 16 17 > >> (Page 16 of 17)