Before we start porting image engine to the new drawing manager
we should do some cleanups.
- Use similar namespace as other draw engines (`blender::image_engine`)
- Switched InstanceData and Instance
- Reduce parameters as drawing mode can access Instance.
- Remove some templates to improve readability.
Pull Request: https://projects.blender.org/blender/blender/pulls/131146
Listing the "Blender Foundation" as copyright holder implied the Blender
Foundation holds copyright to files which may include work from many
developers.
While keeping copyright on headers makes sense for isolated libraries,
Blender's own code may be refactored or moved between files in a way
that makes the per file copyright holders less meaningful.
Copyright references to the "Blender Foundation" have been replaced with
"Blender Authors", with the exception of `./extern/` since these this
contains libraries which are more isolated, any changed to license
headers there can be handled on a case-by-case basis.
Some directories in `./intern/` have also been excluded:
- `./intern/cycles/` it's own `AUTHORS` file is planned.
- `./intern/opensubdiv/`.
An "AUTHORS" file has been added, using the chromium projects authors
file as a template.
Design task: #110784
Ref !110783.
A lot of files were missing copyright field in the header and
the Blender Foundation contributed to them in a sense of bug
fixing and general maintenance.
This change makes it explicit that those files are at least
partially copyrighted by the Blender Foundation.
Note that this does not make it so the Blender Foundation is
the only holder of the copyright in those files, and developers
who do not have a signed contract with the foundation still
hold the copyright as well.
Another aspect of this change is using SPDX format for the
header. We already used it for the license specification,
and now we state it for the copyright as well, following the
FAQ:
https://reuse.software/faq/
The goal is to make it more explicit and centralized operation to
assign and steal buffer data, with proper ownership tracking.
The buffers and ownership flags are wrapped into their dedicated
structures now.
There should be no functional changes currently, it is a preparation
for allowing implicit sharing of the ImBuf buffers. Additionally, in
the future it is possible to more buffer-specific information (such
as color space) next to the buffer data itself. It is also possible
to clean up the allocation flags (IB_rect, ...) to give them more
clear naming and not have stored in the ImBuf->flags as they are only
needed for allocation.
The most dangerous part of this change is the change of byte buffer
data from `int*` to `uint8_t*`. In a lot of cases the byte buffer was
cast to `uchar*`, so those casts are now gone. But some code is
operating on `int*` so now there are casts in there. In practice this
should be fine, since we only support 64bit platforms, so allocations
are aligned. The real things to watch out for here is the fact that
allocation and offsetting from the byte buffer now need an explicit 4
channel multiplier.
Once everything is C++ it will be possible to simplify public
functions even further.
Pull Request: https://projects.blender.org/blender/blender/pulls/107609
Float images loaded in Blender are converted to scene linear and don't
require additional conversion. Image engine can reuse the rect_float of
those images. An assert statement is added tp make this more clear and
to test on missing code paths or future developments.
Image engine is used to draw the image inside the image editor, uv editor and node editor. The
performance during scrolling wasn't smooth when using larger textures on a dedicated GPU. Main
reason was the data transfers that happens when panning the image.
The original idea of the image engine was to have 4 textures that are as large as the editor.
Those textures would be used to simulate a larger canvas where if the texture is out of the
visible area the texture would be reused to contain the data of a new visible area. This would
reduce the data transfers to only on certain x/y coordinates. Between those coordinates no
data transfers would be needed.
This patch implements the mechanism described above. During development other areas to
improve have been detected (incorrect color management for float textures, using different
image formats to reduce data transfer bandwidths, using different render techniques for
images upto 8k). More improvements will follow.
Previously we used to cache a float image representation of the image in
rect_float. This adds some incorrect behavior as many areas only expect
one of these buffers to be used.
This patch stores float buffers inside the image engine. This is done per
instance. In the future we should consider making a global cache.
