Bug 91486

Summary: Saving image modified in the image viewer using Ctrl+S causes graphical glitch
Product: [Applications] digikam Reporter: Michał Kosmulski <michal>
Component: ImageEditor-SaveAssignee: Digikam Developers <digikam-bugs-null>
Status: RESOLVED FIXED    
Severity: normal CC: caulier.gilles
Priority: NOR    
Version First Reported In: unspecified   
Target Milestone: ---   
Platform: unspecified   
OS: Linux   
Latest Commit: Version Fixed/Implemented In: 7.5.0
Sentry Crash Report:

Description Michał Kosmulski 2004-10-17 00:04:24 UTC 
Version:           0.7 beta 1 (using KDE KDE 3.3.0)
Compiler:          gcc 3.3.4 
OS:                Linux

When an image is modified in the image viewer, pressing Ctrl+S causes the file to be saved, but at the same time a strange flicker happens - it looks as if the image's top edge was moved down a pixel or several pixels.
Comment 1 caulier.gilles 2004-10-17 09:32:04 UTC 
I have already reported this bug to Renchi Raju in the past. 

I will try to fix it in the future...

Gilles Caulier
Comment 2 Joern Ahrens 2004-10-17 23:03:10 UTC 
I only happens if "zoom autofit" is enabled.
Comment 3 caulier.gilles 2004-10-17 23:08:34 UTC 
Yes, me too...

Something is wrong in the repaint event...

Gilles
Comment 4 Renchi Raju 2004-10-20 16:18:57 UTC 
i had a close look at this and i believe the problem is in calculation of the image clipping if you render only a small section of the image. depending on how these sections are painted, adjacent sections will have mismatch. i have tried out a tile based approach where image is split into small tiles of equal size and then painted and that seems to fix it. but it also breaks the current selection mask process. since all these needs substantial changes in the code and it doesn't severely hampers usability, i will defer this to 0.7.1 release.
Comment 5 Renchi Raju 2004-11-22 08:27:18 UTC 
CVS commit by pahlibar: 


* reworked the image painting routines:
  - the painting is done onto pixmaps tiles which 
    are cached
  - tile size is 512x512 (surprisingly the speed of
    the scaling routines in imlib2 tends to scale 
    non-linearly, i.e. its much faster to render one big
    tile than a bunch of small ones). that's why such
    a big tile size. at most 20 tiles are cached at one
    time.
  - tile updating and painting is done on demand - expose,
    paint, cache
  - fixes glitches in the painting
* minor change: the blended color has been changed to a
  shade of grey with slightly more opaqueness. i have found
  this color to be more usable than the previous darker blend
BUG: 91486


  M +157 -141  canvas.cpp   1.25
  M +4 -5      canvas.h   1.15
  M +3 -3      imagewindow.cpp   1.55
  M +21 -61    imlibinterface.cpp   1.32
  M +9 -8      imlibinterface.h   1.16