Anders Melander

MyCmd isn't initialized so that's probably the cause of the AV. You need to create an instance of TADOCommand or reference an existing instance. Get rid of the local var declaration if you meant to be using the TADOCommand with the same name on the form Apart from that you haven't told us where in your code the problem occurs.

Not being a native English speaker I just looked up what "deprecated" actually means and it turns out that it's just what you describe: Discouragement of use. My bad.

In practice we can see that MS have not updated MDI for a very long time. The window chrome for MDI child windows does not match the latest style. Yes I'm aware that it's not recommended and of the limitations. My point was that claiming that it's deprecated is just FUD aimed at driving developers towards alternatives such as SDI. Ironically my experience with replacing MDI with SDI is that the users often find SDI confusing. They feel safe with MDI because they know where their windows are - they're always inside the MDI parent. I've tried with docked windows as a middle ground but that is far too advanced for some users.

Deprecated by whom? I don't think I've ever seen that claim backed by a first hand source. I think it's a bit like the claim that circulated about Win32 being deprecated which surfaced when .NET was released. Or about GDI when GDI+ was released.

Yes it looks nice but the rules that are used by different versions of Windows to determine what DPI awareness and scaling to apply are much more complicated than what that table suggest. Trying to make a UI for editing the manifest has become a game of whac-a-mole.

Works for me too (in projects of any size).

There's this old one, as I'm sure you know: https://github.com/andremussche/map2dbg/tree/master/tds2pdb I think I tried it once, for use with VTune, without success.

How is that relevant to the topic?

The ones you found probably does something like this, so I guess that's oldish too : // ----------------------------------------------------------------------------- // // RunningAsAdmin // // ----------------------------------------------------------------------------- // Detect if we're running at an elevated security level. // ----------------------------------------------------------------------------- function RunningAsAdmin: boolean; var hToken, hProcess: THandle; pTokenInformation: pointer; ReturnLength: DWord; TokenInformation: TTokenElevation; begin Result := False; hProcess := GetCurrentProcess; try if OpenProcessToken(hProcess, TOKEN_QUERY, hToken) then try FillChar(TokenInformation, SizeOf(TokenInformation), 0); pTokenInformation := @TokenInformation; GetTokenInformation(hToken, TokenElevation, pTokenInformation, SizeOf(TokenInformation), ReturnLength); Result := (TokenInformation.TokenIsElevated <> 0); finally CloseHandle(hToken); end; except // Ignore error - although none of the above should throw an exception... end; end;

Yes, we know the macro function only works in the editor. Now you know too.

Yes they did. And some made significant contributions with bugs that can not be fixed because no one understand the code, it's poorly documented (if at all) and it's using undocumented algorithms. Maybe that's acceptable in some projects but if I'm to maintain the code then it's not. It doesn't matter how brilliant the code is if it can't be maintained. Code like that is poison to a library. There are many things that Graphics32 would benefit from but a rewrite isn't one of them. Of course if you dislike the architecture and the constraints of working within or incrementally evolving the existing framework then I can understand why you'd want to start from scratch, but by discarding over 20 years of experience and optimizations you're bound to repeat some of the mistakes - and make some new ones 🙂 As I see it Graphics32 and Image32 doesn't really target the same problem space.

A bit premature wouldn't you say. If you consider the rest of the pipeline then using optimized assembly for this will not make any significant difference. Good point. I think I would just not use TBitmap for this and either create a DIB directly or use a TBitmap32 from Graphics32 (with a memory backend).

Hmm. I can't really say. I guess it greatly depends on what you're doing. FWIW, the alpha composition part is actually documented in the help. One of the things people often struggle with is the difference between blend, merge and combine and in which situations to use what. Even I get them mixed up at occasionally. If performance is critical then it would be good to know about the different data types: TFloat, TFixed and integer. I think everybody understands float and integer but I guess fixed precision math isn't common knowledge. The graphics32 TFixed is a 32-bit binary with 16 magnitude bits and 16 fractional bits. I don't have any good links at hand. Google "fixed point".

I can't see how resampling would make it any faster unless your streaming implementation really sucks. Resampling would mean that you'd have to read all the pixel data, juggle it around, store it in a new buffer and then read from that buffer instead. Considerably more expensive than whatever solution you can come up with that just reads the data via Scanline. You haven't shown how you RGBA and RGB types are declared but assuming the R-G-B ordering are the same and the A is the last (i.e. high) byte then just read 4 bytes (that's a DWORD) from the source and write 3 bytes. Rinse, repeat. If the source is ABGR and the destination is RGB (e.g. TColor) then you can rearrange the bits like this: function ABGR2RGB(ABGR: DWORD): TColor; begin Result := ((ABGR and $00FF0000) shr 16) or (ABGR and $0000FF00) or ((ABGR and $000000FF) shl 16); end; or in assembler: function ABGR2RGB(ABGR: DWORD): TColor; asm mov EAX, ECX // Remove this for 32-bit rol EAX, 8 xor AL, AL bswap EAX end;

Set a break point on the CreateFile (and maybe OpenFile) API function and set the break condition to match the name of the file somehow.

Yes, that was my assumption. You can use the Graphics32 to map from a quadrilateral to a rectangle too (for example I use it for perspective correction), but it's true that one of the quadrilaterals must be a rectangle. However since it can do both forward and reverse transformation you can actually use two of them to do quadrilateral to quadrilateral transformation although that would not be very efficient. A better way would be to use one to create the source matrix, use a second to create the destination matrix, multiply the first with the inverse of the second and use the result as the transformation matrix. I believe that's also the method you use. I.e. Matrix = SrcMatrix * Adjoint(DstMatrix) True, but I don't think Graphics32 has ever targeted the average user. It does have a steep learning curve and does require an understanding of at least some of the low level principles - such as alpha compositing.

As far as I know Graphics32 has supported 64-bit for ages. Doesn't it work for you?

Interesting. It looks like it should be easy to adapt that algorithm to the Graphics32 transformation framework. I'll give it go and compare it to the existing one. Turns out there's almost nothing gained from using that method. While the matrix setup (which runs only once) is slightly faster, the transformation matrix (which is used once per target pixel) is exactly the same and thus yields the same performance and result.

Apart from the braces I don't see a problem with that example. It's a convenience or wrapper function and while it's not clear from the context the function doesn't appear to do two completely different things based on the value. A kitten dies every time you do that. Remember that anyone reading the code that uses the function will have no idea that the parameter name makes the intent clear. EnableDisableControls(True); // WTH? EnableDisableControls(False); // WTF?

If the internal pixel data format is the same (which I suspect they are), then you can wrap a TImage32 in a TBitmap32 via a Graphics32 memory backend. They will both be operating on the same block of pixel memory so take care if you resize the TImage32 while the TBitmap32 is associated with it. I don't think you can do it the other way round (wrap TBitmap32 in a TImage32) since TImage32 doesn't have a backend concept. Of course you can always copy the pixel data from one to the other, manipulate it and then copy it back, but that's not very efficient.

Hi Angus and welcome Well, if all you want is a hammer then all the other tools may indeed seem like bloat. The VPR polygon renderer and the line methods solve two different but similar problems. Remember that the purpose of Graphics32 is to do things as fast as possible. This means specialization over generalization. VPR is a generalized vector renderer that does many things reasonably well while the line methods does one single thing as fast as possible. That's why, instead of a single line method with a bunch of parameters, we have individual methods for vertical lines, horizontal lines and "other" lines. It's also why each of these methods are found in different variants each supporting different feature combinations: clipped or unclipped coordinates, transparency, anti alias or not, patterns, etc. And for different numeric types: integer, floating point or fixed precision. It's all about avoiding compromises that would hurt performance and give the user of Graphics32 control over the choices that have an impact on performance. Replacing the line methods with VPR would be like putting all-weather tires on a Formula 1 car. The MoveTo/LineTo methods, like their TCanvas counterparts, are purely high level convenience methods that will be superseded and can be removed once the TCanvas32 rewrite gets merged. But that's being blocked by the 2.0 non-release Interesting. It looks like it should be easy to adapt that algorithm to the Graphics32 transformation framework. I'll give it go and compare it to the existing one.

Please post it here (or in a Git repository somewhere) when you're done. It's probably too computationally expensive for the stuff I use color distance functions for, but I'd like to give it a go regardless. Here are the ones I use for stuff like flood fill and magic wand selection with tolarance, dithering etc. The ColorDistanceRGBA function gives a fast approximation of "visual" difference and is based on this: https://www.compuphase.com/cmetric.htm interface //------------------------------------------------------------------------------ // // Color distance functions // //------------------------------------------------------------------------------ function ColorDistanceSimpleRGB(Old, New: TColor32): Integer; function ColorDistanceRGBA(Old, New: TColor32): Integer; // Note: Not linear. Visual difference. function ColorDistanceRGBALinear(Old, New: TColor32): Integer; function ColorDistanceRGBLinear(Old, New: TColor32): Integer; function ColorDistanceAverageRGB(Old, New: TColor32): Integer; // The HSV values of the first (Old) parameter is cached so when comparing // multiple values you should attempt to keep the first parameter constant. function ColorDistanceHue(Old, New: TColor32): Integer; function ColorDistanceSaturation(Old, New: TColor32): Integer; function ColorDistanceBrightness(Old, New: TColor32): Integer; implementation //------------------------------------------------------------------------------ // // Color distance functions // //------------------------------------------------------------------------------ function ColorDistanceSimpleRGB(Old, New: TColor32): Integer; begin if (Old <> New) then Result := 255 else Result := 0; end; function ColorDistanceRGBA(Old, New: TColor32): Integer; begin if (Old = New) then Exit(0); if (Old and $FF000000 = 0) xor (New and $FF000000 = 0) then Exit(255); var AlphaOld := AlphaComponent(Old); var AlphaNew := AlphaComponent(New); if (AlphaOld <> AlphaNew) then begin if (AlphaOld <> 255) then Old := ColorScale(Old, AlphaOld); if (AlphaNew <> 255) then New := ColorScale(New, AlphaNew); EMMS; end; // See "Colour metric" by Thiadmer Riemersma // http://www.compuphase.com/cmetric.htm // Modified to consider alpha. Adjusted to maintain 0..255 range var Mean := (RedComponent(Old) + RedComponent(New)) div 2; var dA := AlphaNew - AlphaOld; var dR := RedComponent(New) - RedComponent(Old); var dG := GreenComponent(New) - GreenComponent(Old); var dB := BlueComponent(New) - BlueComponent(Old); Result := Round(Sqrt(( dA*dA + (((512+Mean)*dR*dR) shr 8) + ((dG*dG) shl 2) + (((767-Mean)*dB*dB) shr 8)) / 4)); end; function ColorDistanceRGBALinear(Old, New: TColor32): Integer; begin if (Old = New) then Exit(0); if (Old and $FF000000 = 0) xor (New and $FF000000 = 0) then Exit(255); var AlphaOld := AlphaComponent(Old); var AlphaNew := AlphaComponent(New); if (AlphaOld <> AlphaNew) then begin if (AlphaOld <> 255) then Old := ColorScale(Old, AlphaOld); if (AlphaNew <> 255) then New := ColorScale(New, AlphaNew); EMMS; end; var dA := AlphaNew - AlphaOld; var dR := RedComponent(New) - RedComponent(Old); var dG := GreenComponent(New) - GreenComponent(Old); var dB := BlueComponent(New) - BlueComponent(Old); Result := Round(Sqrt(( dA*dA + dR*dR + dG*dG + dB*dB) / 4 )); end; function ColorDistanceRGBLinear(Old, New: TColor32): Integer; begin if (Old = New) then Result := 0 else // All transparent colors are considered equal regardless of RGB if (Old and $FF000000 <> $FF000000) and (New and $FF000000 <> $FF000000) then Result := 0 else // Difference in transparency = max difference if (Old and $FF000000 = 0) xor (New and $FF000000 = 0) then Result := 255 else begin var dR := RedComponent(New) - RedComponent(Old); var dG := GreenComponent(New) - GreenComponent(Old); var dB := BlueComponent(New) - BlueComponent(Old); Result := Round(Sqrt(( dR*dR + dG*dG + dB*dB) / 3 )); end; end; function ColorDistanceAverageRGB(Old, New: TColor32): Integer; asm AND EAX,$00FFFFFF AND EDX,$00FFFFFF MOVD MM0,EAX MOVD MM1,EDX PSADBW MM0,MM1 MOVD EAX,MM0 IMUL EAX,$555555 SHR EAX,24 //Result := ((C shr 16 and $FF) + (C shr 8 and $FF) + (C and $FF)) div 3; end; var HSLCacheColor: TColor32 = 0; HSLCacheH: Byte = 0; HSLCacheS: Byte = 0; HSLCacheL: Byte = 0; function ColorDistanceHue(Old, New: TColor32): Integer; var Z, A, B: Byte; begin if (Old = New) then Exit(0); if (Old and $FF000000 = 0) xor (New and $FF000000 = 0) then Exit(255); if (Old and $FF000000 <> New and $FF000000) then begin if (Old and $FF000000 <> $FF000000) then Old := ColorScale(Old, AlphaComponent(Old)); if (New and $FF000000 <> $FF000000) then New := ColorScale(New, AlphaComponent(New)); EMMS; end; if (Old <> HSLCacheColor) then begin HSLCacheColor := Old; RGBtoHSL(Old, HSLCacheH, HSLCacheS, HSLCacheL); end; A := HSLCacheH; RGBtoHSL(New, B, Z, Z); Result := Abs(A - B); end; function ColorDistanceSaturation(Old, New: TColor32): Integer; var Z, A, B: Byte; begin if (Old = New) then Exit(0); if (Old and $FF000000 = 0) xor (New and $FF000000 = 0) then Exit(255); if (Old and $FF000000 <> New and $FF000000) then begin if (Old and $FF000000 <> $FF000000) then Old := ColorScale(Old, AlphaComponent(Old)); if (New and $FF000000 <> $FF000000) then New := ColorScale(New, AlphaComponent(New)); EMMS; end; if (Old <> HSLCacheColor) then begin HSLCacheColor := Old; RGBtoHSL(Old, HSLCacheH, HSLCacheS, HSLCacheL); end; A := HSLCacheS; RGBtoHSL(New, Z, B, Z); Result := Abs(A - B); end; function ColorDistanceBrightness(Old, New: TColor32): Integer; var Z, A, B: Byte; begin if (Old = New) then Exit(0); if (Old and $FF000000 = 0) xor (New and $FF000000 = 0) then Exit(255); if (Old and $FF000000 <> New and $FF000000) then begin if (Old and $FF000000 <> $FF000000) then Old := ColorScale(Old, AlphaComponent(Old)); if (New and $FF000000 <> $FF000000) then New := ColorScale(New, AlphaComponent(New)); EMMS; end; if (Old <> HSLCacheColor) then begin HSLCacheColor := Old; RGBtoHSL(Old, HSLCacheH, HSLCacheS, HSLCacheL); end; A := HSLCacheL; RGBtoHSL(New, Z, Z, B); Result := Abs(A - B); end;

Good one

The Graphics32 team First of all I'm not the maintainer of Graphics32. I'm just a contributor. I don't even have admin rights to the main repository. As far as I'm concerned the current project lead is @CWBudde1 but I'm not sure he agrees and he's also been largely absent in a long time. Of the remaining 4 members, micha137 hasn't contributed anything significant in a year and Michael Hansen, Mattias Andersson and Andre Beckedorf hasn't been active in a decade. https://github.com/graphics32/graphics32/graphs/contributors (I'm not sure how reliable that page is as I seem to be absent from it). Roadmap The last roadmap I know of was from 2012 (posted in the old graphics32 newsgroups) and concerned the "mythical version 2.0". Since then some of the items on the roadmap has been implemented, some has been superseded and some things not on the roadmap has been added. At present only the Graphics32 issue tracker at Github gives any indication of the direction the project might move. Lack of progress From my POW the inability to make a decision and actually release version 2.0, incomplete or not, has been one of the reasons why the project has stalled. For example the present version supports Delphi 7 and later which greatly limits what can be done - or what people are willing to do. A new version would drop support for ancient versions of Delphi and only support XE and later. In April 2019 it was decided, by Christian, Angus and I as far as I recall, that we should just release version 2.0 as-is. But again, without anyone to take the lead, nothing happened. In my opinion the greatest blow to Graphics32 was the complete loss of the Graphics32 community. This happened when the project was moved to Github and people stopped using the newsgroups. Github is great for managing the project but it's not a community platform. Without a community we're left with individual developers that might still have an interest in the project itself but soon burns out or simply isn't interested in developing in a void with no interaction with others or feedback from the users. Apart from the discussions and QAs, a big part of the old newsgroups was that people posted examples of what they did with Graphics32 and how they did it, extension libraries and graphic algorithm implementations. Luckily I still have an almost complete local copy of the newsgroups and it's still a great resource for inspiration, examples and solutions. Actually it seems the usenet server is still alive: nntp://news.graphics32.org Of course one needs a news client to access them and I'm probably one of the last people on earth to have one installed Image32 I have read the Image32 documentation and I think I've looked at the source once but beyond that I have little knowledge about the project. I would be very surprised if Angus didn't use the techniques used in Graphics32 as inspiration. Although I know he loves to write things from scratch I doubt that he doesn't use Graphics32 as a reference. Anyway, I can only guess. As far as I can see the "architecture" of Image32 is that there isn't one; While Graphics32 is an object oriented framework on top of some highly optimized low level routines, Image32 is more of a monolithic design - one class does everything. As far as I remember this dislike of OO was one of the reasons he wanted to write his own. Another was that he felt Graphics32 had become bloated. I don't agree but that's beside the point. Current state of the project As I see it the current version (i.e. head in the master branch) is stable. There are no grave issues and nothing technical that hinders future adoption of the library into new projects. The documentation has fallen behind and in a few places it is no longer correct. The examples aren't that great but at least they compile and do what they were written to do. The future As I'm just another contributor I can only speak to what I would like to see happen. Someone has to take the lead. It could be me but then I would have to stop contributing code. I can't do both. Also, although I do have opinions about how and what should be done my area of expertise is architecture and implementation. Get 2.0 released or simply abandon the idea of major release versions. As I said above before the 2.0 problem is resolved there will be little or no progress. Move the documentation into a wiki so we're actually able to maintain it. Currently it seems updating the documentation requires custom tools and I for one don't need the hassle of building, installing and maintaining some tool just to keep the docs up to date. It's hard enough to find the motivation to do so without that. Separate the examples from the showcases and write some (or a lot) of small, simple examples that demonstrate how to get started with Graphics32 and how to solve the most common tasks/problems. Even I hardly look at the current examples when I need to figure out how to do something as they are mostly too advanced or bury the relevant code in unrelated gimmicks. I can imagine that they must be undecipherable to a new user. Get rid of or repair the code contributed by cowboys. Some of the newer features of Graphics32 was contributed (and accepted) without regard for the fact that other people should be able to maintain it (for example if the author went awol or decided to work on another project instead). The code should be commented, the algorithms used should be documented, etc. Even if none of the above happens I think Graphics32 will be safe for the immediate future. It's a stable and fairly complete library and there are enough people and projects using it that someone else is bound to pick up the mantle if all the current contributors get hit by a bus.

It does. You just need to keep the attribution, copyright and license notice in the source.