Agreed, when designing systems the devil is in the details. Its important that the details are well understood by everybody in the same way. Small differences in understanding always lead to big implementation problems. Its not that in this case were designing it but it is important to understand the design details that Heruca is outlining.
300Mb sounds right to me. 10,000 x 10,000 x 3 (RGB) is 300 million bytes. Its odd that it takes longer to compress to JPG than PNG. Its almost extraordinary that it is longer to save an uncompressed BMP file than a PNG. In the process you have compute and I/O. Since the PNG is only 5Mb then it implies that the system on which it was being tested had great CPU performance to compress it but terrible HDD performance to store it. If you had used a slower CPU machine with an SSD I would have expected it to be very different. Also, it implies that the system did not have 300Mb of cache RAM spare to offload the file before it was saved. Most systems / OS's 'save' the file to a system buffer which then chugs it out to the HDD in the background and gives control back to the app. Its possible tho that the app tried to check the file by reopening it (or doing some kind of stat on it) which would force the OS to stall that check until the save had fully completed. I know on my app the PNG is the slowest, JPG is better and BMP is fastest. I do overlap the render and save at the same time for bitmaps (BMP files) but I cant do that for the other two tho. So maybe that skews the timings a bit. Even so I would think that you may need to check those times on various bits of hardware before really relying on them. Its a very unusual result to say the least. JPG is normally quite quick to compress and quick by being small to save so normally wins. Some CPUs have special instructions that can be leveraged to help save JPGs but a JPG library may need to ask for them at run time. If they didn't exist then it could be slower. Lots of reasons the speed could change between hardware.
I agree that CC3 is doing special stuff regarding its layers. It obviously has to in order to do 135 layers. So its not comparable to measure it against GIMP. The texture fill thing is an obvious trade off between memory usage and versatility. As an bitmap / raster / image editor (you pick) Gimp is clearly going to be able to have anything going on at any point in one image layer since it has allocated enough memory for the whole sheet. I know a lot of mappers here at the guild are artists that make great maps rather than CAD like in their approach which is why we get a lot of photoshop / Gimp users. Artists will make use of the layers at all points and so Gimp runs rings around CC3 in that respect. So you win some you lose some by taking the trade off. Incidentally its a trade off that I took with my app and as such you still needed an image editor to use it properly. In my mind CC3 and Gimp (a vector - hybrid and a raster app) operate in two separate spaces. But I know I would be fighting a lonely battle if I kept up with that argument - but I believe it nonetheless. Some apps like Xara bridge it well but no app does both sides as well as the best dedicated ones. To pick a camp one side or the other is to miss the point so to be entrenched into one side and waving the flag proudly is a poor decision.
So yeah, how to make a mapping app that handles the best of vector and raster at the same time ? If you go for one or the other then there are other apps out there already which do it well I think because its easier to persuade people of the benefits of each individually and so the graft of development has already happened. But I am in the camp that if targeting maps specifically as opposed to maps of pure art then there could be a better option. That option is still not implemented. Its a hard task. Part of the task must be to persuade / show or realign peoples mentality about how to go about mapping to the way your app is going to do it - which is something I found extremely challenging. So my very best of luck to you with your endeavor.
Reply With Quote
