When I tried to print a fan chart it came out with several areas looking like someone rubbed off some of the info. Upon closer inspection it looked like that on the screen as well. I’ve tried various family lines and it looks like same. Looks like a printer running out of ink but it originates in the fan chart, not the printer. Anyone else have this issue?
1 Like
Yes, it has always been that way for me on a Mac. But when saved and viewed as a PDF it looks fine.
2 Likes
I have the same problem, plus the program hangs and shows “Application Not Responding” if I bring up the context menu for the dock icon, and if I click on the window with RM8 I get the spinning ball. I have to force quit RM to get it to stop. I’m running Mac Monterey.
I’m having that problem as well on Mac using RM 9.02 Attempts to change the window size so i could see if the defect was really in the displayed version, resulted in the program hanging (entirely) for 5 minutes. It then seemed to close and then restart the window. I can imagine generating this chart is very compute intensive, but locking the user out of the program for 5 minutes just for resizing the window isn’t right.
mac display and pdf use pale but distinct colors that are fine.
Chart displays instantly M1 Pro Ventura.
No issue with right click on finder or RM9 dock icon.
RM9 is much better than 8 but still uses a huge CPU % when active (15-20%). A typical mac program like FTM 2019 runs at ~0.5%. However RM9 is still using Intel code requiring Rosetta translation for modern macs. My only other Intel program (Doxie Go SE) uses 4% CPU.
Rooty,
I’d be curious to know what happens if you publish a fan chart (but not send it to print) and just try to enlarge the window for the visual display of the fan chart. Doing that resize of the window is what causes my system to get the spinning wheel of death. I’m running on an imac with core-i9 processor (8 cores) and 32 GB memory. So I don’t see why regenerating the image of a fan chart containing only 4 generations on the display should cause many minutes of the spinning wheel of death (with or without light color shading). I will add that on my system, RM9 generate the initial fan display in about 20 seconds , but then when I resize that display window to be larger, the spinning wheel hits for betwen 1-5 minutes (I suspect it may depend on the size of the window after resizing). I also don’t understand why the chart is shading faint blue when the Appearance setting for Colors is “No Coloring”. If it’s the color shading causing all the processing load, then please, please, RM, let me disable it.
I apologize, I’ve probably taken the conversation away from the wavy light (nearly obliterated) text in the fan chart, as originally raised, but I suspect that both that issue and my added issue of image regeneration performance triggering the spinning wheel are probably rooted in the same faulty image processing trying to generate the chart. Between the two issues, I’ve concluded the fan chart is an useable feature (bug?) for now.
The number of cores is really not relevant to much. The program has to be written to utilize multiple cores and I truly doubt RM is. Not all software can easily be spread across multiple cores just based on the type of problem it solves. Cores should not be confused with threads.
I agree with you. I can’t speak to the Mac version, but the Windows version appears to be a single process running on 1 cpu. Here’s what Resource Monitor shows:
