Author Topic: Early WIP on v2.55  (Read 10459 times)

Michael Lobko-Lobanovsky

  • Administrator
  • *****
  • Posts: 1094
Re: Early WIP on v2.55 :: AHTUNG!!!
« Reply #30 on: October 29, 2018, 09:42:03 pm »
... the obj model altogether with the faulty mtl file, and i shall fix it.

The MTL file is not faulty, and it needs not any fixing. Rather it is the hotfixed OR that's faulty and in need of more work to be able to display the model properly with the existing MAT file. ;)

Thanks!
Mike
(3.6GHz Intel Core i5 Quad w/ 16GB RAM, nVidia GTX 1060Ti w/ 6GB VRAM, Windows 7 Ultimate Sp1)

Patrice Terrier

  • Administrator
  • *****
  • Posts: 1261
    • zapsolution
Re: Early WIP on v2.55
« Reply #31 on: October 29, 2018, 10:02:46 pm »
Matching slash and anti_slash is a very bad practice, but i will take care of it, no problem, this is easy to solve.

Will do it tomorrow morning, first thing  8)
Patrice
(Always working with the latest Windows version available...)

Michael Lobko-Lobanovsky

  • Administrator
  • *****
  • Posts: 1094
Re: Early WIP on v2.55
« Reply #32 on: October 30, 2018, 12:27:22 am »
The model and its textures import flawlessly with the current MAT file into all 3D editors and viewers I have, including 3ds Max. If anything's wrong with at least one index, 3ds Max always aborts import and throws an error message. I'm inclined to believe it more than the debugger.
Mike
(3.6GHz Intel Core i5 Quad w/ 16GB RAM, nVidia GTX 1060Ti w/ 6GB VRAM, Windows 7 Ultimate Sp1)

Patrice Terrier

  • Administrator
  • *****
  • Posts: 1261
    • zapsolution
Re: Early WIP on v2.55
« Reply #33 on: October 30, 2018, 01:38:48 am »
Here is the new Tools.h to fix the relative path problem, and remove the duplicated slash.

See the new function replaceA, and the changes done into Path_CombineA

Warning for dynamic memory allocation, replaceA uses malloc, thus don't forget to use free once done.
« Last Edit: October 30, 2018, 01:41:34 am by Patrice Terrier »
Patrice
(Always working with the latest Windows version available...)

Michael Lobko-Lobanovsky

  • Administrator
  • *****
  • Posts: 1094
Re: Early WIP on v2.55
« Reply #34 on: October 30, 2018, 01:06:22 pm »
Hi Patrice,

The fixes seem to work fine for me, thank you! :)

BTW I cannot compile my VS 2013 solution in the Debug mode; I'm getting three linker errors:

error LNK2001: unresolved external symbol __imp_DwmGetCompositionTimingInfo   Main.obj   ObjReader64
error LNK2001: unresolved external symbol __imp_timeBeginPeriod               Main.obj   ObjReader64
error LNK2001: unresolved external symbol __imp_timeEndPeriod                 Main.obj   ObjReader64

Does that mean I'm missing some WinAPI debug mode library(-ies) or #pragma lib(-s), do you think?
Mike
(3.6GHz Intel Core i5 Quad w/ 16GB RAM, nVidia GTX 1060Ti w/ 6GB VRAM, Windows 7 Ultimate Sp1)

Patrice Terrier

  • Administrator
  • *****
  • Posts: 1261
    • zapsolution
Re: Early WIP on v2.55
« Reply #35 on: October 30, 2018, 01:34:08 pm »
Put this in the debug Property Pages
Linker -> Input section

Additional Dependencies
Winmm.lib;Dwmapi.lib;pdh.lib;UxTheme.lib;Comctl32.lib;Glu32.lib;Shlwapi.lib;opengl32.lib;kernel32.lib;user32.lib;gdi32.lib;%(AdditionalDependencies)
Patrice
(Always working with the latest Windows version available...)

Patrice Terrier

  • Administrator
  • *****
  • Posts: 1261
    • zapsolution
Re: Early WIP on v2.55
« Reply #36 on: October 30, 2018, 01:41:47 pm »
Small fix to change into replaceA

    // Making new string of enough length
    long nLen = (K + cnt * (newlen - oldlen) + 1) * 2;

shoul be

    // Making new string of enough length
    long nLen = (K + cnt * (newlen - oldlen) + 1); // * 2; we are using char here rather than WCHAR
Patrice
(Always working with the latest Windows version available...)

Michael Lobko-Lobanovsky

  • Administrator
  • *****
  • Posts: 1094
Re: Early WIP on v2.55
« Reply #37 on: October 30, 2018, 02:43:51 pm »
Put this in the debug Property Pages

That did the trick, thanks! :) (how could I overlook such an obvious thing? :o)

Small fix to change into replaceA

Done!
Mike
(3.6GHz Intel Core i5 Quad w/ 16GB RAM, nVidia GTX 1060Ti w/ 6GB VRAM, Windows 7 Ultimate Sp1)

Michael Lobko-Lobanovsky

  • Administrator
  • *****
  • Posts: 1094
Re: Early WIP on v2.55 :: !!! AHTUNG, Part II !!!
« Reply #38 on: October 31, 2018, 07:05:42 am »
Patrice,

I'm sorry to say but I have every reason to believe that your

!!! ZI_SPINNER LEAKS GDI OBJECTS !!!

at a rate of 8 handles each time it pops up and down at model load time under my Win 7.

Will you please fix that leak in your GDImage?

(Please don't ask me for proof; I'm pretty good at isolating and fixing the source of GDI memory leaks. I am 100% sure the problem exists under your Win 10 as well though the exact number of handles may differ.)
Mike
(3.6GHz Intel Core i5 Quad w/ 16GB RAM, nVidia GTX 1060Ti w/ 6GB VRAM, Windows 7 Ultimate Sp1)

Patrice Terrier

  • Administrator
  • *****
  • Posts: 1261
    • zapsolution
Re: Early WIP on v2.55
« Reply #39 on: October 31, 2018, 09:51:53 am »
May i send you a spinner.h to use with OR (in debug mode), as i have no way to check it with Seven  :-[

Note: I am using the undocumented API RtlDecompressBuffer, but i could use my proprietary png animation rather than a .ski file, or even just a simple .png
« Last Edit: October 31, 2018, 09:59:10 am by Patrice Terrier »
Patrice
(Always working with the latest Windows version available...)

Michael Lobko-Lobanovsky

  • Administrator
  • *****
  • Posts: 1094
Re: Early WIP on v2.55 :: !!! AHTUNG, Part II !!!
« Reply #40 on: October 31, 2018, 10:13:46 am »
Of course you may, my friend.

Re. your RtlDecompressBuffer, I know. It's in the import table of all the spinners you've ever used. ;) Remember I re-implemented your spinner in multi-threaded OOP FBSL in my Objector? :)

But no, RtlDecompressBuffer has no relation to GDI objects. I'm sure the problem is seen also under your Win 10. I can check it here too but I just was too lazy to switch on my own Win 10 box.
Mike
(3.6GHz Intel Core i5 Quad w/ 16GB RAM, nVidia GTX 1060Ti w/ 6GB VRAM, Windows 7 Ultimate Sp1)

Patrice Terrier

  • Administrator
  • *****
  • Posts: 1261
    • zapsolution
Re: Early WIP on v2.55
« Reply #41 on: October 31, 2018, 10:32:53 am »
As far as i can say i couldn't see anything wrong both DeleteObject and GdipDisposeImage are being called.

But because 4 eyes are better than two, here is the Spinner.h to check in debug mode with OR, just add the include at the top of Main.cpp, and replace all call to ZI_Spinner* with OR_Spinner.

I have some urgent home work to do, but i will check again later on.
Patrice
(Always working with the latest Windows version available...)

Michael Lobko-Lobanovsky

  • Administrator
  • *****
  • Posts: 1094
Re: Early WIP on v2.55 :: !!! AHTUNG, Part II !!!
« Reply #42 on: October 31, 2018, 10:35:02 am »
OK thanks and take your time! :)
Mike
(3.6GHz Intel Core i5 Quad w/ 16GB RAM, nVidia GTX 1060Ti w/ 6GB VRAM, Windows 7 Ultimate Sp1)

Patrice Terrier

  • Administrator
  • *****
  • Posts: 1261
    • zapsolution
Re: Early WIP on v2.55
« Reply #43 on: October 31, 2018, 12:56:24 pm »
I did check in Debug mode, using _CrtDumpMemoryLeaks();

it does detect memory leaks  :-[
but not in the spinner function.

I shall have to investigate more…
seems there is one in Tools.h when using PARSE and AllocTmpStr(lstrlen(sMain), 1, 1);
uing calloc (this function was given to me by James, but i never checked it thoroughly)
« Last Edit: October 31, 2018, 02:32:52 pm by Patrice Terrier »
Patrice
(Always working with the latest Windows version available...)

Michael Lobko-Lobanovsky

  • Administrator
  • *****
  • Posts: 1094
Re: Early WIP on v2.55 :: !!! AHTUNG, Part II !!!
« Reply #44 on: October 31, 2018, 04:45:57 pm »
Patrice,

I am talking not about conventional memory leaks but rather about GDI object leaks like HDC, HPEN, HBRUSH, HBITMAP, etc. handles. Those that you create then select/deselect and then delete or release. These are leaking (i.e. are created but not destroyed, or fail to be destroyed, after use) at a rate of 8 handles per spinner popup. ???

You should examine it not in the debug mode but rather in your Task Manager if you inspect its GDI Objects table column.

Such a leak is usually observed when one attempts to delete the objects that are currently selected in a DC, or DCs with non-native GDI objects created by the user and selected into them. All such deletions fail silently, which results in the app's GDI object count growing rapidly as more and more models are reloaded into the app throughout the same session.

When the ZI_Spinner calls are commented out, my OR GDI object count is absolutely steady at 141/143 GDI handles throughout the entire session. I'm seeing this issue with the ZI_Spinner both precompiled into GDImage and as a standalone include you sent me.

This gives me a reason to believe that the cause of leakage lies in an improper use of GDI handles in the ZI_Spinner source code.

[UPD]  I was lucky to reduce the leakage to 6 handles per popup. So far so good...
« Last Edit: October 31, 2018, 05:31:21 pm by Michael Lobko-Lobanovsky »
Mike
(3.6GHz Intel Core i5 Quad w/ 16GB RAM, nVidia GTX 1060Ti w/ 6GB VRAM, Windows 7 Ultimate Sp1)