Graph layout rendering issues with media-heavy nodes?

1

Hi everyone, hope you’re doing well.

I’m running into an issue where some graphviz diagrams start behaving oddly once I include nodes that reference heavier media or external resources. Layouts sometimes take longer to render, edges overlap unexpectedly, or the output changes slightly between renders even when the graph definition stays the same.

It reminded me of a conversation I saw about handling large media assets and temporary files during processing, similar to cases discussed around video editor apk files causing extra load. That made me wonder if resource handling or caching could indirectly affect how graphviz processes or renders complex graphs.

So my question is — when graphviz layouts become inconsistent or slow with more complex node content, do you usually look at memory limits, rendering engines, or input preprocessing first? Any tips for isolating whether it’s the graph structure itself or external resource handling causing the issue?

Thanks in advance for any guidance!

4

Can you share the graph input?

5

I couldn’t believe this can happen. Last night I was chatting with a friend who uses Gemini, and it said to investigate the cache in lib/gvc/gvusershape.c

The cache size is set here.

It suggests there could be an error or leak in our implementation.

6
  • Does media-heavy nodes mean nodes that include large image files (large file size), that too many nodes include images, or something else?
  • Are you interested in debugging the suspected Graphviz bug, finding a work-around, or both?
  • A work-around might be possible, but no guarantees.
7

Yes, can we get more specifics. If you can’t share the data, then how large are the media files? How many? (More than 50, which is the shape file cache size?) Images, or video? How large is the graph? Does drawing a tree trigger this bug? Could we take an old example like unix.gv and add the external media file references?

8

Typically, this is graphviz rather than the actual media. When image-backed nodes are added, **usershape caching** and size computation begin. If the cache is exceeded (50 shapes), graphviz begins to thrash. That by itself may result in sluggish renders and some layout drift.

Prior to forcing explicit `width/height` and `dpi` and turning off autoscaling, I would verify the engine selection (dot vs. sfdp). You’ve identified the problem if changing the graphics to fixed-size boxes stabilizes the layout. Geometry determines the graphviz layout, and heavy nodes alter geometry before they ever come into contact with IO.

9

This is interesting in light of the fact I just removed this cache. I’ll revert that change.

10

Fascinating! What system is this on? Do you have an example graph? We thought caching this wouldn’t be important. A counterexample would be very useful to inform keeping it.