The batch mode console is using stdio but never flushing its output
after fwrite()s. This still usually works by accident when using
batch mode from a terminal, but it means scripts generally won't work
as responses to requests never get flushed through the return pipe.
Apologies for this not
While working on my resampler, I noticed the tile cache often got
itself into near-deadlock situations when it was actually working
under moderate cache pressure. I have a series of four tile cache
performance patches following this mail; one is a simple one-liner
that removes a few integer
Patch attached [to avoid any chance of gmail mangling lines]
Detailed patch description at:
http://web.mit.edu/xiphmont/Public/gimp-fu/gimp-cache.html
Monty
0001-Minor-change-to-TILE_DATA_POINTER-that-restricts-TIL.patch
Description: Binary data
___
Patch attached [to avoid any chance of gmail mangling lines]
Detailed patch description at:
http://web.mit.edu/xiphmont/Public/gimp-fu/gimp-cache.html
Monty
0002-Add-additional-profiling-to-tile-usage-in-order-to-a.patch
Description: Binary data
___
Patch attached [to avoid any chance of gmail mangling lines]
Detailed patch description at:
http://web.mit.edu/xiphmont/Public/gimp-fu/gimp-cache.html
Monty
0003-Replace-two-list-flush-clean-first-cache-strategy-wi.patch
Description: Binary data
___
Patch attached [to avoid any chance of gmail mangling lines]
Detailed patch description at:
http://web.mit.edu/xiphmont/Public/gimp-fu/gimp-cache.html
Monty
0004-Correct-startup-flaw-in-idle-swapper-start-Don-t-wat.patch
Description: Binary data
___
patch:
On Tue, 2009-06-02 at 04:11 -0400, Christopher Montgomery wrote:
#define TILE_DATA_POINTER(tile,x,y) \
((tile)-data + \
- (((y) % TILE_HEIGHT) * (tile)-ewidth + ((x) % TILE_WIDTH)) *
(tile)-bpp)
-
+ (((y) (TILE_HEIGHT-1)) * (tile)-ewidth + ((x)
(TILE_WIDTH-1))) * (tile)-bpp
+#ifdef TILE_PROFILING
+#include sys/time.h
If we use GTimeVal instead of struct timeval, we can avoid this include
(and a possible portability problem).
Agreed.
These lines don't adhere to the coding style guidelines. Please add a
space after the if and move the opening curly bracket to
On Tue, Jun 2, 2009 at 5:01 PM, Sven Neumann s...@gimp.org wrote:
Hi,
On Tue, 2009-06-02 at 04:13 -0400, Christopher Montgomery wrote:
-#define IDLE_SWAPPER_TIMEOUT 250
-
+#define IDLE_SWAPPER_START 1000
+#define IDLE_SWAPPER_INTERVAL 20
+#define IDLE_SWAPPER_TILES_PER 10
Should
For about a month I'd turned on emacs's trailing whitespace autotrim
and it was a cure worse than the disease. How shall I kill my own
whitespace without generating patches 4x larger than necessary due to
others' trailing whitespace?
Monty
___
On Tue, Jun 2, 2009 at 10:15 PM, Christopher Montgomery
xiphm...@gmail.com wrote:
For about a month I'd turned on emacs's trailing whitespace autotrim
and it was a cure worse than the disease. How shall I kill my own
whitespace without generating patches 4x larger than necessary due to
others
(%rdi), %eax
addl%esi, %edx
imull %eax, %edx
movslq %edx,%rax
addq24(%rdi), %rax
ret
On Tue, Jun 2, 2009 at 5:09 PM, Sven Neumann s...@gimp.org wrote:
Hi,
On Tue, 2009-06-02 at 16:56 -0400, Christopher Montgomery wrote:
As far as I know pretty
On Wed, Jun 3, 2009 at 3:12 AM, Sven Neumann s...@gimp.org wrote:
There should not be any trailing whitespace in the GIMP source code. We
have several times trimmed away all trailing whitespace and committed
these cleanups. If new trailing whitespace sneaked in, then we should
probably do
Updated patches attached, including all requested coding style
changes. Unless, of course, I missed any.
Monty
0001-Minor-change-to-TILE_DATA_POINTER-that-restricts-TIL.patch
Description: Binary data
0002-Add-additional-profiling-to-tile-usage-in-order-to-a.patch
Description: Binary data
14 matches
Mail list logo
