Re: [Gimp-developer] Patch shortening GIMP startup time
On Mon, 2010-08-30 at 23:31 +0200, Łukasz Czerwiński wrote:
> I have made several optimizations in loading script-fu extension
> making the loading process a bit faster. It's the first time I change
> something in an open source program and don't know best way to
> "announce" it and get it reviewed, so I send a patch in a mail.
> The major speedup is caused by calling my function load_script_file
> instead of script_fu_run_command("(load "). Please review my
> changes and send an answer if the patch is OK.
Thanks for your patch. It definitely needs some work though. First of
all it is not OK to comment out code. If code should be removed, then
please remove it.
Passing a string literal directly to g_message() is also not a good
idea. Please use g_message("%s", message) instead. But I didn't
understand what this part of your patch is trying to achieve.
Overall it would help a lot if you could explain what your patch tries
to achieve and what the purpose of the changes are. I have not been able
to understand the benefits of your changes just by looking at the patch.
Sven
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Patch shortening GIMP startup time
Hello,
I have made several optimizations in loading script-fu extension making the
loading process a bit faster. It's the first time I change something in an
open source program and don't know best way to "announce" it and get it
reviewed, so I send a patch in a mail.
The major speedup is caused by calling my function load_script_file instead
of script_fu_run_command("(load "). Please review my changes and send an
answer if the patch is OK.
diff -rup
/home/lukasz/OPOS/SOURCE/gimp-git-patched/gimp/plug-ins/script-fu/scheme-wrapper.c
gimp/plug-ins/script-fu/scheme-wrapper.c
---
/home/lukasz/OPOS/SOURCE/gimp-git-patched/gimp/plug-ins/script-fu/scheme-wrapper.c
2010-08-24
17:49:15.0 +0200
+++ gimp/plug-ins/script-fu/scheme-wrapper.c 2010-08-24 22:47:21.0
+0200
@@ -298,6 +298,14 @@ ts_interpret_stdin (void)
scheme_load_file (&sc, stdin);
}
+/* modified by Lukasz Czerwinski (lc277...@students.mimuw.edu.pl) */
+
+int load_script_file(const char *fname) {
+ return scheme_file_push(&sc,fname);
+}
+
+/* end of modification */
+
gint
ts_interpret_string (const gchar *expr)
{
diff -rup
/home/lukasz/OPOS/SOURCE/gimp-git-patched/gimp/plug-ins/script-fu/scheme-wrapper.h
gimp/plug-ins/script-fu/scheme-wrapper.h
---
/home/lukasz/OPOS/SOURCE/gimp-git-patched/gimp/plug-ins/script-fu/scheme-wrapper.h
2010-08-24
17:49:15.0 +0200
+++ gimp/plug-ins/script-fu/scheme-wrapper.h 2010-08-24 23:09:18.0
+0200
@@ -32,6 +32,10 @@ const gchar * ts_get_success_msg (v
void ts_interpret_stdin (void);
+/* modified by Lukasz Czerwinski (lc277...@students.mimuw.edu.pl) */
+int load_script_file(const char *fname);
+/* end of modification */
+
/* if the return value is 0, success. error otherwise. */
gint ts_interpret_string (const gchar *expr);
diff -rup
/home/lukasz/OPOS/SOURCE/gimp-git-patched/gimp/plug-ins/script-fu/script-fu-scripts.c
gimp/plug-ins/script-fu/script-fu-scripts.c
---
/home/lukasz/OPOS/SOURCE/gimp-git-patched/gimp/plug-ins/script-fu/script-fu-scripts.c
2010-08-24
17:49:15.0 +0200
+++ gimp/plug-ins/script-fu/script-fu-scripts.c 2010-08-25
16:58:31.0 +0200
@@ -589,6 +589,7 @@ script_fu_run_command (const gchar *com
return success;
}
+/* modified by Lukasz Czerwinski (lc277...@students.mimuw.edu.pl) */
static void
script_fu_load_script (const GimpDatafileData *file_data,
gpointeruser_data)
@@ -602,13 +603,15 @@ script_fu_load_script (const GimpDatafil
command = g_strdup_printf ("(load \"%s\")", escaped);
g_free (escaped);
- if (! script_fu_run_command (command, &error))
+// if (! script_fu_run_command (command, &error))
+ if (! load_script_file(file_data->filename))
{
gchar *display_name = g_filename_display_name
(file_data->filename);
gchar *message = g_strdup_printf (_("Error while loading
%s:"),
display_name);
+ g_message (message);
- g_message ("%s\n\n%s", message, error->message);
+// g_message ("%s\n\n%s", message, error->message);
g_clear_error (&error);
g_free (message);
@@ -625,6 +628,7 @@ script_fu_load_script (const GimpDatafil
g_free (command);
}
}
+/* end of modifications */
/*
* The following function is a GTraverseFunction.
diff -rup
/home/lukasz/OPOS/SOURCE/gimp-git-patched/gimp/plug-ins/script-fu/tinyscheme/scheme.c
gimp/plug-ins/script-fu/tinyscheme/scheme.c
---
/home/lukasz/OPOS/SOURCE/gimp-git-original/gimp/plug-ins/script-fu/tinyscheme/scheme.c
2010-08-24
17:49:15.0 +0200
+++ gimp/plug-ins/script-fu/tinyscheme/scheme.c 2010-08-25
17:08:44.0 +0200
@@ -125,6 +125,21 @@ static int utf8_stricmp(const char *s1,
return result;
}
+/* modified by Lukasz Czerwinski (lc277...@students.mimuw.edu.pl) */
+#define stricmp_left_converted utf8_stricmp_left_converted
+static int utf8_stricmp_left_converted(const char *case_folded, const char
*s2)
+{
+ char *t2a;
+ int result;
+
+ t2a = g_utf8_casefold(s2, -1);
+
+ result = strcmp(case_folded, t2a);
+ g_free(t2a);
+ return result;
+}
+/* end of modification */
+
#define min(a, b) ((a) <= (b) ? (a) : (b))
#if USE_STRLWR
@@ -898,15 +913,18 @@ static INLINE pointer oblist_find_by_nam
int location;
pointer x;
char *s;
+ gchar *name_case_folded = g_utf8_casefold(name, -1);
location = hash_fn(name, ivalue_unchecked(sc->oblist));
for (x = vector_elem(sc->oblist, location); x != sc->NIL; x = cdr(x)) {
s = symname(car(x));
/* case-insensitive, per R5RS section 2. */
-if(stricmp(name, s) == 0) {
+if(stricmp_left_converted(name_case_folded, s) == 0) {
+ g_free(name_case_folded);
return car(x);
}
}
+ g_free(name_case_folded);
return sc->NIL;
}
@@ -1415,6 +1433,14 @@ static void finalize_cell(scheme *sc, po
/* == Routines for Readin
Re: [Gimp-developer] Getting new layer modes fit for inclusion
On 08/30/2010 08:19 PM, Rupert Weber wrote: > On 08/24/2010 07:46 AM, Martin Nordholts wrote: > >> >> * Only show the legacy color modes when an image that already >> uses them is the active image (we either show all four, even >> if an image only uses one). >> > > Haven't got around doing that, yet, but have question. Deciding when to > activate the legacy modes is easy: Whenever an image is loaded that uses > them. > > But when to deactivate? > - As soon as there is no layer left using legacy modes? (I.e. you > couldn't switch modes back and forth. Once switched away from legacy > modes, the menu item would be gone.) > - When closing the image or switching to another image that doesn't have > legacy modes. I.e. changing the active image will change the dropdown. > - When closing the last image that uses legacy modes. I.e. you could > activate legacy modes for all images by keeping a foot-in-the-door image > open. > - Only when closing GIMP. > > While I could think of use-cases for all of them, I think it boils down > to how strongly we would want to discourage from using the legacy modes. I think you could add a gboolean was_loaded_with_obsolete_modes to GimpImage, set it when an image is loaded, and then check that boolean in gimp_layer_tree_view_set_image(). So whenever an image that was loaded with obsolete layer modes present becomes the active image, we show the obsolete modes in the menu. Slightly different from my initial solution proposal in other words. / Martin > Is it decided that GEGL will not support the legacy modes, or should > they be implemented in GEGL as well to retain backward compatability? There is one big issue left to settle: whether e.g. a Screen pixel composited onto nothing should result in the pixel or 'nothing'. Right the result is the unmodified pixel, as in the SVG 1.2 compositing model. In legacy GIMP compositing, the result is 'nothing' (except when the layer is the bottom-most layer...). I'm fine with using our legacy compositing model, as long as there exists a consistent compositing model without special cases to describe it. I will try to come up with such a compositing model unless someone else gives it a go before me. / Martin -- My GIMP Blog: http://www.chromecode.com/ "Automatic tab style and removed tab title bar" ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Getting new layer modes fit for inclusion
On Mon, 2010-08-30 at 20:25 +0200, Rupert Weber wrote: > so I've played around with babl a bit, and quite a few questions came > up. Is there a separate babl mailing list? gegl-developer is the place for discussing babl things. Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Getting new layer modes fit for inclusion
so I've played around with babl a bit, and quite a few questions came up. Is there a separate babl mailing list? Getting the conversions symmetric is possible, but at a cost. Without any other changes, increasing the bits from 16 to 20 gives perfect round-trip accuracy, but it also becomes about 4x slower; probably due to the increased size (x32) of lookup tables. So that would definitely need more work. Rupert ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Getting new layer modes fit for inclusion
On 08/24/2010 07:46 AM, Martin Nordholts wrote: > > * Only show the legacy color modes when an image that already > uses them is the active image (we either show all four, even > if an image only uses one). > Haven't got around doing that, yet, but have question. Deciding when to activate the legacy modes is easy: Whenever an image is loaded that uses them. But when to deactivate? - As soon as there is no layer left using legacy modes? (I.e. you couldn't switch modes back and forth. Once switched away from legacy modes, the menu item would be gone.) - When closing the image or switching to another image that doesn't have legacy modes. I.e. changing the active image will change the dropdown. - When closing the last image that uses legacy modes. I.e. you could activate legacy modes for all images by keeping a foot-in-the-door image open. - Only when closing GIMP. While I could think of use-cases for all of them, I think it boils down to how strongly we would want to discourage from using the legacy modes. Is it decided that GEGL will not support the legacy modes, or should they be implemented in GEGL as well to retain backward compatability? ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Wish: A better animation system inside GIMP
Hi guys, > That's not a problem since creating animations is not a defined goal in > the GIMP product vision. I rather think we should remove support for > animations in GIMP for 3.0, plug-ins can supply that functionality instead. I'm pretty aware that animations are not the goal in GIMP, however, I'm working in the past five years with GIMP to produce animations. Anyway, the thing is, I believe that the GIMP-GAP can goes forward and replace the animation filters completely. The animation filter is a great light-table tool, is pretty useful and we don't have something similar in GAP. Is not the right moment to remove or replace the animations filter, and maybe the right time to notice that the animation is a real function of GIMP and assume this as part of the product vision. Cheers -- Daniel Pinheiro Lima http://blogdooswaldo.blogspot.com/ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
