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

List:       koffice-devel
Subject:    Re: Review Request: Fixed bugs in thumbnail creation mechanism
From:       "Dmitry Kazakov" <dimula73 () gmail ! com>
Date:       2009-07-14 21:38:58
Message-ID: 20090714213858.9537.30662 () localhost
[Download RAW message or body]



> On 2009-07-12 13:38:55, Boudewijn Rempt wrote:
> > I remember having had trouble with the exactbounds computation and adding that \
> > extra row column solved the problem. Not sure why anymore... But in general, \
> > reading a from a paint device should never create new tiles! 
> > On the filter thing, I think it grew historically like this -- I'm not sure about \
> > the reasns anymore, but maybe Cyrille knows?
> 
> Dmitry Kazakov wrote:
> That's a hack =)
> On creating tiles. Actually, reading doesn't create "a tile" in terms of old \
> engine. It just create a wrapper (KisTile), that doesn't store actual pixels, but \
> it shares default KisTileData that actually does. There is only consequence of such \
> behavior - extent of the data manager can be changed on reading. But i think that \
> is fully logic - if the reader reads from a part of canvas he is in charge of this \
> read, and he must ensure that he reads from existent part of canvas. There can be \
> two reasons of creation of a tile in a read: it's done intentively (e.g. resize of \
> the image) and broken code. So such behavior helps to find broken code too.
> 
> 
> Boudewijn Rempt wrote:
> No, definitely not! "if the reader reads from a part of canvas he is in charge of \
> this read, and he must ensure that he reads from existent part of canvas." -- \
> that's quite a wrong assumption. You should be able to read from anywhere without \
> changing anything to the canvas. 
> Dmitry Kazakov wrote:
> Well, i can't agree with you =( If you read a byte from the canvas, you mean (by \
> reading itself) that there is an image on it. What is the meaning of reading \
> vacuum? You have to read "something", some material object, and this object is you \
> image. Btw, can you suggest a usecase of being able to read everywhere without \
> changing anything?  I can't see any, not counting the case of letting wrong code \
> work longer :( (i mean the case in exactBounds() )

Well, yes. We shouldn't extend an extent. Usecase: merging.

But what about the patch? It doesn't rely on any "extending extents". It just fixes a \
bug in trunk. Extents was just a way i'd found this bug.

I have already fixed the call to exactBounds out of \
KisPaintDevice::createThumbnaiDevice, that Casper pointed out. What do you think \
about it now?


- Dmitry


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


On 2009-07-12 07:36:09, Dmitry Kazakov wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://reviewboard.kde.org/r/990/
> -----------------------------------------------------------
> 
> (Updated 2009-07-12 07:36:09)
> 
> 
> Review request for KOffice.
> 
> 
> Summary
> -------
> 
> There is a bug in thumbnails in filters dialog. If you open it and look at 'Invert' \
> thumbnail thoroughly, you'll see that it's thumb is quite higher than others. That \
> is so because filters applied to thumbs inside constant rect (100,100) [1]. \
> 'Invert' filter inverts defaultPixel and after that KisPaintDevice::exactBounds \
> won't work well, because there is no more defaultPixel in thumbnail. This bug is \
> fixed in this patch. 
> Alongside with this bug, there is a bug in KisPaintDevice::exactBounds. In cycles \
> of calculating right and bottom bounds, iterator reads one column/row more than \
> needed every time(!) [2]. This bug is not seen much in old tile engine, as reading \
> of unallocated areas was not causing any changes in internals of engine. But in new \
> one extent is extended by one tile to the right and bottom every time exactBounds() \
> called. This is fixed too. 
> And the last chunk - fix in KisPaintDevice::createThumbnailDevice(). Thumbnail \
> created only for actual image - not it's extent. 
> 
> [1] ui/kis_filters_model.cc:170
> [2] image/kis_paint_device.cc:251 and image/kis_paint_device.cc:287
> 
> 
> Diffs
> -----
> 
> trunk/koffice/krita/image/kis_paint_device.cc 995043 
> trunk/koffice/krita/ui/kis_filters_model.cc 995043 
> 
> Diff: http://reviewboard.kde.org/r/990/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]