Issue 122985 - Slow working with photos
Summary: Slow working with photos
Alias: None
Product: Draw
Classification: Application
Component: editing (show other issues)
Version: 4.0.0
Hardware: PC Windows 7
: P3 Major (vote)
Target Milestone: 4.0.1
Assignee: Armin Le Grand
QA Contact:
Keywords: regression
Depends on:
Reported: 2013-08-08 21:38 UTC by sevalav
Modified: 2017-05-20 10:34 UTC (History)
6 users (show)

See Also:
Issue Type: DEFECT
Latest Confirmation in: 4.0.0
Developer Difficulty: ---
jsc: 4.0.1_release_blocker+


Note You need to log in before you can comment on or make changes to this issue.
Description sevalav 2013-08-08 21:38:30 UTC
Draw, problems:
Slow inporting of bigger picture, slow (very slow) editing of this picture.
Comment 1 sevalav 2013-08-08 21:44:38 UTC
Slow, very slow work with bigger size of picture inside Draw. Impossible for easy work.
AOO400m3(Build:9702)  -  Rev. 1503704
2013-07-16 14:54:56 (Di, 16 Jul 2013)
Comment 2 sevalav 2013-08-08 21:48:51 UTC
Link for Draw document:
Comment 3 Regina Henschel 2013-08-08 22:38:34 UTC
I can confirm the bad performance. Take a common photo from a digital camera. I have used a 2,7MB JPEG-photo. A 90° rotation needs 2 seconds, a move 3 seconds, loading 7 seconds. AOO3.4.1 makes 90° rotation in 1 second, a move immediately and loading in 3 seconds.

Especially the delay in moving makes working with photos virtually impossible.
Comment 4 Oliver-Rainer Wittmann 2013-08-12 10:29:09 UTC
put Armin on CC as he is one of the experts here
Comment 5 sevalav 2013-08-12 12:51:52 UTC
Wittmann, how to do that? I am new here.. :)
Comment 6 Oliver-Rainer Wittmann 2013-08-20 13:49:40 UTC
(In reply to sevalav from comment #5)
> Wittmann, how to do that? I am new here.. :)

Oh sorry...
I meant to say that "I have put Armin on CC as ...."

But nevertheless, in order to put somebody on CC of an issue you have to found the CC List field in the upper right corner. There is a link the start the edit mode. In the edit mode you can add the corresponding person.
I am not sure, if a certain access right is needed to edit the CC List field.
Comment 7 sevalav 2013-08-20 15:11:12 UTC
In AOO 3.4.1 there is not present this problem.
Comment 8 Oliver-Rainer Wittmann 2013-09-02 13:26:17 UTC
adjusting Issue Type as this is a defect.
Comment 9 Armin Le Grand 2013-09-03 13:53:23 UTC
ALG: Already speeded up stuff for rendering and conversion to Gdiplus::Bitmap in task #122923#, this should bring it back to comparable speeds as before.

Still I took a look at JPEGReader::Read. To mention before: Nothing was changed there, but it uses ca. 17% of it's time to read the jpeg and the *rest* to get it to a Bitmap as content. This is because SetPixel() calls are used and jpeg's imported format is RGB while the 24bit bitmap uses GBR internally. There is no GBR import format available from the jpeg importer unfortunately.
Tried to use CopyScanline at BitmapWriteAccess using BMP_FORMAT_24BIT_TC_RGB. This works but is not much faster as SetPixel() since the internal format conversion is not very fast.
But using BMP_FORMAT_24BIT_TC_BGR and first 'switching' all 1st and 3rd bytes in a loop makes it much faster. With this additional speedup for jpeg we sould be better than before. Preparing checking this in.

Also took a look at the swap stuff in current GraphicObjects; these all get swapped out after 5000ms (5 seconds), independent of the time set in tools/options/memory/Remove_from_memory_after setting. This seems wrong and makes switching pages very slow since loading has to reoccur often. Taking a look...
Comment 10 Armin Le Grand 2013-09-03 15:46:59 UTC
AG: Checked what happens when not setting a swap time at all; idea was that the GraphicManager (which at least reads the timeout from the settings in GraphicObject::ImplSetGraphicManager and sets it at the global GraphicCache) would then swap out all GraphicObjects after the given time, but this does not work. Reading the setting itself and set it instead of the 5000ms works well; still has its weaknesses since it *tests* for swap out every e.g. 10 minutes (if set so), also no 'touch' when the graphic is used to reset the timer is there (what would be normal for a cache). What to do...?
Comment 11 Armin Le Grand 2013-09-03 16:17:16 UTC
ALG: Checked svtools jpeg load changes on linux to be on the safe side, all works well and is faster, too.
Comment 12 Armin Le Grand 2013-09-04 12:15:32 UTC
ALG: Did the same I dod for jpeg (see comment 9) for png, got improvements from 10s load time to 2s. Only done for 24/32bit and not preview-loading to minimize risk, checked with a PNG test suite all optimized cases. Need to check this one on linux, too.
Also experimenting with the time settings to flush graphics; when using the default from the tools/options of 10 minutes (instead of the hard-coded 5 seconds) exactly that happens; there is no mechanism to make the GraphicManager to take the used memory or number of cached GraphicObjects lead to flushing graphics (this needs rework). When I would set that time correct, this may lead to memory problems in other cases. Maybe the speedups should be all for now, to be on the safe side...
Comment 13 Armin Le Grand 2013-09-04 12:46:33 UTC
ALG: Looking for a good compromize with the swap-out time: The default is 10 minutes. The minimum is one minute, thus 60 seconds. When the minimum should match to the former hard-coded 5 seconds, we have a divisor of 12 to use. For the default of 10 minutes this would mean 50 seconds. Compared to before this is ten times more (would allow better navigation by switching through pages) and is controllable by the user by setting the tools/options/memory/Remove_from_memory_after setting. Seems to be a good compromize to me. Checked in a living office, feels good.
Comment 14 Armin Le Grand 2013-09-04 16:01:29 UTC
ALG: Checking all changes on Linux...
Comment 15 Armin Le Grand 2013-09-05 11:43:47 UTC
ALG: Linux check led to slight adaptions in png importer, works well, adapting to win version. Adding comments and preparing commit...
Comment 16 Armin Le Grand 2013-09-05 12:25:14 UTC
ALG: Also saw that deleting graphic objects does not flush the graphic content since these objects go to the undo stack. Added code to do this when objects get deleted and move to the undo stack. This will help when adding/removing a lot of pictures (e.g. D&D copy/paste from explorer or similar). Checking...
Comment 17 Armin Le Grand 2013-09-05 12:58:18 UTC
ALG: Works like a charm, adding this. GraphicObjects get flushed when deleted or redoing a delete. Preparing commit, setting AOO401 flag, too.
Comment 18 SVN Robot 2013-09-05 14:07:06 UTC
"alg" committed SVN revision 1520296 into trunk:
i122985 Various speedups for graphic object swapping to enhance user experience
Comment 19 Armin Le Grand 2013-09-05 14:18:29 UTC
ALG: Testing final version on Linux and AOO401...
Comment 20 jsc 2013-09-06 08:07:08 UTC
approve showstopper request
Comment 21 Armin Le Grand 2013-09-06 08:16:05 UTC
ALG: Looks good, found a missing part of #122923# which was needed, added. Preparing commit for AOO401...
Comment 22 SVN Robot 2013-09-06 08:50:02 UTC
"alg" committed SVN revision 1520507 into branches/AOO401:
i122985 Various speedups for graphic object swapping to enhance user experience
Comment 23 SVN Robot 2013-09-10 14:22:54 UTC
"hdu" committed SVN revision 1521489 into branches/AOO401:
#i122985# fix compile error in pngreader.cxx for product build with debug ena...
Comment 24 SVN Robot 2013-09-10 14:25:42 UTC
"hdu" committed SVN revision 1521488 into trunk:
#i122985# fix compile error in pngreader.cxx for product build with debug ena...
Comment 25 liuping 2013-09-13 06:04:19 UTC
Verified on AOO401m4(Build:9713)  -  Rev. 1521921 on Win7,Pass
Comment 26 liuping 2013-09-13 06:18:42 UTC
Verified on AOO401m4(Build:9713)  -  Rev. 1521921 on Linux,Pass