-
Notifications
You must be signed in to change notification settings - Fork 251
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
Different IPython interface #36
Comments
Sorry for the late reply, I'm kinda swamped with work in the last few weeks. Is this patch for IPython? Would this mechanism simply replace the existing For what it's worth, others have also reported problems with the SVG rendering, although not from the performance side - it seems like the SVG plots embedded in an IPython notebook do not render the vertex labels properly, so I'm very interested in finding a solution that allows the user to at least configure what format the plots are sent to the IPython backend, and I'm happy to make PNG the default if it solves the performance problems. |
No problem. This could replace the current If you want to have a different format, simple call If 'enable on import' is too much, this could also become a user action, much like As a sidenote: if you only want to switch to png, the easiest would be to add this method to def _repr_png_(self):
"""returns a PNG representation of this plot as a string.
This method is used by IPython to display this plot inline.
"""
surface = cairo.ImageSurface(cairo.FORMAT_ARGB32, int(self.bbox.width), int(self.bbox.height))
context = cairo.Context(surface)
# Plot the graph on this context
self.redraw(context)
io = BytesIO()
surface.write_to_png(io)
# Return the raw SVG representation
return io.getvalue() [EDIT: wrong, it will call all magic methods available] |
I have tried an implementation of I'm on holiday until the end of this week so let me revisit this thread early next week. I definitely like the idea, but I'd rather try to find a solution where we use the standard configuration mechanism of python-igraph (see the Anyway, thanks for the idea and the code samples - I'll definitely get back to this and implement it somehow in the next release. If you feel like doing so, you can fork the master branch of the repo and merge your code into the forked branch, and then I'll revisit your branch once I'm back from holidays. |
I won't have time to work on this until friday next week, so no problem... Ok, just looked it up: IPython will call all magic methods which are available (so One way to work around this implementing something that makes Oh, and this should also work: raise a But I feel that the above way with an explicit formatter for The main obstacle in setting image sizes is that currently the final size is added to the plot during |
So, would it be acceptable to remove |
Yes, removing |
Another question: I would like to remove the hack in the patch by pushing the size calculations from the |
Yes, it is also acceptable. |
Now that matplotlib is an accepted plotting engine for python-igraph, you can use its PNG (or other) static raster backends to achieve this. I'd be for closing this one and telling people to use mpl. But @ntamas this is just my personal preference. |
Let's go back to the beginning of this thread. If I understand correctly, the original motivation for this patch was this:
The question is: is this still a problem, and if it is, is this solved with the Matplotlib backend? If Matplotlib solves this, then we can safely close this issue. Otherwise we should attempt to find a solution somehow, first by figuring out where the performance bottleneck is. From a cursory look at the original proposal, it still draws the graph through Cairo by the usual means but avoids jumping through a few hoops, so the original performance bottleneck is somewhere in the machinery around the Cairo plotting and not in Cairo itself. |
Might be worth mentioning that we are considering switching to matplotlib as default. Mpl deals with backends (e.g. PNG/SVG) quite flexibly and is generally quite well integrated with notebooks and ipython as well, so if we transition we might end up in the same boat as many other libraries in terms of performance: might not support billions of nodes, but it will let the user choose the backend at will. |
I've found that the svg rendering becomes a real performance hog when the plotted graph gets big.
I've build the following functions, which are enabled similar to the version which manages the image plotting of matplotlib figures:
Usage:
Would you take such a patch?
The text was updated successfully, but these errors were encountered: