Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Separate parsing from rendering #60

Open
GoogleCodeExporter opened this issue Feb 12, 2016 · 6 comments
Open

Separate parsing from rendering #60

GoogleCodeExporter opened this issue Feb 12, 2016 · 6 comments

Comments

@GoogleCodeExporter
Copy link

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
Copy link
Author

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

  • Added labels: Type-Enhancement
  • Removed labels: Type-Defect

@GoogleCodeExporter
Copy link
Author

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
Copy link
Author

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
Copy link
Author

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
Copy link
Author

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
Copy link
Author

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant