| Age | Commit message (Collapse) | Author |
|---|
|
For render image buffers to be acquired, a lock must be provided. Also
fixed wrong usage of release, it must always be called regardless if the
returned image buffer is NULL.
|
|
Issue only happens in release builds on windows. That said it was an
actual error in the code. This class is compiled inline in release
builds. When updating multiple textures it would reuse the same memory
to collect the changes. When the previous loaded tilenumber was exactly the
same but from a different image the tile buffer wasn't loaded.
Reviewed By: sergey
Maniphest Tasks: T96213
Differential Revision: https://developer.blender.org/D14274
|
|
Adding better support for drawing huge images in the image/uv editor. Also solved tearing artifacts.
The approach is that for each image/uv editor a screen space gpu texture is created that only contains
the visible pixels. When zooming or panning the gpu texture is rebuild.
Although the solution isn't memory intensive other parts of blender memory usage scales together with
the image size.
* Due to complexity we didn't implement partial updates when drawing images tiled (wrap repeat).
This could be added, but is complicated as a change in the source could mean many different
changes on the GPU texture. The work around for now is to tag all gpu textures to be dirty when
changes are detected.
Original plan was to have 4 screen space images to support panning without gpu texture creation.
For now we don't see the need to implement it as the solution is already fast. Especially when
GPU memory is shared with CPU ram.
Reviewed By: fclem
Maniphest Tasks: T92525, T92903
Differential Revision: https://developer.blender.org/D13424
|
|
This patch reimplements the image partial updates. Biggest design motivation for the redesign
is that currently GPUTextures must be owned by the image. This reduces flexibility and adds
complexity to a single component especially when we want to have different structures.
The new design is not limited to GPUTextures and can also be used by reducing overhead in image
operations like scaling. Or partial image updating in Cycles.
The usecase in hand is that we want to support virtual images in the image editor so we can
work with images that don't fit in a single GPUTexture.
Using `BKE_image_partial_update_mark_region` or `BKE_image_partial_update_mark_full_update`
a part of an image can be marked as dirty. These regions are stored per ImageTile (UDIM).
When a part of the code wants to receive partial changes it needs to construct a `PartialUpdateUser`
by calling `BKE_image_partial_update_create`. As long as this instance is kept alive the changes can
be received.
When a user wants to update its own data it will call `BKE_image_partial_update_collect_changes`
This will collect the changes since the last time the user called this function. When the partial changes
are available the partial change can be read by calling `BKE_image_partial_update_get_next_change`
It can happen that the introduced mechanism doesn't have the data anymore to construct the
changes since the last time a PartialUpdateUser requested it. In this case it will get a request
to perform a full update.
Maniphest Tasks: T92613
Differential Revision: https://developer.blender.org/D13238
|
