The Persistence of Vision Raytracer (POV-Ray).
This is the legacy Bug Tracking System for the POV-Ray project. Bugs listed here are being migrated to our github issue tracker. Please refer to that for new reports or updates to existing ones on this system.
Attached to Project: POV-Ray
Opened by Jim Holsenback - 2011-11-16
Last edited by William F Pokorny - 2017-05-18
Opened by Jim Holsenback - 2011-11-16
Last edited by William F Pokorny - 2017-05-18
FS#227 - Fixed Vector Limitations
See this documentation entry for more details.
If the concern seems to be the multiple calls to alloc (on push_back, with lock of allocator), what about:
# using a normal vector (s0 and s1 in media.cpp circa line 700)
# with s0.reserve(lights.size()) and s1.reserve(lights.size()) before the copy in the for loop.
For the other case of FixedSimpleVector, I found only :
* trace.h, where it seems to support a replacement in typedef with normal vector (should I expect some leaks ?)
* frame.h, untested so far.
work in progress.
Please don't work on this: It is an extremely fragile construction and only Chris and I know all the details and side effects and rationale for the way it is. It is a workaround, but it isn't there because it is easy to fix, but because it is really, really hard to fix well.
Ok
For the record, benchmark get a slow down on change of frame.h (from 2:35 to 2:48)
Other changes did not had a significant impact. (but media might not be part of benchmark)
Changing the state of this task instead of blindly porting it to github as is. Original wiki link is dead, and other than seeing a discussion about some tricky memory allocation/performance issues I’m lost.
For the records, the whole issue is about artificial limits to certain features, due to the use of FixedSimpleVector<> to avoid excessive memory allocation/deallocation overhead.
The corresponding hard limits are configured via the *_VECTOR_SIZE macros in /source/core/configcore.h.
Now tracked on github as issue #292.