summaryrefslogtreecommitdiff
path: root/TEMPLATE.SOURCECODE.HEADER
diff options
context:
space:
mode:
authorLászló Németh <laszlo.nemeth@collabora.com>2015-11-27 21:59:30 +0100
committerAndras Timar <andras.timar@collabora.com>2015-12-01 12:53:28 +0000
commit945da612c70cc67c3b182c3f2ecdfd4333c8f456 (patch)
treed0c32bc97a2c7202ba166d96fd792955fda7d090 /TEMPLATE.SOURCECODE.HEADER
parent224ceff5f2c64ff47f4e687ac674d0a320bb9872 (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