> 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 stack trace to... seems it was an alternate thread(maybe GC?). I did a sampling profile and got this:

Function Name	Inclusive  Exclusive Inclusive % Exclusive %
_DispatchMessageW@4	10,361	5	88.32	0.04
[nvoglv32.dll]   	7,874	745	67.12	6.35
_GetExitCodeThread@8	5,745	5,745	48.97	48.97
_SwitchToThread@0	2,166	2,166	18.46	18.46

So possibly it is simply my system and graphics card. For some reason NVidia might be using a lot of cpu here for no apparent reason?

DispatchMessage is still taking quite a bit of that though?


Seems like someone else has a similar issue:

https://devtalk.nvidia.com/default/topic/832506/opengl/nvoglv32-consuming-a-ton-of-cpu/


https://github.com/mpv-player/mpv/issues/152


BTW, trying sleep in the MSG loop

Error: undefined identifier 'sleep', did you mean function 'Sleep'?		

"import core.thread; sleep(10);"

;)

Adding a Sleep(10); to the loop dropped the cpu usage down to 0-1% cpu!

http://stackoverflow.com/questions/33948837/win32-application-with-high-cpu-usage/33948865

Not sure if that's the best approach though but it does work.

They mention to use PeekMessage and I don't see you doing that, not sure if it would change things though?

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 to to!wstring(title).dup simply to have the same title and classname.
>
>> [...]
>
> I have the opposite on memory but not a big deal.
>
>
>> [...]
>
> I will investigate this soon and report back anything. It probably is something straightforward.
>
>> [...]
>
> I found this on non-power of 2 textures:
>
> https://www.opengl.org/wiki/NPOT_Texture
>
>
> https://www.opengl.org/registry/specs/ARB/texture_non_power_of_two.txt
>
> It seems like it's probably a quick and easy add on and you already have the padding code, it could easily be optional(set a flag or pass a bool or whatever).
>
> it could definitely same some serious memory for large textures.
>
> e.g., a 3000x3000x4 texture takes about 36MB or 2^25.1 bytes. Since this has to be rounded up to 2^26 = 67MB, we almost have doubled the amount of wasted space.
>
> Hence, allowing for non-power of two would probably reduce the memory footprint of my code to near 50MB(around 40MB being the minimum using uncompressed textures).
>
> I might try to get a working version of that at some point. Going to deal with the cpu thing now though.
>
> Thanks again.

Never mind about this. I wasn't keeping in mind that these textures are ultimately going to end up in the video card memory.

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?

If this is the case, then maybe there is one odd temporary still hanging around in png?

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 with target machine type 'X86'
>>
>> not sure what that means with gzlib.c.ojb. Must be another bug in ldc alpha ;/
>
> It looks like you're trying to link 32-bit objects to a 64-bit Phobos.
> The only pre-built LDC for Windows capable of linking both 32-bit and 64-bit code is the multilib CI release, see https://github.com/ldc-developers/ldc/releases/tag/LDC-Win64-master.


Yes, it looks that way but it's not the case I believe(I did check when this error first came up). I'm using the phobo's libs from ldc that are x86.

I could be mistaken but

phobos2-ldc.lib(gzlib.c.obj)

suggests that the problem isn't with the entire phobos lib but gzlib.c.obj and that that is the only one marked incorrectly, since it's not for all the other imports, it seems something got marked wrong in that specific case?

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 this is the case, then maybe there is one odd temporary still hanging around in png?

Could be, though the png itself has relatively small overhead, and the opengl texture adds to it still. I'm not sure if video memory is counted by task manager or not... but it could be loading up the whole ogl driver that accounts for some of it. I don't know.

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 guess?
>
> right, the new code free() them right at scope exit.
>
>> If this is the case, then maybe there is one odd temporary still hanging around in png?
>
> Could be, though the png itself has relatively small overhead, and the opengl texture adds to it still. I'm not sure if video memory is counted by task manager or not... but it could be loading up the whole ogl driver that accounts for some of it. I don't know.

Ok. Also, maybe the GC hasn't freed some of those temporaries yet. What's strange is that when the app is run, it seems to do a lot of small allocations around 64kB or something for about 10 seconds(I watch the memory increase in TM) then it stabilizes. Not a big deal, just seems a big weird(maybe some type of lazy allocations going on)


Anyways, I'm much happier now ;) Thanks!

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 PeekMessage and I don't see you doing that, not sure if it would change things though?

I am using MsgWaitForMultipleObjectsEx which blocks until something happens. That something can be a timer, input event, other message, or an I/O thing... it doesn't eat CPU unless *something* is happening.

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. Since collections are expensive, it puts them off as long as it can and tries to do them as infrequently as reasonable. (some GCs do smaller collections to spread the cost out though, so the details always differ based on implementation)

So, you'd normally see it go up to some threshold then stabilize there, even if it is doing a lot of little garbage allocations.

However, once the initialization is done here, it shouldn't be allocating any more. The event loop itself doesn't when all is running normally.

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` is a static member of the Thread class.
>
>
>> They mention to use PeekMessage and I don't see you doing that, not sure if it would change things though?
>
> I am using MsgWaitForMultipleObjectsEx which blocks until something happens. That something can be a timer, input event, other message, or an I/O thing... it doesn't eat CPU unless *something* is happening.

Yeah, I don't know what though. Adding Sleep(5); reduces it's consumption to 0% so it is probably just spinning. It might be the nvidia issue that creates some weird messages to the app.

I'm not too concerned about it as it's now done to 0, it is minimal wait time for my app(maybe not acceptable for performance apps but ok for mine... at least for now).

As I continue to work on it, I might stumble on the problem or it might disappear spontaneously.

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 the problem stems, it would be nice to have more info why instead of a range violation. previousLine is null in the break.

All the png's generated are loadable by external app like ifranview, so they are not completely corrupt but possibly could have some thing that is screwing png.d up.


The code where the error happens is:

		case 3:
			auto arr = data.dup;
			foreach(i; 0 .. arr.length) {
				auto prev = i < bpp ? 0 : arr[i - bpp];
				arr[i] += cast(ubyte)
					/*std.math.floor*/( cast(int) (prev + previousLine[i]) / 2);
			}

Range violation at png.d(1815)

Any ideas?

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 others have this problem.

If I reduce the image dimensions it doesn't have this problem. My guess is that there is probably a bug with a > vs >= or something. When the image dimensions are "just right" an extra line is added that may be non-zero.

The image dimensions are 124x123.

This is all speculation but it seems like it is a png.d or opengltexture issue. I cannot see this added line in any image editor I've tried(PS, ifranview) and changing the dimensions of the image fix it.

Since it's a hard one to debug without test case I will work on it... Hoping you have some possible points of attack though.