[RESOLVED] GradientFill vs GdiGradientFill (GDI32)

[Milk]

I've just noticed an undocumented (by MSDN) Api called GdiGradientFill, it appears to be the same as the documented GradientFill except according to AllApi it's W2k+ only.

Does anyone know anything about it? Does it have any advantage over GradientFill?

[LaVolpe]

Didn't realize it was there either. However, some quick googling shows that msimg32's GradientFill API simply calls gdi32's GdiGradientFill API. This appears founded looking at msimg32's decompiled GradientFill call:

Disassembly of GradientFill  (0x7638117F)
; Section: .text
;= = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = 
; EXP: GradientFill (4)
; SYM:GradientFill
0x7638117F: 8BFF                   MOV         EDI,EDI          
0x76381181: 55                     PUSH        EBP              
0x76381182: 8BEC                   MOV         EBP,ESP          
0x76381184: 5D                     POP         EBP              
0x76381185: FF2508203876           JMP         DWORD PTR [0x76382008]
' ^^ the above shows that this function simply calls another function
0x7638118B: 90                     NOP         
0x7638118C: 90                     NOP         
0x7638118D: 90                     NOP         
0x7638118E: 90                     NOP         
0x7638118F: 90                     NOP

Here's what I saw, looking at decompiled DLLs. Supports claim of Win2K+ only.
1. Win2K,XP: GdiGradientFill exists; msimg32.DLL GradientFill redirected (above)
2. WinNT4: Non-existant. msimg32 not shipped with NT4, GDI32 has no reference to GdiGradientFill
3. Win98: GdiGradientFill does not exist; msimg32.DLL GradientFill has own code; does not jump to another function
WinME? Don't know; probably same as Win98

Edited: If you want to experiment, on Win2K+, delcare as follows:

Private Declare Function GdiGradientFill Lib "gdi32" (... same parameters)

[LaVolpe]

Just FYI: WinXP's msimg32 has only 5 exported functions, 3 of which are commonly known: AlphaBlend, GradientFill & TransparentBlt. All 3 jump to GDI32, each with a Gdi prefix: GdiAlphaBlend, GdiGradientFill, GdiTransparentBlt.

So the only advantage may be calling GDI32 directly on Win2K+ vs calling msimg32 which then jumps to gdi32, a few execution lines faster in memory. However, the disadvantage, obviously, is that you'd have to have multiple API declarations: Win2K+, Win98/ME.

[Milk]

Thankyou

I've been having some problems with GradientFill causing spectacular system crashes presumably because I've passed it bad vertex coords. If GdiGradientFill was a rewrite then it just might have been a bit more idiot (moi) friendly.

[LaVolpe]

Well, have you looked at vbnet's example. Are you converting R/G/B values correctly?
http://vbnet.mvps.org/code/forms/gradientfill.htm

[Milk]

I'm pretty sure it's when I send out of range vertex coords as it works fine most of the time and the 48bit RGB values don't change where the coords do. It really is a spectacular crash; blank screen, internal speaker beep and restart making me reluctant to do too much detective work by purposefully trying to cause it.

I am using a slightly different vertex structure, but I don't think it's that. There are also around 10'000 little triangles but I don't think it's that either. The coords however are on rare occasions way out of DC bounds.

Private Type tVertex
    x As Long
    y As Long
    lRed As Byte
    hRed As Byte
    lGreen As Byte
    hGreen As Byte
    lBlue As Byte
    hBlue As Byte
    lAlpha As Byte
    hAlpha As Byte
End Type

[LaVolpe]

The structure shouldn't be an issue, both yours & the one on vbNet are 16bytes each.

Hmmm. Are you using AlphaBlend afterwards? If so, if the coords are outside of the bitmap dimensions, AlphaBlend will fail. I have seen AlphaBlend crash when not used properly. If AlphaBlend is in use, maybe rem that out for a test and see if crash persists.

But with the type of crash you are describing, the first thing I would absolutely ensure is that the amount of triangles and the pointer to to the first triangle matematically add up. In other words, if tVertex(0 to 5), and providing tVertex(3) as the pointer and saying you have 4 triangles can crash because API is looking for tVertex(3),(4),(5),(6). Spectacular crashes are usually writes to allocated system memory. I once crashed once so hard, I had to replace my Kernel32.dll; don't ask me how I did that -- I simply destroyed the project and moved on, as I was only playing around anyway.