modules cleanup
The GIMP's modules for OS/2 need some extra handling.
It's copied into the 3-4 modules C files and it's also not
updated. I want to clean up this code.
I suggest to create a new file called modregister.c and put
all the "register" things there. Modules have to link the new file.
The will be no new features only a cleaner design.
OK ?
Here is the original code (ugly and copied 3 times) :
#ifdef __EMX__
struct main_funcs_struc {
gchar *name;
void (*func)();
};
struct main_funcs_struc *gimp_main_funcs = NULL;
static gpointer
get_main_func(gchar *name)
{
struct main_funcs_struc *x;
if (gimp_main_funcs == NULL)
return NULL;
for (x = gimp_main_funcs; x-name; x++)
{
if (!strcmp(x-name, name))
return (gpointer) x-func;
}
}
typedef GimpColorSelectorID (*color_reg_func)(const char *,
GimpColorSelectorMethods *);
typedef gboolean (*color_unreg_func) (GimpColorSelectorID,
void (*)(void *),
void *);
#endif
/* globaly exported init function */
G_MODULE_EXPORT GimpModuleStatus
module_init (GimpModuleInfo **inforet)
{
GimpColorSelectorID id;
#ifndef __EMX__
id = gimp_color_selector_register ("GTK", "gtk.html", methods);
if (id)
#else
color_reg_func reg_func;
reg_func = (color_reg_func) get_main_func("gimp_color_selector_register");
if (reg_func (id = (*reg_func) ("GTK", methods)))
#endif
{
info.shutdown_data = id;
*inforet = info;
return GIMP_MODULE_OK;
}
else
{
return GIMP_MODULE_UNLOAD;
}
}
***
* Asbjørn Pettersen Phone work: +47 77 66 08 91 *
* Kongsberg Spacetec a.s Phone home: +47 77674022 *
* Telefax:+47 77 65 58 59 *
* Prestvannveien 38 www:http://www.spacetec.no *
* N-9005 Tromsoe, Norway email:[EMAIL PROTECTED] *
***
Re: modules cleanup
On Monday, 8 Nov 1999, Asbjoern Pettersen wrote: The GIMP's modules for OS/2 need some extra handling. It's copied into the 3-4 modules C files and it's also not updated. I want to clean up this code. The same problem was occurring on Solaris2. Yosh has now tweaked some of the libtool options so that it should now work. Do these fixes for Solaris2 also fix the problem under OS/2? I suggest to create a new file called modregister.c and put all the "register" things there. Modules have to link the new file. The will be no new features only a cleaner design. I'm all for a cleaner design. Ideally we should be doing the same thing for all architectures, rather than using nasty #ifdefs everywhere. Also, still to be fixed with the module code is a version check as suggested by Tim Janik a long time ago, and unloading modules from the idle loop (which should make the perl module self-unloadable). I'm not particularly happy with the OS/2 solution, it seems a little ugly, but I'm not sure why exactly I don't like it. Austin
Re: Re: Tile Cache Size
On Wed, Nov 03, 1999 at 05:40:03PM -0600, Tim Mooney [EMAIL PROTECTED] wrote: As far as I know, most Unix and Unix-like OSes will generally try give you the space you're requesting as a contiguous chunk. In the case of files like a (e.g.) 40 Meg swap-file for the gimp, that may not be possible, even for a filesystem that is much less than 50% full. All it takes is "average" fragmentation to ruin the OS' ability to give you a contiguous chunk. Then you have to convince me (you don't have, but I won't believe you) that this is a problem... surely, each ~8MB chunk of a large file is fragmented on an ext2 file system _by definition_, but these are very large chunks. This means, I think, that all bets *are* off, at least regarding the gimp's ability to keep tiles "close" on-disk. I think that on an OS that encourages fragmentation you are right. However, I can't think of a common os in use that allows to run gimp and has such a bad filesystem. The bigger the swap file, the less likely it is that the gimp will be able to do this. That's why I asked my original question. But this is not at all a problem. For example, on my 8GB main (i.e. /usr, /home) partition that I already use since two years ans that is 95% full (too full for the file system in question) I have 0.5% fragmentation. Only two files have fragmented chunks smaller than 8MB (the maximum). In any case, since you think this is bad (and I think this is good), only hard data would clear this problem. However, as a matter of fact, linux' swapping (the os with the ext2 fs) is _far_ worse than _any_ application-side swapping. -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | |
Re: Rendering text with gimp_perl and gimp_text
On Wed, Nov 03, 1999 at 08:20:14AM +0100, Martin Treusch von Buttlar [EMAIL PROTECTED] wrote: There is currently only a windows 95 environment for this and I am Is it commercial (bd ;)? The bottom of ru should be on the same y-pos as the baseline of Äq. While I think it would be a nice option you didn´t really convince me that this is the way to go. Why? Because you can implement both behaviours with the current semantics, but only one behaviour (yors) with your proposed semantics. textlayers have the same height now, though ru is still at the top. I get different sized layers. Gimp 1.1.7 Maybe this has changed in 1.1.0 (which I'm using currently). On Thu, Nov 04, 1999 at 04:24:10PM +0100, Martin Treusch von Buttlar [EMAIL PROTECTED] wrote: Getting the ascent/descent of one font is no problem using gimp_text_get_extents. Getting the information if a given string has a ascent or descent _is_. I must have misunderstood your problem: why do you want to know the ascent or the descent of a given string? - "knowing" which letters have a descent|ascent. Bad if you have dif- ferent types of fonts. More important still this knowledge is ex- ternal. And not even defined. - letting the gimp_text_get_extents return two additional fields, namely ($has_ascent,$has_descent). I favour the last ;) But that wouldn't help you... wether a given character/string has an ascent doesn't tell you how much it is (which is what you want to know?) -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | |
Re: Help System
On Wed, Nov 03, 1999 at 10:47:48AM +0100, Uwe Koloska [EMAIL PROTECTED] wrote: Consider that GtkXmHTML cannot be compiled on linux libc5 systems (or generally systems without thread support) because it needs the threaded version of My very own personal opinion on this is: - either make gimp a gnome application (puke!). This would be honest, as we are kind-of forcing gnome on people anyway (wanna help? use gnome!) - unbundle the help system (or don't ever claim the gimp would have such a help system - fact is it doesn't work) A help system that only works by chance (i.e. not on the majority of platforms) is not work the hassle. -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | |
Re: Plugins
On Wed, Nov 03, 1999 at 11:07:32AM +0100, Uwe Koloska [EMAIL PROTECTED] wrote: I don't know anything about the actual CVS-release but with 1.1.10 I have to disable nls-support, because there are so many doubled menus (some german, some english). Maybe it's because I'm using a libc5 based system but I think there are many systems out there with similar problems. Strange that I don't encounter this problem (that sever), maybe the version we used for the booth at the Systems '99 had a much better german translation? In any case, this problem is a totally seperate issue (as I talked about with Daniel). A solution (workaround, fix...) would be to do it like perl, i.e. translate by component unless there is a better translation. E.g. Toolbox/Xtns/Animation/Seth Spin = Toolbox/Xtn/Animation/Seth's Dreher (translation available) Toolbox/File/Selection/Add Selection = Toolbox/Datei/Auswahl/Add Selection (only a partila translation for File/Selection available) This would solve your problem for the vast majority of untranslated (E.g. third-party) plug-ins. Well, what I understand about half-translated plug-ins is, that if the binding for the inclusion in menus and so on is fully translated and the rest isn't that isn't bad, but if some menu entries are and others not is very bad. Would it still be a problem for you if only the menu entry itself is english, but the english menu is sorted under the corresponding german standard menu (see above for "Add Selection")? -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | |
Re: Plugins
On Sun, Nov 07, 1999 at 08:39:51PM +0100, [EMAIL PROTECTED] wrote: This sounds interesting (explain!).. how can i18n lead to segfaults? Not again Marc, we have had this discussion before You told me that all my menus would be shown twice (which was a problem on your machine only). Hint: It's the way menues are handled by Gtk... And if this leads to segfaults it is surely a bug in gkt+? No, really, I am _simply_ interested in how a call to gettext can result in a "legal" segfault. But since its purely for my own pleasure you don't have to explain... (I am serious, btw!) Me included! Maybe I shouldn´t even reply here.. ;- Maybe :) Well, if you care that I won´t repeat the same error again it would be nice if you explained the bug... I don't think so. Half-translations can be really confusing and annoying for a user. Ok, then let's vote on this. "I vote that this is less confusing..." Maybe we should just push the translators a bit for the release (unless code changes are necessary).. Push me, please... PUSH! Half-translated plug-ins are definitely no reason to forget it!! I mean, do you want to translate "ls" to "vz" with LANG=de? I don't understand your intention here... what should "ls" and "vz" be? "ls" is ls(1) and "vz" is the shortcut for "verzeichnis". mixed language environments are the rule today, not the exception. That doesn't make them any better I think it's the only way to go. Look at how M$ handles translation (by looking at i18n'ed visual basic for example ;) I don`t mind it either.. I know, but you aren't supposed to be the average user, are you? Well, I have an opinion about half-trabslation that is just as good as any opinion from an average user. The gimp is not the only i18n'ed project, and I didn't speak english all the time in the past... -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | |
Re: Plugins
On Wed, Nov 03, 1999 at 10:20:37AM +0100, Michael Natterer [EMAIL PROTECTED] wrote: I was (or at least tried to be) very careful not to change any external interface (which I suppose you mean by "cause other changes as well") with the context changes because playing around with the PDB interface in freeze mode looks dangerous to me... I'm sorry... do you really say that you won't implement the context stuff fully for 1.2? I had always thought that the work would be finished before 1.2 So please let me know if you find the semantics of any PDB brush/color/pattern/gradient function changed and I'll restore the old semantics. I don't expect them to be changed yet. I would have appreciated this very much, this would probably result in much less work on my side (no backward-compatibility crap). If you are about to break the pdb interface we should do it now, not later. Doing it later is just awkward, resulting in more work from many others (update it to 1.2, and then to 1.3 again. Doing the major work once would be much better). BTW: I appreciated both new features a lot! :-) But AFAICS, there is only one new feature... -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | |
Re: Rendering text with gimp_perl and gimp_text
Marc Lehmann [EMAIL PROTECTED] writes: I must have misunderstood your problem: why do you want to know the ascent or the descent of a given string? AFAIUTP, it isn't possible for a given text layer to tell where the baseline is. So it isn't possible for different text layers to line up. The ascent and descent are stupidly reported for the font, not the given string. jtl
Re: Re: Tile Cache Size
I rather think _you_ are missing the point (which is disk layout and minimizing seeks, and _not_ a better memory layout. The tile based scheme leads itself naturally to spatial indexing, in fatc it's already half the way to go). About HD: is there a way to do swap on demand to a partition? A daemon, lib or something? I think that is what high end DBs do, handle their own data physical space. Just and idea based in what I have heard. Discard at will. GSR
Re: Re: Tile Cache Size
On Tue, Nov 09, 1999 at 12:04:14AM +0100, "Guillermo S. Romero / Familia Romero" [EMAIL PROTECTED] wrote: About HD: is there a way to do swap on demand to a partition? A daemon, lib or something? is this gimp-related (?) or do you want something like swapd? or swap priorities? I think that is what high end DBs do, handle their own data physical these high end db's also do not recommend this technique ;- -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | |
Re: Re: Tile Cache Size
About HD: is there a way to do swap on demand to a partition? A daemon, lib or something? is this gimp-related (?) or do you want something like swapd? or swap priorities? I know what swapd and swap priorities are (I think I do, OS thing and how partitions are used). I am speaking about something that "owns" a partition (or filesystem or warp generator) and accepts request from apps like "hey you! move this are of my RAM to your storage" and "quickly! give me back the data I give you some minutes ago". So Gimp could use it, instead of using OS things (swap or filesystem). I guess everybody will agree that a partition handled by one process (with high performance in mind) is a good solution. Well, now you can point why my suggestion is 100% wrong. ;] I think that is what high end DBs do, handle their own data physical these high end db's also do not recommend this technique ;- Really? Maybe time to get a book about DB implementation. Damn, so many thing, so few time. GSR
Re: Rendering text with gimp_perl and gimp_text
On Mon, 8 Nov 1999, Marc Lehmann wrote: I must have misunderstood your problem: why do you want to know the ascent or the descent of a given string? I've only been following this thread on-and-off so please forgive any ignorance :-) One problem with the current system that I encountered was as follows :- I wanted to write a script-fu to generate a logo with each letter of the string in a different color. (See http://www.flamingtext.com/net-fu/forms/colored-logo.html) To do this each character in the string of course has to be rendered individually. But if you just render them one after the other, increasing the x-offset by the width of the rendered character each time, then the baselines are all over the place. I worked around this problem by rendering (string-append char " " str), where char is the current character and str is the full string and " " is a bunch of spaces so that kerning doesn't leave dags behind. After redering that string I use gimp-text-get-extents to get the width of char and increase x-offset by that amount. - letting the gimp_text_get_extents return two additional fields, namely ($has_ascent,$has_descent). I favour the last ;) But that wouldn't help you... wether a given character/string has an ascent doesn't tell you how much it is (which is what you want to know?) Yep, you're right, that info tells you didly! But if it returned the baseline of the rendered text (as a offset from the top or bottom of the text area) then that could be used to translate the text area if required. -Dave -- http://www.flamingtext.com/
Re: Rendering text with gimp_perl and gimp_text
On Mon, 8 Nov 1999, Marc Lehmann wrote: The ascent and descent are stupidly reported for the font, not the given string. Ok, then I'd say this is a very bad bug ;) I'd suggest fixing it by not removing any space from the text layer / the tetx string returned by gimp_text. Or add a new function, say gimp_text_ex, that has one additional flag which controls whether the space is removed or not, and change gimp_text to simply call gimp_text_ex with a value of false for this flag. That way you won't break every script that uses gimp-text. -Dave -- http://www.flamingtext.com/
Re: Re: Tile Cache Size
On Tue, 9 Nov 1999, Guillermo S. Romero / Familia Romero wrote: So Gimp could use it, instead of using OS things (swap or filesystem). I guess everybody will agree that a partition handled by one process (with high performance in mind) is a good solution. What's wrong with using mmap? You can even map a raw partition if you want. (According to the man page, I've never tried it). -Dave -- http://www.flamingtext.com/
Re: Re: Tile Cache Size
Marc Lehmann ([EMAIL PROTECTED]) wrote: But this is not at all a problem. For example, on my 8GB main (i.e. /usr, /home) partition that I already use since two years ans that is 95% full (too full for the file system in question) I have 0.5% fragmentation. Only two files have fragmented chunks smaller than 8MB (the maximum). I think 2 things need to be clearly seperated here: 1. The fragmentation of the swap file on the harddisk. I agree that this is a bit of a non issue with the ext2 filesystem (even if the swapfile gets fragmented a bit it's no big deal); 2. The fragmentation of tiles within the swap file. The sound of Gimp trashing the harddisk suggests that this is a very big issue. Anyway, today I went over the Gimp sources and noticed how complicated the tile architecture makes things and I couldn't help wondering why the heck it was put in. All it seems to do is to give you an order of magnitude slower speed when dealing with large images. And large images were supposed to be the very reason for a tiling architecture. -- -- Ewald
Re: Re: Tile Cache Size
On Tue, 9 Nov 1999, Ewald R. de Wit wrote: Anyway, today I went over the Gimp sources and noticed how complicated the tile architecture makes things and I couldn't help wondering why the heck it was put in. All it seems to do is to give you an order of magnitude slower speed when dealing with large images. And large images were supposed to be the very reason for a tiling architecture. I'm afraid I have to agree with you on the performance WRT large images. I tried editing a couple of large images yesterday (10MB/600dpi) and it was painfully slow (Dual 300MHz PII, 128MB RAM). I've got a 20MB/1200dpi one I want to edit and I'm not looking forward to it! -Dave
Re: Re: Tile Cache Size
On Tue, 9 Nov 1999, David Bonnell wrote: On Tue, 9 Nov 1999, Ewald R. de Wit wrote: Anyway, today I went over the Gimp sources and noticed how complicated the tile architecture makes things and I couldn't help wondering why the heck it was put in. All it seems to do is to give you an order of magnitude slower speed when dealing with large images. And large images were supposed to be the very reason for a tiling architecture. I'm afraid I have to agree with you on the performance WRT large images. I tried editing a couple of large images yesterday (10MB/600dpi) and it was painfully slow (Dual 300MHz PII, 128MB RAM). I've got a 20MB/1200dpi one I want to edit and I'm not looking forward to it! Hmm. Are you setting the tile cache size to something reasonable? It will definitely suck with the default 10mb tile cache... later, Andrew Kieschnick
Re: Re: Tile Cache Size
On Tue, Nov 09, 1999 at 01:27:29AM +0100, Ewald R. de Wit wrote: Anyway, today I went over the Gimp sources and noticed how complicated the tile architecture makes things and I couldn't help wondering why the heck it was put in. All it seems to do is to give you an order of magnitude slower speed when dealing with large images. And large images were supposed to be the very reason for a tiling architecture. I have no idea where this came from, Ewald did you actually do any benchmarking, or just a few thought experiments? Computers do not behave in practise as it may seem they should ideally. Here are some practical results from my real Gimp machine, a PII 300MHz with 64Mb of memory and ~64Mb of swap. This is with CVS Gimp. If I configure Gimp to believe that it has as much memory as one might conceivably need, then the results are as follows: Loading a large image (*): Wait 10 mins, get bored, try to kill, but the machine is in a swap death loop, after 5 more minutes, just as I log in as root from a serial console, X experiences resource starvations and so Gimp, Gnome, xterms and everything go into the drink. If I configure Gimp with a large but not improbable tile cache (64Mb): Loading a large image (*): Wait 5 mins, TIFF loader finishes, after a further 10 mins the image has been drawn at 10:1 reduction. Now with the defaults as supplied (12Mb ISTR): Loading a large image (*): Wait about 2 mins, loader finishes and now after a further 2 or 3 mins the image has been drawn. And finally with my preferred settings (20Mb): Loading a large image (*): Wait about 2 mins, loader finishes and now after a further couple of minutes the image is drawn, however later performance is slightly faster than in the default case above. (*) A large image here is one which genuinely WILL NOT fit in memory, by any stretch of the imagination. It is a JPEG tiled TIFF (nasty!) of dimensions 7274x9985 and in full 24-bit colour. Nick.
Re: Re: Tile Cache Size
Further to my last post (and possibly related to Ewald's complaints too) Why does my 7274 x 9985 RGB image (212743Kb of data by my calculations) result in the creation of a gimpswap which is up to 500Mb in size? The performance for such images seems adequate to me (can't compare PotatoShop because it refuses to load any of our larger images at all) but this is wasting a lot of active disk space :( Nick.
Re: Re: Tile Cache Size
On Mon, 8 Nov 1999, Andrew Kieschnick wrote: Hmm. Are you setting the tile cache size to something reasonable? It will definitely suck with the default 10mb tile cache... Bumped it up to 60MB and it's better. Something as simple has hiding one of the layers takes about 10 seconds to complete. (Took about 20-30secs before I think). Or moving a rectangular region of one layer (which should affect only the union of the pixels under the src and dest rectangles?) takes about 10 seconds too. (Again, was probably almost 20 seconds before increasing the tile cache size). -Dave
Re: modules cleanup
On Mon, 8 Nov 1999 17:13:08 + (GMT), Austin Donnelly wrote:
The GIMP's modules for OS/2 need some extra handling.
It's copied into the 3-4 modules C files and it's also not
updated. I want to clean up this code.
The same problem was occurring on Solaris2. Yosh has now tweaked some
of the libtool options so that it should now work. Do these fixes for
Solaris2 also fix the problem under OS/2?
I'm not useing libtool, and i prefer to fix problems at run-time not at LINK-time.
Problems and inputs should be solved/handled in the code and not in
compiler,linker,loader,fork,,,.
Here is an example with gimp_main() (for plug-ins)
UNIX:
int main (int argc, char *argv[])
{
return gimp_main (argc, argv);
}
OS/2:
int main (int argc, char *argv[])
{
set_gimp_PLUG_IN_INFO(PLUG_IN_INFO); /* Yes it's input to gimp_main() */
return gimp_main (argc, argv);
}
The OS/2 and UNIX code is doing the same !
The structure PLUG_IN_INFO is a REAL input and should be a parameter
input to gimp_main().ex: gimp_main(argc,argv, PLUG_IN_INFO);
On UNIX they trust/use fork() to input the structure, but my OS/2 version will work
on all system with or without forking.
It's more readable too.
I suggest to create a new file called modregister.c and put
all the "register" things there. Modules have to link the new file.
The will be no new features only a cleaner design.
I'm all for a cleaner design. Ideally we should be doing the same
thing for all architectures, rather than using nasty #ifdefs
everywhere.
Also, still to be fixed with the module code is a version check as
suggested by Tim Janik a long time ago, and unloading modules from the
idle loop (which should make the perl module self-unloadable).
I'm not particularly happy with the OS/2 solution, it seems a little
ugly, but I'm not sure why exactly I don't like it.
I don't like it either. That's why i want to clean it up.
Austin
Asbjoern P.
***
* Asbjørn Pettersen Phone work: +47 77 66 08 91 *
* Kongsberg Spacetec a.s Phone home: +47 77674022 *
* Telefax:+47 77 65 58 59 *
* Prestvannveien 38 www:http://www.spacetec.no *
* N-9005 Tromsoe, Norway email:[EMAIL PROTECTED] *
***
