mirror of https://github.com/GNOME/gimp.git
*** empty log message ***
This commit is contained in:
parent
101d32ff16
commit
f12faae82a
|
@ -6,7 +6,6 @@ Sun Feb 14 4:28:00 CST 1999 Seth Burgess <sjburges@gimp.org>
|
|||
* plug-ins/sinus/sinus.c: changed macro definition supplied by
|
||||
Thomas to allow tilable sinus again.
|
||||
|
||||
>>>>>>> 1.858
|
||||
Sun Feb 14 23:11:30 CET 1999 Marc Lehmann <pcg@goof.com>
|
||||
|
||||
* libgimp/gimptile.c (gimp_tile_cache_ntiles): Round up, not down,
|
||||
|
|
|
@ -52,7 +52,8 @@ It does not need to concern users.
|
|||
The parasite data format is not rigidly specified. For non-persistant
|
||||
parasites you are entirely free, as the parasite data does not survive the
|
||||
current gimp session. If you need persistant data, you basically have to
|
||||
choose between the following alternatives:
|
||||
choose between the following alternatives (also, having some standard for
|
||||
non-persistant data might be fine as well):
|
||||
|
||||
- cook your own binary data format
|
||||
|
||||
|
@ -73,6 +74,9 @@ choose between the following alternatives:
|
|||
representation would be. Not much a problem for most applications,
|
||||
though.
|
||||
|
||||
You could also use one parasite per field you store, i.e. foo-size,
|
||||
foo-offset-x, foo-offset-y etc...
|
||||
|
||||
- use the libgimp serialize functions
|
||||
|
||||
Look at the stuff in libgimp/gserialize.h. These functions allow for
|
||||
|
@ -81,7 +85,30 @@ choose between the following alternatives:
|
|||
issues and other hazzles. The drawback is that you might encounter
|
||||
problems when you want to extend your structures later, as you have to
|
||||
be prepared for images saved with parasites form a very old version of
|
||||
your plug-in, and the gserialize functions do not (yet) handle different
|
||||
data formats nicely.
|
||||
your plug-in, and the gserialize functions do not handle different data
|
||||
formats nicely itself.
|
||||
|
||||
One way out around this is to prefix your data with a version identifier
|
||||
(remember to use a guchar, i.e. something without endian-ness problems).
|
||||
Depending on that (remember to skip it before deserializing)
|
||||
|
||||
Another very easy way is to add a version tag to your parasite name,
|
||||
i.e. "foo-bar-v1", "foo-bar-v2". Your plug-in could then check for older
|
||||
versions and act accordingly and/or attach the new parasite or both the
|
||||
new and the old version of your data.
|
||||
|
||||
The gserialize stuff also makes it possible to just append more fields
|
||||
(i.e. more gserialized structs) to your data. You could check the length
|
||||
of the parasite data ("anything left?") to decide wether to decode more
|
||||
fields. Here's some example:
|
||||
|
||||
data = parasite_data(p);
|
||||
size = parasite_data_size(p);
|
||||
length = gdeserialize(...);
|
||||
tlength += length;
|
||||
data += length;
|
||||
if (tlength != size)
|
||||
gdeserialize the next one, etc.
|
||||
|
||||
|
||||
|
||||
|
|
|
@ -119,7 +119,7 @@ gimp_tile_cache_size (gulong kilobytes)
|
|||
void
|
||||
gimp_tile_cache_ntiles (gulong ntiles)
|
||||
{
|
||||
gimp_tile_cache_size ((ntiles * _gimp_tile_width * _gimp_tile_height * 4) / 1024);
|
||||
gimp_tile_cache_size ((gulong)(ntiles * _gimp_tile_width * _gimp_tile_height * 4 + 1023) / 1024);
|
||||
}
|
||||
|
||||
guint
|
||||
|
|
Loading…
Reference in New Issue