extgraph-developer

[Extgraph-developer] Improved drawing of zoomed canvas etc.

[Phil S. <p.s...@gn...>]

Hi. I have joined Extgraph list as busy hacking SimpleGraph for my own
application. Added jointed links and also a host of new node types for
my application.

However, I have got to an issue that might be of general interest. 
Simplegraph has relatively involved painting method. It paints to a bitmap
which is then bitlblt to the canvas. This has a few downsides, particularly
in that as you zoom in, instead of seeing more text, text is simply 
enlarged, lines are thickened etc. I want to zoom so that can see more text 
and keep lines at same weight.  I also looked at less involved way of 
painting but see that it is done because zoom method includes arbitary
rounding. This can be avoided but developer perhaps didn't spot it. I tried
with setworldTransform or setviewport setwindowextext calls but hit the
rounding issue as the code is structured at the moment.

Proper scaling on zoom requires transforming the graph coords by
x' = x*scale + scaledoffset. To avoid problem with rounding, think the
actual calculation is
x' = muldiv(x,M,D) + offset, where M is max(clientHeight, clientwidth) and
D is M*100/Zoom percent

The easier way to introduce this scaling would be a derivative of
TCanvas say TScaleableCanvas with overriddern draw methods to scale
the x,y coordinates before calling inherited draw methods.

Sadly this approach is no go. MoveTo, LineTo etc etc are static methods
in TCanvas. You can replace with static MoveTo, LineTo, but then the
drawing calls have to reference TScaleCanvas to the replaced method.
Once you do this, you cant pass TMetafileCanvas or Printer.Canvas to
the draw methods. 

Unless someone has a better idea, I think the only way to achieve what I
want is explicit scaling of coordinates in the drawing calls. This would a
big impact on ExtGraph, perhaps rather more than you would want.


----------------------------------------------------------
Phil Scadden, Institute of Geological and Nuclear Sciences
764 Cumberland St, Private Bag 1930, Dunedin, New Zealand
Ph +64 3 4799663, fax +64 3 477 5232

RE: [Extgraph-developer] Improved drawing of zoomed canvas etc.

[vrecion <pav...@sy...>]

Dear Phill,
Thanks for your remarks and recommendations. We will try to implement it
future versions.

It will be interesting for us to know, which extensions you have made, not
only for inspiration. Maybe they can be useful also for other users. 

Pavel

-----Original Message-----
From: ext...@li...
[mailto:ext...@li...] On Behalf Of Phil
Scadden
Sent: Tuesday, March 15, 2005 2:38 AM
To: ext...@li...
Subject: [Extgraph-developer] Improved drawing of zoomed canvas etc.

Hi. I have joined Extgraph list as busy hacking SimpleGraph for my own
application. Added jointed links and also a host of new node types for
my application.

However, I have got to an issue that might be of general interest. 
Simplegraph has relatively involved painting method. It paints to a bitmap
which is then bitlblt to the canvas. This has a few downsides, particularly
in that as you zoom in, instead of seeing more text, text is simply 
enlarged, lines are thickened etc. I want to zoom so that can see more text 
and keep lines at same weight.  I also looked at less involved way of 
painting but see that it is done because zoom method includes arbitary
rounding. This can be avoided but developer perhaps didn't spot it. I tried
with setworldTransform or setviewport setwindowextext calls but hit the
rounding issue as the code is structured at the moment.

Proper scaling on zoom requires transforming the graph coords by
x' = x*scale + scaledoffset. To avoid problem with rounding, think the
actual calculation is
x' = muldiv(x,M,D) + offset, where M is max(clientHeight, clientwidth) and
D is M*100/Zoom percent

The easier way to introduce this scaling would be a derivative of
TCanvas say TScaleableCanvas with overriddern draw methods to scale
the x,y coordinates before calling inherited draw methods.

Sadly this approach is no go. MoveTo, LineTo etc etc are static methods
in TCanvas. You can replace with static MoveTo, LineTo, but then the
drawing calls have to reference TScaleCanvas to the replaced method.
Once you do this, you cant pass TMetafileCanvas or Printer.Canvas to
the draw methods. 

Unless someone has a better idea, I think the only way to achieve what I
want is explicit scaling of coordinates in the drawing calls. This would a
big impact on ExtGraph, perhaps rather more than you would want.


----------------------------------------------------------
Phil Scadden, Institute of Geological and Nuclear Sciences
764 Cumberland St, Private Bag 1930, Dunedin, New Zealand
Ph +64 3 4799663, fax +64 3 477 5232



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Extgraph-developer mailing list
Ext...@li...
https://lists.sourceforge.net/lists/listinfo/extgraph-developer

[Extgraph-developer] Changes I've made (Was Improved drawing zoomed canvas)

[Phil S. <p.s...@gn...>]

> It will be interesting for us to know, which extensions you have made, not
> only for inspiration. Maybe they can be useful also for other users. 

Okay. My application is drawing thermodynamic schematic of a power plant,
which can be reduced to components linked in a planar graph (more or
less). To this end, I have extended graphlink and nodes with the huge no.
of properties required to characterize them. Obviously of no interest to
anyway else. Likewise I have add many different node types to cover the
standard symbols for pump, turbine etc. These have to be custom rather
than graphic because there are conventions concerning where a link may
join them. I did briefly consider generalising this. This would require a 
node to have a property listing allowed link points. Even more complicated
though for my application because entering link points are different from
exiting link points.

Of more general use is jointed link, but I confess that I hacked this by 
simply adding a midpoint property to link. When link is made, it calculates 
to the midpoint, but allows the moving of this node to anywhere so link can
do strong right-angle bends. Bezier links that I see are added address the
same problem more generally, but again, I have convention to follow. The
implementation changes a lot of core code

Finally I added export to couple of plane-graph representations. This is so 
I can feed a schematic into plane-graph optimiser program, get new node
positions and then read back. This is utter hack, never intended to be more
than a one-off exercise but is potentially a useful kind of extension.

----------------------------------------------------------
Phil Scadden, Institute of Geological and Nuclear Sciences
764 Cumberland St, Private Bag 1930, Dunedin, New Zealand
Ph +64 3 4799663, fax +64 3 477 5232

RE: [Extgraph-developer] Changes I've made (Was Improved drawing zoomed canvas)

[Phil S. <p.s...@gn...>]

Okay, will do, but not immediately.

Oh and yet another one. Components are heirachical. Ie a node might
internally consist of a collection of nodes (which in turn can be made of
smaller nodes). So aggregation and hiding are added bits. For planar
graphs, you can manage this very easily by maintaining an incidence
matrix. This allows you quickly calculate link to a supernode from the
subnode links.


----------------------------------------------------------
Phil Scadden, Institute of Geological and Nuclear Sciences
764 Cumberland St, Private Bag 1930, Dunedin, New Zealand
Ph +64 3 4799663, fax +64 3 477 5232

Re: [Extgraph-developer] Changes I've made (Was Improved drawing zoomed canvas)

[Marco W. <in...@ca...>]

The current code (yet not released) contains implementations for Nodes 
to have a Parent. This allows similar behaviour as you describe. In 
addition I have added some methods on the Node which can disable or 
enable clicking on it's ChildNodes. Similarly moving a Node will move 
all children, Visible and Lock will also be derivable over Parent Child 
relations.

Marco.

Phil Scadden wrote:

>Okay, will do, but not immediately.
>
>Oh and yet another one. Components are heirachical. Ie a node might
>internally consist of a collection of nodes (which in turn can be made of
>smaller nodes). So aggregation and hiding are added bits. For planar
>graphs, you can manage this very easily by maintaining an incidence
>matrix. This allows you quickly calculate link to a supernode from the
>subnode links.
>
>
>----------------------------------------------------------
>Phil Scadden, Institute of Geological and Nuclear Sciences
>764 Cumberland St, Private Bag 1930, Dunedin, New Zealand
>Ph +64 3 4799663, fax +64 3 477 5232
>
>
>
>-------------------------------------------------------
>SF email is sponsored by - The IT Product Guide
>Read honest & candid reviews on hundreds of IT Products from real users.
>Discover which products truly live up to the hype. Start reading now.
>http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
>_______________________________________________
>Extgraph-developer mailing list
>Ext...@li...
>https://lists.sourceforge.net/lists/listinfo/extgraph-developer
>
>
>
>  
>

Re: [Extgraph-developer] Changes I've made (Was Improved drawing zoomed canvas)

[Marco W. <in...@ca...>]

Response below....

Phil Scadden wrote:

>>It will be interesting for us to know, which extensions you have made, not
>>only for inspiration. Maybe they can be useful also for other users. 
>>    
>>
>
>Okay. My application is drawing thermodynamic schematic of a power plant,
>which can be reduced to components linked in a planar graph (more or
>less). To this end, I have extended graphlink and nodes with the huge no.
>of properties required to characterize them. Obviously of no interest to
>anyway else. Likewise I have add many different node types to cover the
>standard symbols for pump, turbine etc. These have to be custom rather
>than graphic because there are conventions concerning where a link may
>join them. I did briefly consider generalising this. This would require a 
>node to have a property listing allowed link points. Even more complicated
>though for my application because entering link points are different from
>exiting link points.
>  
>
I've got similar requirements. However I use a information repository in 
a database. Once a node is placed onto the diagram it links up other 
nodes itself depending on the information in the database.

>Of more general use is jointed link, but I confess that I hacked this by 
>simply adding a midpoint property to link. When link is made, it calculates 
>to the midpoint, but allows the moving of this node to anywhere so link can
>do strong right-angle bends. Bezier links that I see are added address the
>same problem more generally, but again, I have convention to follow. The
>implementation changes a lot of core code
>
>Finally I added export to couple of plane-graph representations. This is so 
>I can feed a schematic into plane-graph optimiser program, get new node
>positions and then read back. This is utter hack, never intended to be more
>than a one-off exercise but is potentially a useful kind of extension.
>  
>
Using undirected graph engines is what I've been using. Similar things 
as you describe here. Perhaps we should allow an export to such a 
format. Are you using publicly available engines or some custom build ones?

Marco.