Bug 91486 - Saving image modified in the image viewer using Ctrl+S causes graphical glitch
Summary: Saving image modified in the image viewer using Ctrl+S causes graphical glitch
Status: RESOLVED FIXED
Alias: None
Product: digikam
Classification: Applications
Component: ImageEditor-Save (show other bugs)
Version: unspecified
Platform: unspecified Linux
: NOR normal
Target Milestone: ---
Assignee: Digikam Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2004-10-17 00:04 UTC by Michał Kosmulski
Modified: 2022-02-03 04:07 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In: 7.5.0


Attachments

Note You need to log in before you can comment on or make changes to this bug.
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