← Back to branch summary

~ubuntu-branches/ubuntu/edgy/koffice/edgy-updates

« back to all changes in this revision

Viewing changes to kspread/FORMATTING_DESIGN

  • Committer: Bazaar Package Importer
  • Author(s): Ben Burton
  • Date: 2004-05-09 11:33:00 UTC
  • mto: This revision was merged to the branch mainline in revision 3.
  • Revision ID: james.westby@ubuntu.com-20040509113300-xi5t1z4yxe7n03x7
Tags: upstream-1.3.1
Import upstream version 1.3.1

Show diffs side-by-side

added added

removed removed

Lines of Context:
kspread/FORMATTING_DESIGN
 
1
I just want to store some notes here in CVS as a compilation of
 
2
what I understood from some previous discussion on redesigning -- wanted
 
3
to do this before it is forgotten.  It is very unlikely that I am 
 
4
going to have the time/motivation to do this myself but hopefully
 
5
this can help give a start to whomever does the work.  I don't think
 
6
anything here is definitive, and certainly if there are better ideas
 
7
than we should scrap these.  For Norbert/Phillip/Ariya this is just
 
8
to help keep track of our ideas, and hopefully the future will see
 
9
many more KSpread hackers who can use this as a head-start in thinking
 
10
about KSpread design.
 
11
 
 
12
 
 
13
NOTE: when I say 'pointer' in this description, I'm thinking of some shared
 
14
object kind of class with a reference count -- not a literal pointer
 
15
that we would have to remeber to delete...
 
16
 
 
17
 
 
18
 
 
19
The problem needing solved is that the class KSpreadCell (which has 
 
20
about a billion instantiations during a run of the program) is several
 
21
hundred bytes.  This is a tremendous waste of space, and most of it
 
22
is spent holding information such as font type/size/color, which borders
 
23
to draw and line thickness, background color, and so on.  Since this
 
24
information is going to be identical for a vast majority of cells, we 
 
25
should find an efficient way to share data among cells.
 
26
 
 
27
The first idea is to break the format information into small classes,
 
28
such as one for font size/type, one for border information and so on.
 
29
The way to save memory is to use a 'flyweight' system in which cells
 
30
would have a pointer to the data, so cells with the same formatting have
 
31
the same pointer and the information itself has only a single instantiation.
 
32
 
 
33
At first, we can simply use the copy constructor of this class to implement
 
34
the sharing, and if it seems profitable in the long run these classes
 
35
can keep some kind of static mapping so that in the constructor a check
 
36
can be done to see if, for instance, helvetica font size 12 has already
 
37
been allocated in the past and use that pointer rather than allocating
 
38
a 2nd instance.
 
39
 
 
40
 
 
41
 
 
42
 
 
43
Next, these format objects would be collected objects I was calling 'styles'
 
44
A style would basically be one of every type of Format object and thus
 
45
would completely define the format of the cell.  A style can be shared the
 
46
same way as a format object -- if two cells have all identical format
 
47
objects than they can share the same style object.
 
48
 
 
49
 
 
50
 
 
51
We had discussed two different ways of actually mapping these formats
 
52
and styles to particular cells.  
 
53
 
 
54
One way is to simply have
 
55
each cell contain a pointer to its style.  Rather than each cell using
 
56
200ish bytes to store the formatting, it has the single 4 byte pointer,
 
57
and then the the 200ish bytes is shared among all cells with that same
 
58
formatting information.
 
59
 
 
60
The other possibility is to map it by region.  This involves storing
 
61
a map of some sort in KSpreadTable to say, cells A2:E30 have this style,
 
62
column H has this style, etc.  Here, the cell itself would store no
 
63
formatting.  
 
64
 
 
65
If I remember correctly, we were leaning towards the second
 
66
method because of both the memory consumption, and because it is a simpler
 
67
way of handling setting formatting on a full column or row.  However
 
68
this method will be much more complex to implement in a way that there
 
69
can be efficient lookup to retrieve the current style for a particular cell.
 
70
 
 
71
 
 
72
 
 
73
Some things to decide:
 
74
 
 
75
How fine grained to make the format objects?
 
76
- How much information to store in each format object.  If there are a few,
 
77
  large format objects, than each Style is very small, requiring only a 
 
78
  single pointer for each of these few format objects.  However the data
 
79
  sharing is not very efficient if between 2 cells the font color changes, and
 
80
  there are 10 other pieces of data that are exactly the same
 
81
 
 
82
  If there is too little in each format object, than we don't gain any
 
83
  savings in memory because each additional type of format object results
 
84
  in an extra pointer in each style object
 
85
 
 
86
 
 
87
 
 
88
 
 
89
 
 
90
There's probably much more that can be put in here.
 
91
 
 
92
 
 
93
BTW, I hope to stay involved at least a little with KSpread.  It is unlikely
 
94
however that I will try to take on any large chunks of code unless I just get 
 
95
in a random programming fit on a weekend  :-)  
 
96
 
 
97
-John