From f12faae82a3d9d693306d552e6c5a2e2222957aa Mon Sep 17 00:00:00 2001 From: Marc Lehmann Date: Sun, 14 Feb 1999 22:56:10 +0000 Subject: [PATCH] *** empty log message *** --- ChangeLog | 1 - docs/parasites.txt | 33 ++++++++++++++++++++++++++++++--- libgimp/gimptile.c | 2 +- 3 files changed, 31 insertions(+), 5 deletions(-) diff --git a/ChangeLog b/ChangeLog index 1b7b53f5b3..69cc60b22a 100644 --- a/ChangeLog +++ b/ChangeLog @@ -6,7 +6,6 @@ Sun Feb 14 4:28:00 CST 1999 Seth Burgess * 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 * libgimp/gimptile.c (gimp_tile_cache_ntiles): Round up, not down, diff --git a/docs/parasites.txt b/docs/parasites.txt index e2a30f61d6..7aa3adb649 100644 --- a/docs/parasites.txt +++ b/docs/parasites.txt @@ -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. + diff --git a/libgimp/gimptile.c b/libgimp/gimptile.c index 98c8400ecc..d08a7648d1 100644 --- a/libgimp/gimptile.c +++ b/libgimp/gimptile.c @@ -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