[Gimp-developer] [PATCH] OpenRaster: optimize PNG saving
From 0e41e65f31ae07c91f2ed5dc8f0c51d05949be51 Mon Sep 17 00:00:00 2001 From: Jon Nordby jono...@gmail.com Date: Sat, 27 Feb 2010 14:28:58 +0100 Subject: [PATCH] OpenRaster: optimize PNG saving Sets lower compression and disables interlacing. On a 5 layer image of 4500x6000px this gives an order of magnitude better save-times, with 50% increase in file size. --- plug-ins/pygimp/plug-ins/file-openraster.py | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/plug-ins/pygimp/plug-ins/file-openraster.py b/plug-ins/pygimp/plug-ins/file-openraster.py index 2016c2b..eeefe13 100755 --- a/plug-ins/pygimp/plug-ins/file-openraster.py +++ b/plug-ins/pygimp/plug-ins/file-openraster.py @@ -85,7 +85,7 @@ def save_ora(img, drawable, filename, raw_filename): def store_layer(img, drawable, path): tmp = os.path.join(tempdir, 'tmp.png') - pdb['file-png-save-defaults'](img, drawable, tmp, 'tmp.png') + pdb['file-png-save'](img, drawable, tmp, 'tmp.png', 0, 2, 1, 1, 1, 1, 1) orafile.write(tmp, path) os.remove(tmp) -- 1.7.0 -- Regards Jon Nordby - www.jonnor.com 0001-OpenRaster-optimize-PNG-saving.patch Description: Binary data ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] enhancement: warnings instead of fatal error for duplicate calls to gimp_env_init
This is an enhancement request. Repeated calls to gimp_env_init should yield warnings and not fatal errors. It has benefits for gimp plugins written in Python. Currently gimp_env_init() calls g_error (fatal) if called a second time. Instead, pygimp_main(), which calls gimp_env_init(), should check whether this is a repeated call and issue a warning then return an error. (I'm not sure if any changes are needed for ScriptFu, whether Pygimp should check the return from gimp_main and raise a warning exception, etc.) Currently, you can't import a plugin from another plugin unless the imported plugin guards the call to main() to prevent it from being called unless this is a top level invocation: if __name__=='__main__': main() It could be sufficient to have a convention for plugins to guard the call to main(), but the convention is not usually followed. Or you could have a convention that any shared code needs to be in a separate module from the top plugin module, but again, that convention is not often followed. If you could import a plugin from within a Gimp plugin, then you could share more code. You could use classes etc. from imported plugins. You could also invoke the imported plugin's top function without invoking it as a registered PDB procedure. Neither reason is compelling. I am not that familiar with the gimp source. I am guessing that gimp_main() can't be called twice to avoid redundant io channels, and that gimp_env_init() is doing the guarding. But does it need to be fatal, is there any real harm done if they return a warning to the caller? Apparently not. I built a version of gimp in which gimp_main returned a warning on second invocations. It didn't seem to hurt gimp. Context: I was exploring whether you could use pydoc to document plugins. I tried to invoke the python pydoc module on a plugin from within another plugin, an 'inspector' plugin. Pydoc imports a module and introspectively documents it using the python inspect module. It fails to import (fatal error: gimp_env_init must only be called once) unless the call to main() is guarded. This enhancement fixes that problem. (You can't typically invoke pydoc as a command from the shell on a plugin because the shell environment typically does not include the path to the gimpfu module.) Documentation produced by pydoc might be of marginal use, and then only to programmers, and sometimes only if the plugin writer has provided docstrings, self documentation in the code. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Painting with xinput device strange behavior
I checked wacom driver and can't found anything noticable. Both wacom and my driver set motion buffer size 0. I noticed that the strange behavior happens with relative high cpu load. Sam 於 2010年02月26日 16:08, Alexia Death 提到: On Fri, Feb 26, 2010 at 9:09 AM, Sam Linitrs@gmail.com wrote: Hi Alexia, I don't know much about the history buffer filling. Would you please share some doc on how to fill it in driver ? Im not a diver developr so I dont have the information you need... You can take look at how wacom does it. Las I checked they did it right. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
