[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:28:53
Message-ID: ae32c1ef0907141428o50a46fa0tb44e28900dce9d09 () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
Thanks for a good explanation and a good usecase!
I don't think picking a layer idea could apply to tiles (nevertheless it's a
good idea), but idea of isValid is quite interesting here.
When a tile is outside an extent, it's marked as invalid. It could be great
tool for debugging purposes. But it could create some overhead in normal
work.
Now i think that the most useful usecase of "NOT extending extent on read
operations" is merging. E.g. merging several layers with one small point on
every layer. If reads extended extent, we would have needed to merge all the
layers, instead of few small rects.
I'll try to fix it new engine...
2all:
Btw, what about the patch?
On Tue, Jul 14, 2009 at 1:13 PM, Thomas Zander <zander@kde.org> wrote:
> On Tuesday 14. July 2009 08.07.47 Dmitry Kazakov wrote:
> > The
> > question is "should we extend an extent of an image on read operations?"
> > I think yes. My arguments are:
> > 1) That is logical: read and write operation are symmetric (that is they
> > work in the same way) therefore behavior of tile manager is more
> > predictable for programmer.
> > 2) It doesn't hide any bugs in a caller's code. If you accidentally read
> > outside borders of the image, you'll see it in changed extent.
> >
> >
> > I still don't have any usecase of opposite behavior, can someone tell me
> > that?
>
> Re point 1; there are various APis that don't suggest this is more
> predictable. The point in general is that the API focusses its interaction
> one class.
> So you have QDomElement, QTextLine, iterators and various other classes
> like
> KWPage etc that wrap your data *and* have an isValid() method. This allows
> the programmer to optimize for the common case and not ask another API if
> the data wrapper object would actually be valid.
> So, its easier to allow non-valid objects to be created for the API since
> that will allow one class to be used instead of more for the common case.
>
> The solution for point 2 is different based on the usecase; in KWord
> querying
> a non-valid page object will just return dummy information. In QTextLine
> (which is lower level API, and meant to be fast) querying a non-valid
> object
> will dereference a null-pointer and crash. So its pretty easy do that
> isValid() or optimize if you are certain its not an issue.
>
> A valid usecase might;
> User right clicks on a position in the canvas and we want to show a popup
> of
> all the valid layers at that position. So we get the tile for that layer a
> that position and check if its valid. If it is, add an item to the popup,
> if
> its not then there is no image data at that position for that layer.
>
> A just as valid usecase from the perspective of a new programmer is that I
> iterate over the tiles until I get an invalid tile. That actually is a
> pretty common usage in something like QTextBlock API.
>
> Sorry for bias to kword/text for api examples. I'm sure there are valid
> examples outside my area of expertise ;)
> --
> Thomas Zander
>
> _______________________________________________
> koffice-devel mailing list
> koffice-devel@kde.org
> https://mail.kde.org/mailman/listinfo/koffice-devel
>
>
--
Dmitry Kazakov
[Attachment #5 (text/html)]
Thanks for a good explanation and a good usecase! <br><br>I don't think picking a \
layer idea could apply to tiles (nevertheless it's a good idea), but idea of \
isValid is quite interesting here.<br>When a tile is outside an extent, it's \
marked as invalid. It could be great tool for debugging purposes. But it could create \
some overhead in normal work.<br> <br>Now i think that the most useful usecase of \
"NOT extending extent on read operations" is merging. E.g. merging several \
layers with one small point on every layer. If reads extended extent, we would have \
needed to merge all the layers, instead of few small rects.<br> <br>I'll try to \
fix it new engine...<br><br>2all:<br>Btw, what about the patch?<br><br><div \
class="gmail_quote">On Tue, Jul 14, 2009 at 1:13 PM, Thomas Zander <span \
dir="ltr"><<a href="mailto:zander@kde.org">zander@kde.org</a>></span> \
wrote:<br> <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, \
204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="im">On Tuesday \
14. July 2009 08.07.47 Dmitry Kazakov wrote:<br> > The<br>
> question is "should we extend an extent of an image on read \
operations?"<br> > I think yes. My arguments are:<br>
> 1) That is logical: read and write operation are symmetric (that is they<br>
> work in the same way) therefore behavior of tile manager is more<br>
> predictable for programmer.<br>
> 2) It doesn't hide any bugs in a caller's code. If you accidentally \
read<br> > outside borders of the image, you'll see it in changed extent.<br>
><br>
><br>
> I still don't have any usecase of opposite behavior, can someone tell me<br>
> that?<br>
<br>
</div>Re point 1; there are various APis that don't suggest this is more<br>
predictable. The point in general is that the API focusses its interaction<br>
one class.<br>
So you have QDomElement, QTextLine, iterators and various other classes like<br>
KWPage etc that wrap your data *and* have an isValid() method. This allows<br>
the programmer to optimize for the common case and not ask another API if<br>
the data wrapper object would actually be valid.<br>
So, its easier to allow non-valid objects to be created for the API since<br>
that will allow one class to be used instead of more for the common case.<br>
<br>
The solution for point 2 is different based on the usecase; in KWord querying<br>
a non-valid page object will just return dummy information. In QTextLine<br>
(which is lower level API, and meant to be fast) querying a non-valid object<br>
will dereference a null-pointer and crash. So its pretty easy do that<br>
isValid() or optimize if you are certain its not an issue.<br>
<br>
A valid usecase might;<br>
User right clicks on a position in the canvas and we want to show a popup of<br>
all the valid layers at that position. So we get the tile for that layer a<br>
that position and check if its valid. If it is, add an item to the popup, if<br>
its not then there is no image data at that position for that layer.<br>
<br>
A just as valid usecase from the perspective of a new programmer is that I<br>
iterate over the tiles until I get an invalid tile. That actually is a<br>
pretty common usage in something like QTextBlock API.<br>
<br>
Sorry for bias to kword/text for api examples. I'm sure there are valid<br>
examples outside my area of expertise ;)<br>
--<br>
<font color="#888888">Thomas Zander<br>
</font><br>_______________________________________________<br>
koffice-devel mailing list<br>
<a href="mailto:koffice-devel@kde.org">koffice-devel@kde.org</a><br>
<a href="https://mail.kde.org/mailman/listinfo/koffice-devel" \
target="_blank">https://mail.kde.org/mailman/listinfo/koffice-devel</a><br> \
<br></blockquote></div><br><br clear="all"><br>-- <br>Dmitry Kazakov<br>
_______________________________________________
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