[prev in list] [next in list] [prev in thread] [next in thread] 

List:       koffice-devel
Subject:    Re: Review Request: Refactoring for KisPrescaledProjection plus
From:       "Dmitry Kazakov" <dimula73 () gmail ! com>
Date:       2009-08-05 12:35:51
Message-ID: 20090805123551.21962.67832 () localhost
[Download RAW message or body]


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://reviewboard.kde.org/r/1156/
-----------------------------------------------------------

(Updated 2009-08-05 12:35:51.021256)


Review request for KOffice.


Changes
-------

Here is the second version of the patch with refactoring for KisPrescaledProjection. \
I've spent almost a week to understand fully this "subpixels" drawing. Here was a \
couple of bugs in previous version.

Most significant changes:
1) KisProjectionCache ang KisImagePyramid are now derived from a base class \
KisProjectionBackend 2) Drawing itself is moved out from KisPrescaledProjection. Now \
all (almost all) drawing is done through a special stucture named a "patch". Why is \
it needed? In previos versions of KisPrescaledProjection we were requesting small \
QImage tiles of a projection to draw them on a canvas. We took them from a backend, \
scaled them down (with Blitz or QPainter - no difference) and then drew them onto \
m_prescaledQImage. It was a not good idea really. What about border effect in \
billinear scaling? That's why we got artefacts on small scales (~30%)[1] and that's \
why we couldn't use smoothScale on huge scales (~1600%) (btw, we still can't use \
smooth scale on level 1600% exactly due to some Qt's optimization (see below), but we \
can use it on 1601% level and others =) )  This problem is solved with "patches" \
system. We request some rect (a "patch") from the backend, but it returns us a bit \
more pixels, than we asked. Those pixels will help us to eliminate border effect. 3) \
Usage of the mipmapping is controlled by "useMipmapping" entry of a config file. Btw, \
i think we should change configuration of zooming a bit. I think it should be like:

zoomBackend: cache | mipmapping
zoomAlgo0to100: nearestNeighbour | bilinear
zoomAlgo100to200: nearestNeighbour | bilinear
zoomAlgoAfter200: nearestNeighbour | bilinear

What do you think?

4) And of course mipmapping added =)

===
Known bugs and fixmes:
1) Sometimes canvas is bounded by one-pixel white lines at right and bottom edges. I \
know it's due to some rounding in KisProjectionCache but i don't know how to fix it \
better. We convert image<->canvas pixels twice during one update. This a legacy \
procedure. I think i'll change it soon. 2) I don't know whether we should prescale a \
patch with Blitz. Does it really gives us time benefit? 3) Patch borders don't work \
with large images due to indirect painting stuff. We can't request KisImage for \
QImages when we want.

Mipmapping:
4) Still no threading
5) Should use SSE for downsampling
6) It's a bit more slowly than projectionCache due to the use of tiled paint device. \
It needs some profilng.


Summary (updated)
-------

Makes prescaled projection code simplier and clearer. It also removes weird [1], \
simply unused [2] and previously unused code with bugs [3].

Most significant changes:
1) imageRectFromViewPortPixels and viewRectFromImagePixels now just convert rects' \
coords, without respect to canvas size (they still do respect image size).  2) They \
both made _private_ so this change won't brake anything outside 3) Broke the link \
from KisCanvas2 to KisPrescaledProjection::viewRectFromImagePixels. It was quite bad \
idea to use internal conversion function from outside. Reasons:  a) they are internal
    b) vRect can be changed (expanded) by prescaled projection during update (mipmap \
case)  c) viewRectFromImagePixels was called twice: from KisCanvas2 first and then \
from KisPrescaledProjection::updateCanvasProjection again 4) now it's easier to \
maintain


[1] kis_pescaled_projection.cc:412-431
[2] kis_pescaled_projection.cc:396-403
[3] kis_pescaled_projection.cc:532


Diffs (updated)
-----

  trunk/koffice/krita/ui/CMakeLists.txt 1000698 
  trunk/koffice/krita/ui/canvas/kis_canvas2.cpp 1000698 
  trunk/koffice/krita/ui/canvas/kis_image_pyramid.h PRE-CREATION 
  trunk/koffice/krita/ui/canvas/kis_image_pyramid.cpp PRE-CREATION 
  trunk/koffice/krita/ui/canvas/kis_prescaled_projection.h 1000698 
  trunk/koffice/krita/ui/canvas/kis_prescaled_projection.cpp 1000698 
  trunk/koffice/krita/ui/canvas/kis_projection_backend.h PRE-CREATION 
  trunk/koffice/krita/ui/canvas/kis_projection_backend.cpp PRE-CREATION 
  trunk/koffice/krita/ui/canvas/kis_projection_cache.h 1000698 
  trunk/koffice/krita/ui/canvas/kis_projection_cache.cpp 1000698 
  trunk/koffice/krita/ui/kis_config.h 1000698 
  trunk/koffice/krita/ui/kis_config.cc 1000698 
  trunk/koffice/krita/ui/tests/kis_prescaled_projection_test.cpp 1000698 

Diff: http://reviewboard.kde.org/r/1156/diff


Testing
-------


Thanks,

Dmitry

_______________________________________________
koffice-devel mailing list
koffice-devel@kde.org
https://mail.kde.org/mailman/listinfo/koffice-devel


[prev in list] [next in list] [prev in thread] [next in thread] 

Configure | About | News | Add a list | Sponsored by KoreLogic