It’d be great to have access to named required sizes of path items (startNewSubPath() = 3, lineTo() = 2, quadraticTo() = 5, etc). So the argument passed to Path::preallocateSpace is slightly more readable. Ideally i’d like to read it that way:
Path p;
p.preallocateSpace(Path::StartNewSubPathSize + Path::LineToSize * n + Path::CloseSubPathSize);
Wouldn’t a quicker approach be to just make your path, then add a Debug statement that prints out the size of the path, and then revise your code after you’re done making the path and populate p.preallocateSpace() with the value from the Debug line? You can pull the size of the path from Path::toString() by parsing.
I posted a question about a similar thing regarding path sizes and how big do they have to be to start causing slowdowns.
True that … however the path size is dynamic. It’s not such a big problem to read up the numbers in the docs. It’s just a question of style: i prefer to have as little ‘magic numbers’ in my code as possible.
Well… I’d be a bit hesitant to do this, as it does imply that the storage structure won’t change, and that’s not guaranteed. I really only intended it to be used for simple cases to help preallocate a decent sized block if you know it’s going to be a complex path. What kind of sizes are you talking about here?
Actually the possible changing structure is in my point of view a good argument for having named sizes in the code. If ever the structure changes you can either simply bump the variable value or remove/change the name. The compiler will in that case raise awareness that this function has to be revisited.
I only preallocate paths that are complex and exceed trivial control point counts (anti-aliased waveform and graphs). I think the documentation is quite clear on that.
I am talking about the following part in the documentation:
[…] each lineTo() or startNewSubPath() will require 3 coords (x, y and a type marker). Each quadraticTo() will need 5, and a cubicTo() will require 7. Closing a sub-path will require 1.
So that would be
LineToSizeStartNewSubPathSizeQuadraticToSizeCubicSizeCloseSubPathSizeSure, but what if it changed so that consecutive similar operations didn’t need a flag each time, or if there were special cases for sub path handling, etc.
My point is that we don’t like exposing too much of the internal of classes like this because it makes it harder for us to change them. If this preallocation is so critical to the performance of your app then over-allocating a bit probably isn’t a big deal, is it?
That’s right… i don’t see over-allocating in these code sections as critical. I was mostly searching for a way to eliminate magic numbers and keep my code legible and self-explainatory.
