twm's blog

I just had a nasty surprise with Delphi 10.3 when trying to build a project that worked fine with previous Delphi versions. The problem turned out the text one of my pre build events wrote to the output. It contained the string “error :”. Apparently Delphi 10.3 parses the output of the build events and tries to interpret it.

Try for yourself:

• Create a batch file test.cmd with the following content:

  @echo error: bla
  

• Add it as a pre build event to a Delphi project:

  call path\to\test.cmd
  

• Try to compile.

If I’m right, you will get an error like:

And the Messages window will contain the following error:

[Exec Error] EXEC(1): bla

Very annoying. If this is documented, I can’t find it. I only see:

Cancel on error

Cancels the project build if a command returns a nonzero error code.

on http://docwiki.embarcadero.com/RADStudio/Rio/en/Build_Events and http://docwiki.embarcadero.com/RADStudio/Rio/en/Creating_Build_Events

As you will find in the documentation and on the web the usual way to access the pixels of a Bitmap in Delphi is using the Scanline[] array property. Something like this:

type
  TRgbTriple = packed record
    // do not change the order of the fields, do not add any fields
    Blue: Byte;
    Green: Byte;
    Red: Byte;
  end;

  TRgbTripleArray = packed array[0..MaxInt div SizeOf(TRgbTriple) - 1] of TRgbTriple;
  PRgbTripleArray = ^TRgbTripleArray;

procedure ConvertBmp(_InBmp, _OutBmp: TBitmap);
var
  x, y: Integer;
  Pixel: TRgbTriple;
begin
  Assert(_InBmp.PixelFormat = pf24bit);
  _OutBmp.SetSize(_InBmp.Width, _InBmp.Height);
  _OutBmp.PixelFormat := pf24bit;
  for y := 0 to Height - 1 do begin
    for x := 0 to Width - 1 do begin
      Pixel := PRgbTripleArray(_InBmp.Scanline[y])^[x];
      doSomething(Pixel);
      PRgbTripleArray(_OutBmp.Scanline[y])^[x] := Pixel;
    end;
  end;
end;

This code first checks that the input bitmap is using 24 bits per pixel, then sets the output bitmap to do the same. Then it enumerates through all the lines in the input bitmap and then all the pixels in that line, reads them does “something” with them and finally writes them to the corresponding pixel in the output bitmap.

Let’s assume a small VGA sized bitmap, so we get 480 lines with 640 pixels each. In total that makes 2 * 640 * 480 calls to ScanLine[], each taking a short time (There are multiple function calls in the getter method.).

Call that code for several bitmaps and you will end up with a huge amount of time spent in the calls to ScanLine[]. (Don’t just take my word for it, go ahead and time it!)

The first optimization that can be done is calling ScanLine[] only once for each line of each bitmap:

var
  InScanLine: PRgbTripleArray;
  OutScanLine: PRgbTripleArray;
// ...
  for y := 0 to Height - 1 do begin
    InScanLine := PRgbTripleArray(_InBmp.Scanline[y]);
    OutScanline := PRgbTripleArray(_OutBmp.Scanline[y]);
    for x := 0 to Width - 1 do begin
      Pixel := InScanLine^[x];
      doSomething(Pixel);
      OutScanLine^[x] := Pixel;
    end;
  end;

This reduces the number of calls to ScanLine by a factor of 640, which you will find is quite significant. (Again: Time it!)

But we still can do more. What if we only needed 4 calls in total rather than 2 * 480 ?

All we need to do is calculating the line addresses ourself. To do that we simply need two addresses, the one of the first and the one of the second line:

// if you are using Delphi 2007 or older you need to correct the NativeInt declaration from 8 bytes to 4 bytes:
{$IF SizeOf(Pointer) = 4}
type
  NativeInt = Integer;
{$IFEND}

function AddToPtr(const _Ptr: Pointer; _Offset: NativeInt): Pointer; inline;
begin
  Result := Pointer(NativeInt(_Ptr) + _Offset);
end;

function PtrDiff(const _Ptr1, _Ptr2: Pointer): NativeInt; inline;
begin
  Result := NativeInt(_Ptr1) - NativeInt(_Ptr2);
end;

var
  BytesPerPixel: NativeInt;
  InScanLine0: Pointer;
  InBytesPerLine: NativeInt;
  OutScanLine0: Pointer;
  InBytesPerLine: NativeInt;
  InPixel: PRgbTriple;
  OutPixel: PRgbTriple;
// ...
  BytesPerPixel := SizeOf(Pixel)  
  InScanLine0 := InBmp.ScanLine[0];
  InBytesPerLine := NativeInt(_InBmp.ScanLine[1]) - NativeInt(InScanLine0);
  OutScanLine0 := _OutputBmp.ScanLine[0];
  OutBytesPerLine := NativeInt(_OutBmp.ScanLine[1]) - NativeInt(OutScanLine0);
  OutPixel := OutScanLine0;
  for y := 0 to Height - 1 do begin
    for x := 0 to Width - 1 do begin
      InPixel := AddToPtr(InScanLine0, InBytesPerLine * y + x * BytesPerPixel);
      Pixel := InPixel^;
      doSomething(Pixel);
      OutPixel := AddToPtr(OutScanLine0, OutBytesPerLine * y + x * BytesPerPixel);
      OutPixel^ := Pixel;
    end;
  end;

What we do here is calculate the difference between the first two scan lines and use it to calculate the address of each scan line in the bitmap.

Note: Most of the time this difference will be negative because on Windows Bitmaps usually are stored bottom to top.

There are two inlined helper functions AddToPtr and PtrDiff who do the pointer arithmetic by converting the pointer to NativeInt and back.

Note that the NativeInt declaration in Delphi 2007 and older is wrong. That’s why we redeclare it as 4 bytes in the conditional define above if SizeOf(Pointer) is 4 bytes (32 bits). The code should also work for 64 bits, but I haven’t tried it.

David Hoyle just blogged about Adding Menu Items to the IDE Editor’s Context Menu. As always his article is quite insightful, in particular the last part, because many people forget this:

That’s it, all done, or is it…

Well for a DLL yes as you would never get a situation where the Editor Popup Menu is called when you DLL is not in memory any more however this is not true for a BPL based plug-in so we need to reverse our hook.

… because a BPL based plugin can be loaded and unloaded at any time.

For which he then gives the following code:

Procedure TDDTWizard.UnhookEditorPopupMenu;
Var
  EditorPopupMenu : TPopupActionBar;
Begin
  EditorPopupMenu := FindEditorPopup;
  If Assigned(EditorPopupMenu) And Assigned(EditorPopupMenu.OnPopup) Then
    EditorPopupMenu.OnPopup := TNotifyEvent(FEditorPopupMethod);
End; 

And here we have a problem: How do you know that you can safely remove your hook? Some other plugin might have changed it and you will never know. If you simply change the OnPopup event back to the value you saved when you installed it, you might disable another plugin which was installed/initialized after yours. Or even worse, what if the plugin whose event you saved also has been unloaded? What do you do then? Simply reinstalling its original event handler will potenially crash the IDE the next time the event is called.

That’s exactly the reason why I wrote this article (years ago):
Safe event hooking for Delphi IDE plugins

I use this in my own plugins (Delphi IDE Explorer and parts of GExperts) and it works fine if both plugins adhere to this “standard”. Unfortunately I know of no other plugins who do. If you write Delphi IDE plugins, you might want to consider also tyring to play nice with other plugins.

(Btw David, your blog still says “Copyright David Hoyle 2018” in the footer.)