On Tuesday, 16 August 2016 at 16:40:30 UTC, Adam D. Ruppe wrote:
On Tuesday, 16 August 2016 at 16:29:18 UTC, Guillaume Piolat
wrote:
Hey, I also stumbled upon this with imageformats decoding PNG.
Image loading makes 10x the garbage it should.
Let's see what this threads unveils...
leet me
On Tuesday, 16 August 2016 at 16:40:30 UTC, Adam D. Ruppe wrote:
On Tuesday, 16 August 2016 at 16:29:18 UTC, Guillaume Piolat
wrote:
Hey, I also stumbled upon this with imageformats decoding PNG.
Image loading makes 10x the garbage it should.
Let's see what this threads unveils...
leet me
On Tuesday, 16 August 2016 at 16:29:18 UTC, Guillaume Piolat
wrote:
Hey, I also stumbled upon this with imageformats decoding PNG.
Image loading makes 10x the garbage it should.
Let's see what this threads unveils...
leet me know how it is now
On Friday, 17 June 2016 at 02:55:43 UTC, thedeemon wrote:
On Friday, 17 June 2016 at 01:51:41 UTC, Joerg Joergonson wrote:
Hi, so, do you have any idea why when I load an image with
png.d it takes a ton of memory?
I've bumped into this previously. It allocates a lot of
temporary arrays for
Also, for some reason one image has a weird horizontal line at
the bottom of the image that is not part of the original. This is
as if the height was 1 pixel to much and it's reading "junk". I
have basically a few duplicate images that were generated from
the same base image. None of the
On Saturday, 18 June 2016 at 02:17:01 UTC, Adam D. Ruppe wrote:
I have an auto generator for pngs and 99% of the time it works,
but every once in a while I get an error when loading the png's.
Usually re-running the generator "fixes the problem" so it might
be on my end. Regardless of where
On Saturday, 18 June 2016 at 02:01:29 UTC, Adam D. Ruppe wrote:
On Saturday, 18 June 2016 at 01:20:16 UTC, Joerg Joergonson
wrote:
Error: undefined identifier 'sleep', did you mean function
'Sleep'?
"import core.thread; sleep(10);"
It is `Thread.sleep(10.msecs)` or whatever time - `sleep`
On Saturday, 18 June 2016 at 01:57:49 UTC, Joerg Joergonson wrote:
Ok. Also, maybe the GC hasn't freed some of those temporaries
yet.
The way GC works in general is it allows allocations to just
continue until it considers itself under memory pressure. Then,
it tries to do a collection.
On Saturday, 18 June 2016 at 01:20:16 UTC, Joerg Joergonson wrote:
Error: undefined identifier 'sleep', did you mean function
'Sleep'?
"import core.thread; sleep(10);"
It is `Thread.sleep(10.msecs)` or whatever time - `sleep` is a
static member of the Thread class.
They mention to use
On Saturday, 18 June 2016 at 01:46:32 UTC, Adam D. Ruppe wrote:
On Saturday, 18 June 2016 at 01:44:28 UTC, Joerg Joergonson
wrote:
I simply removed your nextpowerof2 code(so the width and
height wasn't being enlarged) and saw no memory change).
Obviously because they are temporary buffers, I
On Saturday, 18 June 2016 at 01:44:28 UTC, Joerg Joergonson wrote:
I simply removed your nextpowerof2 code(so the width and height
wasn't being enlarged) and saw no memory change). Obviously
because they are temporary buffers, I guess?
right, the new code free() them right at scope exit.
If
On Friday, 17 June 2016 at 14:39:32 UTC, kinke wrote:
On Friday, 17 June 2016 at 04:54:27 UTC, Joerg Joergonson wrote:
LDC x64 uses about 250MB and 13% cpu.
I couldn't check on x86 because of the error
phobos2-ldc.lib(gzlib.c.obj) : fatal error LNK1112: module
machine type 'x64' conflicts
On Saturday, 18 June 2016 at 00:56:57 UTC, Joerg Joergonson wrote:
On Friday, 17 June 2016 at 14:48:22 UTC, Adam D. Ruppe wrote:
[...]
Yes, same here! Great! It runs around 122MB in x86 and 107MB
x64. Much better!
[...]
Yeah, strange but good catch! It now works in x64! I modified
it
The CPU usage is consistently very low on my computer. I still
don't know what could be causing it for you, but maybe it is
the temporary garbage... let us know if the new patches make a
difference there.
Ok, I tried the breaking at random method and I always ended up
in system code and no
On Friday, 17 June 2016 at 14:48:22 UTC, Adam D. Ruppe wrote:
On Friday, 17 June 2016 at 04:54:27 UTC, Joerg Joergonson wrote:
ok, then it's somewhere in TrueColorImage or the loading of
the png.
So, opengltexture actually does reallocate if the size isn't
right for the texture... and your
On Friday, 17 June 2016 at 14:48:22 UTC, Adam D. Ruppe wrote:
On Friday, 17 June 2016 at 04:54:27 UTC, Joerg Joergonson wrote:
[...]
So, opengltexture actually does reallocate if the size isn't
right for the texture... and your image was one of those sizes.
[...]
Cool, I'll check all
On Friday, 17 June 2016 at 04:54:27 UTC, Joerg Joergonson wrote:
ok, then it's somewhere in TrueColorImage or the loading of the
png.
So, opengltexture actually does reallocate if the size isn't
right for the texture... and your image was one of those sizes.
The texture pixel size needs to
On Friday, 17 June 2016 at 04:54:27 UTC, Joerg Joergonson wrote:
LDC x64 uses about 250MB and 13% cpu.
I couldn't check on x86 because of the error
phobos2-ldc.lib(gzlib.c.obj) : fatal error LNK1112: module
machine type 'x64' conflicts with target machine type 'X86'
not sure what that means
On Friday, 17 June 2016 at 03:41:02 UTC, Adam D. Ruppe wrote:
It actually has been on my todo list for a while to change the
decoder to generate less garbage. I have had trouble in the
past with temporary arrays being pinned by false pointers and
the memory use ballooning from that, and the
On Friday, 17 June 2016 at 04:32:02 UTC, Adam D. Ruppe wrote:
On Friday, 17 June 2016 at 01:51:41 UTC, Joerg Joergonson wrote:
Are you keeping multiple buffers of the image around? A
trueimage, a memoryimage, an opengl texture
MemoryImage and TrueImage are the same thing, memory is just
the
On Friday, 17 June 2016 at 01:51:41 UTC, Joerg Joergonson wrote:
Are you keeping multiple buffers of the image around? A
trueimage, a memoryimage, an opengl texture
MemoryImage and TrueImage are the same thing, memory is just the
interface, true image is the implementation.
OpenGL texture
On Friday, 17 June 2016 at 02:55:43 UTC, thedeemon wrote:
I've bumped into this previously. It allocates a lot of
temporary arrays for decoded chunks of data, and I managed to
reduce those allocations a bit, here's the version I used:
If you can PR any of it to me, I'll merge.
It actually
On Friday, 17 June 2016 at 01:51:41 UTC, Joerg Joergonson wrote:
Hi, so, do you have any idea why when I load an image with
png.d it takes a ton of memory?
I've bumped into this previously. It allocates a lot of temporary
arrays for decoded chunks of data, and I managed to reduce those
Hi, so, do you have any idea why when I load an image with png.d
it takes a ton of memory?
I have a 3360x2100 that should take around 26mb of memory
uncompressed and a bunch of other smaller png files.
Are you keeping multiple buffers of the image around? A
trueimage, a memoryimage, an
24 matches
Mail list logo
