Early WIP on v2.55

[Patrice Terrier]

You are not seeing it, because i am not doing it, but that's easy just update the Load in with the string returned by ZI_CloseSpinner.

[Michael Lobko-Lobanovsky]

Yeah, I updated my message above. Please respond to my suggestion.

[Patrice Terrier]

SetWindowText(GetDlgItem(gP.hMain, IDC_LOAD_TIME),  ZI_SpinnerClose());

    SetWindowText(GetDlgItem(gP.hMain, IDC_VERTICES), STRL(Mobj_getNumberOfVertices()));
    SetWindowText(GetDlgItem(gP.hMain, IDC_TRIANGLES), STRL(gM.numberOfTriangles));
    SetWindowText(GetDlgItem(gP.hMain, IDC_INDICES), STRL(gM.numberOfTriangles * 3));
    SetWindowText(GetDlgItem(gP.hMain, IDC_MESHES), STRL(gM.numberOfMeshes));
    SetWindowText(GetDlgItem(gP.hMain, IDC_MATERIALS), STRL(gM.numberOfMaterials));
    // MLL 10-28-2018: ============================
    WCHAR buf[64] = { 0 };
    swprintf_s(buf, strSize(buf), L"%.3f %s", FileSize(pszFilename) / 1048576.0f, L"MB");
    SetWindowText(GetDlgItem(gP.hMain, IDC_OBJ_SIZE), buf);
    killLoadTimer(); // stop model load timer
    // ============================================
    SetWindowText(GetDlgItem(gP.hMain, IDC_LOAD_TIME), ZI_SpinnerClose());

[Michael Lobko-Lobanovsky]

Yeah, the bottom-most line's placement is correct while the topmost isn't.

[Michael Lobko-Lobanovsky]

Now how do I test Spinner.h blur in the DLL? And should I use the same SKI?

[Patrice Terrier]

To test bluring in the DLL, just unREM this code section (line 14739-14740)

    //RECT rb; SetRect(&rb, x + r.left, y + r.top, x + r.left + Width(r), y + r.top + Height(r));
    //BlurTextPlus(hdc, g_SP.szTime, rb, g_SP.font, 4, nStrFormat);

[Patrice Terrier]

I have improved the ZI_SpinnerInit parameters.

Now it can use a specific private font of any size and color (with the new GDImage function zUsePrivateFont).

Example:
    Path_Combine(gP.mt.FullName, skSkinFolder(), L"lcd.ttf");
    ZI_SpinnerInit(gP.hGL, szFile, 0, zUsePrivateFont(gP.mt.FullName, 22), ZD_ARGB(255, 0,255,0));

Perhaps i should switch the layered window to a DWM composited to see if the DLL blur problem goes away 
(like in my DwmSpinner demo)

[Michael Lobko-Lobanovsky]

Patrice,

1. Sorry for not responding; I got an unexpected visit by my son.

2. When talking about blur flicker in the DLL, do you mean that dark topmost scanline that appears running randomly along the top edge of the quark frame window?

3. If yes then I'd say the pictures are looking quite differently in Spinner.h and the DLL. The .DLL blur looks much darker (and better at that!) than the .H blur (which is too thin IMHO), as if i) blur algos are different, or ii) alpha premultiplication algos are different, or iii) sizes or scale of the spinner quark texture are different so that an extra scan line is rendered by the DLL compared to the .H file. Or something else of such geometric kind, rather than DWM compositing or thread priority which would affect the entire spinner display rather than its border scan line only...

Generally I like the .DLL version more than the .H one except for the offending scan line.

4. The green digital font looks very nice and a perfect match to the one used in the alpha threshold display. I'd rather we use that one instead of the cheaper looking white font... Any similar blur problems with the green digital font in the DLL spinner?

[Patrice Terrier]

2. When talking about blur flicker in the DLL, do you mean that dark topmost scanline that appears running randomly along the top edge of the quark frame window?

YES

Added:
Here is how it looks with a text size of 30

Shall send you pandora with the latest spinner change tomorrow morning...

[Michael Lobko-Lobanovsky]

To test bluring in the DLL, just unREM this code section (line 14739-14740)

    //RECT rb; SetRect(&rb, x + r.left, y + r.top, x + r.left + Width(r), y + r.top + Height(r));
    //BlurTextPlus(hdc, g_SP.szTime, rb, g_SP.font, 4, nStrFormat);

This recommendation was obviously incomplete. In fact I asked how I could switch between seeing an include spinner (I falsely assumed I was seeing it on default) and a DLL spinner.

Having got your patches and seeing Spinner.h included in the project, I thought the patches were set to use it. But in fact the calls were set to the library functions and I wasn't ever seeing how the spinner behaved in the include file. All I was seeing so far was just blur or no blur in the library spinner. It was my bad, I'm sorry to admit it, but I think next time I receive a patch I'd be grateful to be told what the patch's initial state is -- just in order to avoid losing my precious lifetime decoding it myself.

Now I can see blur in both include file and spinner and yes, its quality is identical and there's just that offending noisy scan line in the DLL that seems very much like a geometrical (spinner frame size?) issue...

Let's do the tests tomorrow. Seems like I'm too tired tonight if I overlooked such a trivial thing as finding out exactly what it was that I was looking at but not seeing.

Zzzzzz...

[Michael Lobko-Lobanovsky]

If you goto line 14707 in void RenderAnimation() and change this funny if/else-condition as follows:

............
if (g_SP.ishorizontal) {
    GdipDrawImageRectRectI(graphics, g_SP.img, 0, -2, g_SP.imgH, g_SP.imgH, g_SP.imgH * g_SP.frametouse - g_SP.imgH, 0, g_SP.imgH, g_SP.imgH, 2, 0, NULL, NULL); // MLL: brush misalignment?
} else {
    GdipDrawImageRectRectI(graphics, g_SP.img, 0, 0, g_SP.imgW, g_SP.imgW, g_SP.imgW * g_SP.frametouse - g_SP.imgW, 0, g_SP.imgW, g_SP.imgW, 2, 0, NULL, NULL);
}
............

you'll see no scan line flicker in the DLL spinner any more.

So this is a geometrical issue and most probably, its random nature is related to brush misalignment at some stage of GDI+ image creation process. There's a lot of work going on directly in memory rather than in a specific DC canvas, and such manipulations are sensitive to proper brush alignment with calls to SetBrushOrgEx() when the canvases and brushes in question are not managed directly by Windows itself (i.e. do not belong to the OS stock objects). Especially when world transforms are in progress, and image scaling inherent in GdipDrawImageRectRectI() is one of such transforms.

This solution is definitely a crutch but as long as it works, it is just as good as any other one.

[Patrice Terrier]

Mike

Thank you for the crutch solution, i will try it and see how it works by me.

About the use of a layered window for the spinner, this was a survival of the XP's days, before Vista and the great DWM addition.

Nowdays i would have used compositing, just like what i did for the OR overlay, or for my C++ DwmSpinner project (I could  use it to solve definitly the problem, and get rid of the old layered stuff).

[Patrice Terrier]

Here is the latest pandora, altogether with the OR.zip i have been using for test purpose.

There is no more line flicker in the DLL, thank you!

What about the LCD digit size, is it good for you?
 
Do you know of a good free antimalware for Android?

[Patrice Terrier]

You know what, if we use another FONT than the lcd.ttf, then the flicker is back again 

I shall definitly give a go to the DwmSpinner version, to see if there is the same problem.

[Michael Lobko-Lobanovsky]

Here is the latest pandora, altogether with the OR.zip i have been using for test purpose.

Thank you, DL'ed OK and deleted!

There is no more line flicker in the DLL, thank you!

Excellent!

What about the LCD digit size, is it good for you?

What if we make it exactly the size that's used in the alpha threshold display? The earlier screenie gave me an impression it was a little larger than that obscuring too much of quark...
 

Do you know of a good free antimalware for Android?

Sorry Patrice, I've got absolutely no experience with Android except using my smartphone on rare occasions when I'm away from my workstation and optical land line web connection. It is my good old classic Nokia 3310 that I'm using on a regular basis instead.

I'm sorta squeamish towards slack-baked modern gimmicks and for me, there's nothing better than a well-packed desktop PC.

You know what, if we use another FONT than the lcd.ttf, then the flicker is back again 

For me, it's OK with the font you used before lcd.ttf. (see below)

I haven't yet tried lcd.ttf because I was busy typing this response...

Re. DWM, please don't rush if it needs much effort. Let me see first what's going on with the fonts under my Win 7 and 10...