lourenzo / canviz

Automatically exported from code.google.com/p/canviz
0 stars 0 forks source link

Separate parsing from rendering #60

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago
I think canviz is great but I was wondering if wouldn't be desirable to 
separate out parsing from rendering. Apart from hopefully improving 
performance as parsing isn't something JS excels at this might lead to a 
module for Graphviz to generate the relevant Canvas code directly, so 
hopefully reducing the amount of code to maintain in Canviz

I would be happy to write a reference implementation in Python. But from 
what I have seen of the Javascript this isn't directly possible at the 
moment.

Original issue reported on code.google.com by charlie....@clark-consulting.eu on 24 Mar 2010 at 11:25

GoogleCodeExporter commented 9 years ago
The parsing of the xdot file (Canviz.parse()) is already separate from the 
drawing (Canviz.draw()); drawing the 
graph repeatedly will not need to re-parse the xdot file. However, it's true 
that parsing the draw attributes 
(CanvizEntity.parseDrawingCommands()) is done every time the graph is drawn, 
and I do want to take that out 
and make it happen only once at graph loading time, by converting the drawing 
commands into Path objects. I 
appear not to have filed a ticket for this before so thanks for doing so.

Original comment by ryandesi...@gmail.com on 24 Mar 2010 at 5:42

GoogleCodeExporter commented 9 years ago
Great. I'll see if I can whip up a Python version of the parser producing 
"canviz" 
so that this can be used if desired.

Original comment by charlie....@clark-consulting.eu on 24 Mar 2010 at 6:37

GoogleCodeExporter commented 9 years ago
I'm not certain what you mean for this to do. I consider Canviz a client-side 
in-browser xdot renderer, agnostic 
of any server-side scripting language that may be in use to build the graph and 
feed it to Graphviz. Though I 
have considered a server-side script for converting xdot into a more-efficient 
JSON representation for over-the-
wire transmission; see issue #56. Is this what you're thinking of? Or, what 
kind of output are you thinking your 
Python script would generate?

Original comment by ryandesi...@gmail.com on 24 Mar 2010 at 10:38

GoogleCodeExporter commented 9 years ago
I think we're on the same lines - I wasn't sure whether the representation 
would be 
JSON or something Canvas-specific - it should just be possible to generate it 
outside of Canviz.

You're right, of course, that it should be possible to generate the JSON 
directly 
from a graph structure without an xdot intermediary. I've always generated dot 
code 
node-by-node and let Graphviz handle the target formats. Once the format is 
defined 
it would be easy possible to make it a target for Graphviz in situations where 
as 
much as possible should happen on the server.

Original comment by charlie....@clark-consulting.eu on 24 Mar 2010 at 10:49

GoogleCodeExporter commented 9 years ago
Well, the Graphviz developers have mentioned thinking about having a JSON 
output format built into Graphviz. 
But until they do, I see no alternative but to have Graphviz generate xdot, 
then writing a script to turn the xdot 
into JSON. Thinking back to prior discussions, I think I remember now that the 
concern wasn't the size of the 
output, but the processing time for the browser to read the xdot.

Original comment by ryandesi...@gmail.com on 25 Mar 2010 at 12:58

GoogleCodeExporter commented 9 years ago
That is my concern as well. For interactive graph manipulation there probably 
isn't 
anyway around this but I imagine there will be many cases where server-side 
parsing 
will be of significant benefit.

Original comment by charlie....@clark-consulting.eu on 25 Mar 2010 at 10:23