CC3+ is Slow
FarsightX3
Surveyor
Hey guys! Long time no post! I hope everyone has been well! As I do work on large scale maps with a ton of entities on my map, I do tend to get a lot of down time, when hiding, freezing, changing layers/sheets as well as the draw too. It's still quicker than CC3. So my question is, does CC3+ run off HDD, Graphic Card and/or Ram? Most of my time in designing large scale maps is through it loading so slow. I was wondering if it was a hardware issue on my end? I am saving up for a SSD soon. I was wondering if that would help decrease load/render times?
Comments
total amount of RAM up to about 6GB,
OS type (64-bit OS will let the program run with 4GB of usable memory; 32-bit OS lets the program run with 2GB of usable memory),
amount of CPU cache,
CPU clock speed,
memory speed,
hard disk speed (mostly for first load if you have sufficient RAM),
graphics card speed.
The general process for drawing in CC3+ is:
1) clear the background image
2) load image files needed for bitmaps and fills. After the initial load, decoded images will be cached by CC3+ and encoded images by the OS.
3) for each sheet in the drawing
3a) draw everything on a sheet into a memory image
3b) apply effects to the memory image
3c) apply the processed sheet image to the background image
4) show the final image on the screen
Disk speed (SSD vs. spinning rust) usually only affects step 2. The disk hardware usually only has an impact on the first redraw.
Graphics card speed may have a minor impact on 3a and 4, depending on your OS and graphics card.
CPU speed, cache, memory speed, have a major impact on step 3b and 3c. These steps are usually the most performance-intensive, with certain effects like blur having a severe impact.
How slow a drawing takes to render is also affected by the entities that you're drawing. The slowest entities overall are bitmap-filled smooth polygons. The worst performance killer is not the entity type, but entity fill. If you're drawing a hatch-filled entity (especially an oriented hatch fill), then that hatch fill will be composed of thousands of entities that need to be drawn individually.
Farsight, what I do it try to hide sheets and layers that I don't need. Especially those with bitmaps fills in them.
For reference, I'm running i7-4712HQ @2.30 GHz and I don't consider my maps all that intense but use blanked sheets and layers.
I think on my current map the biggest culprit is cave walls, they use a bitmap fill and are fractalized. I had to go and reduce the number of nodes and I usually keep them and the cave floors hidden so I have better performance.
Because of the processing a program like CC3+ needs to do for each redraw (much much more than for example an image editor), there are no processor invented that CC3+ won't be slow on if the map gets complicated enough, although it shouldn't be slow on more "normal" size maps, but I don't know how complicated your maps are (CC3+ doesn't put any limits on what you can do, but I do recommend rethinking complexity if a map gets too slow to work with. Also, on very complex maps, it may be an advantage to work with effects off, calculating those effects all the time really eats CPU cycles)
It doesn't crash though. It just takes a really long time to do any one of those 3 things - but we are talking about a machine that only ever has 1.7 GB RAM available nowadays thanks to Win 10, and which struggles to cope with processors that have been kneecapped by the recent security upgrades.
(If this thread is still active by the time I've saved enough for a new laptop with more RAM and processors, I'll update those facts
[EDIT: actually, thinking about it, could it be the security upgrades over the last 3 months, which were feared to slow things down by up to 30% that are causing this particular problem? Processor speeds will never be what they were last year!]
I had a student in my office the other day with an older i7 processor. It would normally be a beefy machine, but some tasks where slowed to a crawl after the intel spectre/meltdown fixes. Personally, I am running a processor new enough that it could be fixed without taking the severe speed hit, but those older ones wouldn't. I am not sure if this affects CC3 performance or not though, but it sure is a thought.
However, if I reduce the window so that the effective drawing resolution becomes much lower, then performances become acceptable, and in some circumstances (usually reducing the window size even further), I can even enable effects and continue working. This is annoying, giving the feeling of drawing on a post-stamp, but this is the only way I found to get decent performances (I don't have any performance issues with my computer with any other program, including games). Sometimes, I look at youtube videos about CC3+, and the performance is huge compared to what I have in fullscreen.
https://en.wikipedia.org/wiki/720p#/media/File:Vector_Video_Standards2.svg shows some of the more popular video standard resolutions in use down over the years. https://en.wikipedia.org/wiki/4K_resolution#/media/File:Digital_video_resolutions_(VCD_to_4K).svg shows how the common broadcast resolutions vary. The rendering system in CC3+ was developed back when HD (1920x1080) was a high-end device.
That's the way of things isn't it. I wonder just how big things will get before we finally accept that 'this is enough', and 'I wouldn't be able to see the difference if we doubled it again because I don't have the eyes of a hawk'?
The desire for huge and high-resolution screens is as much for multi-viewer experiences as anything (the home theater). A single human has a relatively small area of their visual field that hits the limit stated above, so you can get by with smaller screens held closer for a single-person device. Sharing devices means that you need to provide high resolution everywhere on the device and at a larger distance.
How much is enough? It depends on the level of bragging rights you want with your friends. After spatial resolution (pixels on the screen) comes temporal resolution (how many frames per second), but because CC3+ doesn't continually redraw its screen under most situations, temporal resolution is less important for it. That's not to say that I wouldn't like it to be much faster, but the compatibility needs for some of the features that have been implemented in CC3+ are, um, complex.
Before, with HD, I worked with one application full screen, one document in the application, now, I can work with two documents (real-size vertical A4) or two applications side-by-side, and the text is crystal clear, with individual pixels invisible.
Question for jslayton: What API is used by CC3+ for drawing? Is this gdi, openGL,D3D, something else?..
The FastCAD core dates to the mid 90s from the comments. It's straight GDI rendered to in-memory DIBs. It uses custom bitmap software to do its fills, which is why you get nearest-neighbor sampling and artifacts along edges of some filled entities. The effects system uses the drawn DIBs to apply software-based operations. Switching the rendering engine to something other than its current state is a huge effort, but the initial prototype showed some promise.
My current 24" monitor is 1920 x 1080p. Works fine for me. I don't have to wear my eye glasses when looking at my computer screen.
I have 2 real ones, and 2 virtual ones. All have always been automatically turned on without me having to do anything. There was one app that couldn't 'see' the virtual CPUs no matter what I did (nothing to do with PF software I hasten to add). I suppose it must be different between different machines, and even between different apps
The usual tricks are to put sets of things on different layers (for example districts of a city) and hide layers not currently being used... this is layers not sheets, so that you can carry on working on any sheet with stuff hidden.
You can also work with effects off, work at low res, and hide sheets if you aren't working on them.
If you think this is related to the latest update that is a separate issue, and maybe should be reported to tech support?
(if by low res are you talking about the size of the drawing, which mine is about 13800 by 9400 in size)
Also, is there any way to see how many objects are in the drawing by command. One thing I did do was add more objects in the form of a forest, but it honestly wasn't a whole lot more than I had in the north (maybe an extra 5% to what was previously on the map). I was hand adding each object, not using an autofiller, so the forest isn't just a deluge of objects (just saying that because I know its slower, but I did that so I wouldn't have a bajillion objects)
You will see a folder with binoculars. Above that is S: and a word here
Click on that. About the middle of the popup, there is a square that says Activate Sheet Effects.
If checked they are on. No check mark, they are off.
The resolution I was talking about is the resolution at which the bitmap textures and symbols are displayed. CC3 has 4 different resolution images for every texture and symbol asset stored away in the Profantasy folders. These four resolutions are called VH (very high), HI (high), LO (low), and VL (very low). Normally CC3 will decide which resolution to display for each fill and symbol in your drawing depending on how far in or out you are zoomed, but you can force CC3 to use only the LO res images for everything all the time by clicking the hourglass button on the left toolbar and setting "Display Speed" to "Fixed Bitmap Quality", and "Low". If you fix the display speed at LO don't forget what you have done when you render the map to a bitmap image, since you will need to open the Display Speed dialog again and return it to automatic before rendering your image.
Another thing that can slow your map down is if you have a very intricate coastline or other vector shape that has thousands of nodes in it. Most usually this is caused by people making the mistake of having unnecessarily complex coastlines - a problem that can be compounded by tracing sections of that coastline as the edge of various terrain textures. If you have tens of thousands of nodes in your map your map will be necessarily slow and may even crash from time to time. A comment made by Remy Monsen just recently on another thread suggested that 15,000 nodes should be taken as a normal maximum in most cases, though some maps have as many as 30,000. I am only guessing here, but if your map is itself quite huge I imagine that you have made it this large in order to have a lot of detail in it, so this may be contributing to the problem.
You can find out how many nodes you have in your map by using the Info->List tool and selecting the largest and most complex shapes you have drawn. The node count is in the information given in the blue box and will appear for each entity separately at the top of the list of coordinates for the entity. Worth checking? Most certainly if you have a highly detailed map of the size you describe.
What to do about it...
Most coastlines are far to detailed for their intended purpose, so it does little harm to use the SIMPLIFY command (you type SIMPLIFY on your keyboard and hit enter). Look at the command line at the bottom of your CC3 window and you will see it is asking for a number. The number you give is the minimum distance between consecutive nodes in map units. On a map that size (if you are really talking about 13800 x 9400 map units) I would suggest trying 1 or 2 to start with, or even higher if you have way over 15,000 nodes. If you don't like the result CTRL+Z will reverse the effect so that you can try with a lower number.
You can find out quite a bit of information about your map using the Info->Count All tool, which will give you a list of totals.
38 2D Point Entities
716 2D Line Entities
137 2D Circle Entities
656 2D Arc Entities
10 2D Ellipse Entities
115 2D Elliptical Arc Entities
330 2D Path Entities
264 2D Polygon Entities
495 2D Smooth Polygon Entities
65 2D Spline Entities
326 2D Text Entities
934 Symbol Definition Entities
11645 Symbol Reference Entities
2 2D Text Attribute Entities
106 2D Multipoly Entities
2217 XP Entities
3 File Notes Entities
18059 Entities occupying 3132.66k of memory