diff options
author | László Németh <laszlo.nemeth@collabora.com> | 2015-11-27 21:59:30 +0100 |
---|---|---|
committer | Andras Timar <andras.timar@collabora.com> | 2015-12-01 12:53:28 +0000 |
commit | 945da612c70cc67c3b182c3f2ecdfd4333c8f456 (patch) | |
tree | d0c32bc97a2c7202ba166d96fd792955fda7d090 /TEMPLATE.SOURCECODE.HEADER | |
parent | 224ceff5f2c64ff47f4e687ac674d0a320bb9872 (diff) |
tdf#95614 fix freezing with linked graphic
When an unloaded linked picture comes into the visible view
(including repainting a page), SwNoTextFrm::PaintPicture()
starts a thread to load it in the background using the
TriggerAsyncRetrieveInputStream() method of the graphic node.
To avoid to start a second thread on the same graphic node,
TriggerAsyncRetrieveInputStream() checks mpThreadConsumer,
the graphic node member variable for the possible thread object.
The problem is that when the thread finished and
SwGrfNode::UpdateLinkWithInputStream() reset mpThreadConsumer,
the graphic object of the graphic node is still in unloaded
state (its type is GRAPHIC_DEFAULT or GRAPHIC_NONE instead of
GRAPHIC_BITMAP or GRAPHIC_GDIMETAFILE) for a while, because
its modification is solved asynchronously after several
SvFileObject::GetData() calls. In the intermediate state
of the graphic object, with the high priority repaints of
the new scheduler, PaintPicture() could start new thread
to load the image again.
Using the new member variable SwGrfNode::mbUpdateLinkInProgress,
this patch will prevent the graphic node to start newer thread
unnecessarily.
Change-Id: I9433f0fa4613294103a00a3955fc2f35d8863b59
Reviewed-on: https://gerrit.libreoffice.org/19974
Reviewed-by: Michael Meeks <michael.meeks@collabora.com>
Reviewed-by: Andras Timar <andras.timar@collabora.com>
Tested-by: Andras Timar <andras.timar@collabora.com>
Diffstat (limited to 'TEMPLATE.SOURCECODE.HEADER')
0 files changed, 0 insertions, 0 deletions