Calling picture->load after it was already once called resulted in
segmentation fault or memory leak (depending on whether the vector (svg, tvg)
or raster (jpg, png, raw) file was loaded).
This patch checks the image has already been loaded. If so, the load()
returns InsufficientCondition.
@issue: fixes#719
if the last contour dispatching is dealt with closed command but actual command
is not the closed, the close tag is written with the opened
In this case, stroking rendering is buggy.
So this optimization stragtegy is to merging shapes.
If two shapes have the same layer, having save properties except the paths,
we can integrate two shapes to one, this helps to build up a simpler
scene-tree, reduce the runtime memory, helps for faster processing for rendering.
As far as I checked tiger.svg, it removes 142 shape nodes,
decreased the binary size: 60537 -> 54568.
Overall, avg 4% binary size can be reduced among our example svgs by this patch.
This change protects against negative value in unsigned int of
RenderRegion.x/y. This fixes a problem of invisible paint if ClipPath
bounds was negative.
@issue: #704
This optimizes binary size by skipping the scene if it has the only child.
though the reduced size is too trivial size (avg 0.4% as far as I checked our example svgs),
we can reduce the loading job & runtime memory as well.
Skip to save transform data by accumulating them through the scene tree,
and then applying the final transform to the path points.
Assume that each transform have 36 bytes, it could be increased linear to paints node count
if every paints has transform in the worst case.
Fudamentally, this save their memory and only remains to Bitmap Pictures,
also helps to reduce the loading/rendering workloads since
it doesn't need to perform any transform jobs after converting.
Added error string printing on jpg image loading failure.
The error message help developer find the corrupted jpg file.
Error message is not printed for open from char* data as there the
loaders are tried on by one.
tvg binary format might break the compatibility if any major features have been changed.
It's allowed to do it when the major version is upgraded.
In that case, still we need to support the backward compatibility,
we can provide multiple binary interpreters and choose the proper one
based on the current loading tvg binary format version.
Thus, you can add further interpreters if it's necessary in the future.
Our policy is to derive the TvgBinInterpreterBase class to make it running on
the interface.
for example, if the major version is upgraded 1.x, you can implement TvgBinInterpreter1.
