Application hangs when converting to png via cli using --scale parameter

[poleguy]

Preflight Checklist

• I agree to follow the Code of Conduct that this project adheres to.
• I have searched the issue tracker for a feature request that matches the one I want to file, without success.

You must agree to search and the code of conduct. You must fill in this entire template. If you delete part/all or miss parts out your issue will be closed.

Describe the bug
A clear and concise description of what the bug is.
Application hangs when converting to png via cli using --scale parameter once the scale parameter is large enough
and once the diagram is complex enough.

I expect the program to either create the png file I asked for or exit with an error message if it ran out of memory or exceeded some limit, etc. The application should not hang indefinitely.

To Reproduce
Steps to reproduce the behavior:

1. Open the attached test_hang.drowio.txt file.
2. download to a local location
3. rename the file to test_hang.drawio.txt
4. run this command and confirm the png is created correctly.
   time drawio -x -f png -s 1 test_hang.drawio
   test_hang.drawio -> test_hang.png

real 0m4.069s
user 0m1.789s
sys 0m0.328s

5. run this command and confirm the png generation hangs indefinitely (I kill it after 3 minutes.)
   time drawio -x -f png -s 10 test_hang.drawio
   This hangs and you must eventually use ctrl-c to kill it. No output file is created.

Expected behavior
A clear and concise description of what you expected to happen.
The cli command should create a test_hang.png output file in less than 3 minutes. (I'd expect 15-20 seconds... although it seems like a very long time to do the rendering. I wonder what is wrong with an algorithm that would take 20 seconds to render a png of a file that displays instantly on the screen.)

Screenshots
If applicable, add screenshots to help explain your problem.

draw.io version (In the Help->About menu of the draw.io editor):

• draw.io version 19.0.3
• diagrams.net 19.0.3

Desktop (please complete the following information):

• OS: Windows, MacOS, Linux...
  linux

Additional context
Add any other context about the problem here.
The resolution is too low if you don't use -s 10 on some of our diagrams, so we must use it.

If you simplify the diagram, e.g. by deleting some elements in the middle. Eventually -s 10 will work.
Conversely if you increase it to -s 11 it will still hang.

I also tried with jpg output and it still hangs.
I tried to simplify the diagram more than the one I have attached, and it does fix the problem, but the problem comes back if you then increase the -s to a bigger setting.
It's not clear of some element in my diagram is a factor causing this to happen or not.
I carefully removed all proprietary information from the attached test diagram.
github is annoyingly restrictive and won't let you upload a file named .drawio.

Addendum:
I'm trying to reproduce this again locally, and realizing I no longer can reproduce it reliably.
Usually this is run in a script via ssh. Therefore we have to run it under xvfb-run. The (failing) command I run is:
time xvfb-run -a drawio -x -f png -s 10 test_hang.drawio

So there may be some other factor causing this to hang related to xvfb. It's possible it has to do with the virtual screen size?

test_hang.drawio.txt

[poleguy]

There is also another bug that if you remove the background white box then it will cut off the text on left and right. That I can work-around easily enough, so I'm not going to bother filing a bug report beyond this comment.

I do appreciate having draw.io now. I spent so many years not being able to collaborate with others on diagrams due to visio licenses not being available to those I wanted to work with.

[poleguy]

Very interesting. It works if I change the screen size in xvfb to be be 1024x767x24, but fails if I leave the --server-args parameter off, or set it to 1024x768x24 (the default I think):

$ time xvfb-run --server-args="-screen 0 1024x768x24" -a drawio -x -f png -s 10 test_hang.drawio
libva error: vaGetDriverNameByIndex() failed with unknown libva error, driver_name = (null)
[1270397:0610/164703.439886:ERROR:viz_main_impl.cc(186)] Exiting GPU process due to errors during initialization
libva error: vaGetDriverNameByIndex() failed with unknown libva error, driver_name = (null)
[1270445:0610/164703.503161:ERROR:gpu_memory_buffer_support_x11.cc(44)] dri3 extension not supported.
test_hang.drawio -> test_hang.png

real 0m14.818s
user 0m8.080s
sys 0m1.272s

$ time xvfb-run --server-args="-screen 0 1280x1024x24" -a drawio -x -f png -s 10 test_hang.drawio
libva error: vaGetDriverNameByIndex() failed with unknown libva error, driver_name = (null)
[1269926:0610/164547.713962:ERROR:viz_main_impl.cc(186)] Exiting GPU process due to errors during initialization
libva error: vaGetDriverNameByIndex() failed with unknown libva error, driver_name = (null)
[1269985:0610/164547.772904:ERROR:gpu_memory_buffer_support_x11.cc(44)] dri3 extension not supported.
^C[1269985:0610/164651.385114:ERROR:connection.cc(46)] X connection error received.
[1269985:0610/164651.385111:ERROR:connection.cc(46)] X connection error received.
real 1m4.471s
user 0m1.080s
sys 0m0.262s

Really, the problem is that drawio cannot render a .png file via ssh. So it's no good for running in a scripting environment. If you could fix that then the xvfb-run workaround wouldn't be needed, and we wouldn't run into this bug.

I guess I have a workaround now. But I have no idea why the smaller screen size helps make it not hang.

References:
https://stackoverflow.com/questions/22913794/setting-a-resolution-for-xvfb-run-and-wkhtmltopdf-wkhtmltoimage
https://sites.google.com/a/swiftlet.co.th/tech/home/x-virtual-frame-buffer-command

[poleguy]

Unfortunately the xvfb-run -screen workaround is not reliable.
In addition I should mention that my original drawio file that has the problem with hanging, has sometimes rendered correctly in the past with exactly the same settings, so this is an intermittent failure. We regenerate the png files with a script frequently.

[davidjgraph]

version 19.0.3 is really old, please re-test on the latest release.

[poleguy]

I just installed 24.5.3 and it does not hang. I guess you can close this ticket.

I do get these messages now sometimes:
[1912795:0611/165055.738676:ERROR:tile_manager.cc(982)] WARNING: tile memory limits exceeded, some content may not draw

Unfortunately 24.5.3 sometimes renders giant white areas instead of the expect content. So maybe that's not going to work so well for me either.

And there seems to be a bug in handling latex strings used in this file. The ones with newlines in 19.0.3 render without newlines in 24.5.3.

Also if you try to double click to edit the latex it is immediately converted to normal text and you lose the font formatting. That used to work in 19.0.3. Now it's broken until you explicitly remove all the formatting. It seems you can only edit the latex by toggling the menu option "Extras->Mathematical Typesetting". Maybe that's a feature not a bug? But it was unexpected and hard to diagnose.

I also tried 24.4.13 and have the same problem with newlines in latex.

If I use the string $$abc\def$$ it renders the string as "abcdef" all on one line. If I use the string $$abc$$$$def$$ I get something close to what I got before, although the spacing seems different.

Oh well, I guess that's better than hanging.

[poleguy]

For the record:
Without --scale, the text renders poorly, and the latex text is almost completely illegible. That's why I have resorted to using --scale 10.
For example, the upper image here is the default output with latex, and the bottom is just regular text.