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

List:       koffice-devel
Subject:    Re: Call on wise men for text on shape
From:       Thorsten Zachmann <t.zachmann () zagge ! de>
Date:       2010-06-28 6:52:02
Message-ID: 201006280852.02600.t.zachmann () zagge ! de
[Download RAW message or body]

On Sunday 27 June 2010 11:09:48 Thomas Zander wrote:
> > 4. You patch tests each shape if there is a text inside it. That has 2
> > problems:
> > o all shapes are tested if they contain text. That is quite some overhead
> > as it will iterate over all XML elements contained in the current xml
> > element of the shape.
> 
> In the same class there are several of such structures, checking for the
> frame,  checking for the group etc. Your claim of it being quite some
> overhead sounds strange as checking if a certain xml element is present is
> the main way of loading. Its essentially happens all over the place.
> As its the main way of iterating over a DOM structure its also highly 
> optimized.
> With that in mind, I'm open to some benchmarking results that show the
> total  impact of loading this way.
> If it does have a significant measurable impact we have some low hanging
> fruit  to optimize the DOM tree with :)

For a frame it is needed to walk over each sub item to find the best supported 
one.
For a group is needed as we need to load each member of the group.

I do not save that iterating over the structure is inefficient. Iterating over 
the elements that don't support the feature is inefficient and that is what your 
patch does. So that needs to be avoided.

> > o there are features that use the same way of saving of text like the
> > "wordart feature" which then will also get a text attached but should not
> > get one attached.
> 
> I'm wondering why you bring this up as the way of saving this is
> essentially  the same as the way the inheritance did things. The places
> where the saving code is called from is exactly the same.
> If this patch has that problem, why would inheritance not have that
> problem?

It is a problem in the loading code. By saving I do not mean the saving code 
in koffice but the structure that is saved in odf. As it uses the same 
structures as Text On Shape the loading code in your patch will create a text 
shape which is not wanted in this case.

Thorsten
_______________________________________________
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]