Issue 60 in canviz: Separate parsing from rendering
can...@googlecode.com
Owner: ----
Labels: Type-Defect Priority-Medium
New issue 60 by charlie....@clark-consulting.eu: Separate parsing from
rendering
http://code.google.com/p/canviz/issues/detail?id=60
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.
--
You received this message because you are listed in the owner
or CC fields of this issue, or because you starred this issue.
You may adjust your issue notification preferences at:
http://code.google.com/hosting/settings
can...@googlecode.com
Labels: -Type-Defect Type-Enhancement
Comment #1 on issue 60 by ryandesign.com: Separate parsing from rendering
http://code.google.com/p/canviz/issues/detail?id=60
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.
can...@googlecode.com
Comment #2 on issue 60 by charlie....@clark-consulting.eu: Separate parsing
from rendering
http://code.google.com/p/canviz/issues/detail?id=60
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.
can...@googlecode.com
Comment #3 on issue 60 by ryandesign.com: Separate parsing from rendering
http://code.google.com/p/canviz/issues/detail?id=60
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?
can...@googlecode.com
Comment #4 on issue 60 by charlie....@clark-consulting.eu: Separate parsing
from rendering
http://code.google.com/p/canviz/issues/detail?id=60
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.
can...@googlecode.com
Comment #5 on issue 60 by ryandesign.com: Separate parsing from rendering
http://code.google.com/p/canviz/issues/detail?id=60
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.
can...@googlecode.com
Comment #6 on issue 60 by charlie....@clark-consulting.eu: Separate parsing
from rendering
http://code.google.com/p/canviz/issues/detail?id=60
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.