pyscripter

@Kas Ob.order which is the same as shown by IDA works here. I can recolor both ways: if Succeeded(Element.GetAttributeValue('fill', D2D1_SVG_ATTRIBUTE_POD_TYPE_COLOR, @OldColor, SizeOf(OldColor))) then begin if (OldColor.r <> 0) or (OldColor.g <> 0) or (OldColor.b <> 0) then Assert(Succeeded(Element.SetAttributeValue('fill', D2D1_SVG_ATTRIBUTE_POD_TYPE_COLOR, @NewColor, SizeOf(NewColor)))); end; and Assert(Succeeded(Element.GetAttributeValue('fill', IID_ID2D1SvgPaint, Pointer(Paint)))); if Assigned(Paint) then begin Paint._AddRef; if Paint.GetPaintType = D2D1_SVG_PAINT_TYPE_COLOR then begin Paint.GetColor(OldColor); if (OldColor.r <> 0) or (OldColor.g <> 0) or (OldColor.b <> 0) then Paint.SetColor(NewColor); end; end; end; The declaration of SetColor needs to be changed: function SetColor(Const color: D2D1_COLOR_F): HResult; stdcall;

The functions seem to work now (Succeeded) but still no recoloring though). What is strange is that the order of the overloads in the VTable is the reverse than that in the include file. What is the tool you are using to inspect the Vtables?

It does not recolor here. Could you please post your project.

This is the one I was getting before at $78 I think. Also when I call it using the commented code it does not succeed. Assert(Succeeded( Element.GetAttributeValue('fill', IID_ID2D1SvgPaint, Pointer(Paint)) )) fails. It does not appear to be in the right order now. Do you get the recoloring to work.

@Mahdi Safsafi Amazing stuff. Questions: There are many more overloads in the include file implemented as inline functions. Do those interfere with the above? After the first set of Set/GetAttributeValue there is a GetAttributeValueLength function. Does this comes last? It was just by accident that my GetAttributeCall was picking the correct overload!! That really confused me.

Thanks for your efforts...

Impressive guess work!

Thanks, but this is puzzling. at $7C is the GetAttributeValue, which I know it works and at $78 should be the one before. (right?). In the include file the function before the GetAttributeValue is the relevant SetAttributeValue. How can I find the correct order?

Wow. I was using the order in the include file. What exactly is the order that works? Could you please post the relevant section of the file or the file as a whole?

I have tried to used the method used in the sample see the commented out code: Assert(Succeeded( Element.GetAttributeValue('fill', IID_ID2D1SvgPaint, Pointer(Paint)) )); but that did not work either. So I then tried to use a different overload to get the color and that worked. But setting it back produces the crash.

There is not much in the internet, just a Microsoft sample at https://github.com/microsoft/Windows-universal-samples/tree/master/Samples/D2DSvgImage/cpp which I am following. But the element works fine with GetAttributeValue call. So it should be OK.

The value of OldColor returned by GetAttributeValue is right. (I have a simple svg file and checked with the contents of the file). So GetAttributeValue works fine. Access violation at 0x75db8cbx read of address 0x000000001 D2D1_SVG_ATTRIBUTE_POD_TYPE = DWord; {$EXTERNALSYM D2D1_SVG_ATTRIBUTE_POD_TYPE} const // The attribute is a D2D1_COLOR_F. D2D1_SVG_ATTRIBUTE_POD_TYPE_COLOR = D2D1_SVG_ATTRIBUTE_POD_TYPE(1); I did check that the correct overload is called. (looked at the assembly code calliing the function: call dword ptr [eax+$7c] for GetAttributeValue , dword ptr [eax+$78] for SetAttributeValue , tripled checked with the C header file order of interface members etc). MSDN description of SetAttributeValue overload used. I am attaching the project source code in case anyone wants to have a go. The display of svg files works fine and now without using Vcl.Direct2D. Svg.zip d2d1svg.h

OldColor: TD2D1ColorF; //works with correct results if Succeeded(Element.GetAttributeValue('fill', D2D1_SVG_ATTRIBUTE_POD_TYPE_COLOR, @OldColor, SizeOf(OldColor))) // Crashes Access violation Element.SetAttributeValue('fill', D2D1_SVG_ATTRIBUTE_POD_TYPE_COLOR, @OldColor, SizeOf(OldColor)); D2D1_SVG_ATTRIBUTE_POD_TYPE_COLOR = 1 The prolog of the two functions differ. Doesn't this mean the declaration should be different? But I am not sure what SetAttributeValue expects

For comparison the following method is GetAttributeValue: /// <summary> /// Gets an attribute of this element as a POD type. Returns an error if the /// attribute is not specified. Returns an error if the attribute name is not valid /// on this element. Returns an error if the attribute cannot be expressed as the /// specified POD type. /// </summary> STDMETHOD(GetAttributeValue)( _In_ PCWSTR name, D2D1_SVG_ATTRIBUTE_POD_TYPE type, _Out_writes_bytes_(valueSizeInBytes) void *value, UINT32 valueSizeInBytes ) PURE; which I am successfully using by translating to (same parameters) function GetAttributeValue(name: LPWSTR; _type: D2D1_SVG_ATTRIBUTE_POD_TYPE; value: Pointer; valueSizeInBytes: UINT32): HResult; overload; stdcall; However the prolog of GetAttributeValue is different: 564713C0 6690 nop 564713C2 55 push ebp 564713C3 8BEC mov ebp,esp 564713C5 83EC24 sub esp,$24 564713C8 8B4D08 mov ecx,[ebp+$08] 564713CB 53 push ebx 564713CC 8BD9 mov ebx,ecx 564713CE 56 push esi 564713CF 8D4108 lea eax,[ecx+$08] 564713D2 33C9 xor ecx,ecx 564713D4 85C0 test eax,eax 564713D6 57 push edi 564713D7 0F44D9 cmovz ebx,ecx 564713DA 6A08 push $08 564713DC 5A pop edx

Pcre-Jit-Delphi Delphi wraps the PCRE library into the System.RegularExpressions unit. This unit provides a high-level, easy-to-use interface to PCRE. A limitation however is that it does not provide access to the Just-In-Time (JIT) compiler of PCRE. PCRE JIT can improve the performance of regular expression matching dramatically and is particularly useful, when you apply the same regular expression repetitively. The purpose of the Pcre-Jit-Delphi project is to patch the Delphi RTL in order to provide access to JIT. Please visit the project page at Github to see how you can use PCRE JIT in your projects. Benchmark The console project Benchmark.dpr in Demos folder compares the performance of the built-in Delphi regular expressions library, with the those of using Study without JIT and Study with JIT on a commonly used regular expression benchmark. Here are the results I got from the 64 bit version. Time | Match count ============================================================================== Delphi's own TRegEx: /Twain/ : 7.00 ms | 811 /(?i)Twain/ : 41.00 ms | 965 /[a-z]shing/ : 384.00 ms | 1540 /Huck[a-zA-Z]+|Saw[a-zA-Z]+/ : 461.00 ms | 262 /\b\w+nn\b/ : 588.00 ms | 262 /[a-q][^u-z]{13}x/ : 539.00 ms | 4094 /Tom|Sawyer|Huckleberry|Finn/ : 757.00 ms | 2598 /(?i)Tom|Sawyer|Huckleberry|Finn/ : 861.00 ms | 4152 /.{0,2}(Tom|Sawyer|Huckleberry|Finn)/ : 2615.00 ms | 2598 /.{2,4}(Tom|Sawyer|Huckleberry|Finn)/ : 2766.00 ms | 1976 /Tom.{10,25}river|river.{10,25}Tom/ : 455.00 ms | 2 /[a-zA-Z]+ing/ : 807.00 ms | 78423 /\s[a-zA-Z]{0,12}ing\s/ : 560.00 ms | 49659 /([A-Za-z]awyer|[A-Za-z]inn)\s/ : 789.00 ms | 209 /["'][^"']{0,30}[?!\.]["']/ : 321.00 ms | 8885 Total Time: 11963.00 ms ============================================================================== Delphi's own TRegEx with Study: /Twain/ : 6.00 ms | 811 /(?i)Twain/ : 41.00 ms | 965 /[a-z]shing/ : 316.00 ms | 1540 /Huck[a-zA-Z]+|Saw[a-zA-Z]+/ : 21.00 ms | 262 /\b\w+nn\b/ : 581.00 ms | 262 /[a-q][^u-z]{13}x/ : 413.00 ms | 4094 /Tom|Sawyer|Huckleberry|Finn/ : 28.00 ms | 2598 /(?i)Tom|Sawyer|Huckleberry|Finn/ : 217.00 ms | 4152 /.{0,2}(Tom|Sawyer|Huckleberry|Finn)/ : 2632.00 ms | 2598 /.{2,4}(Tom|Sawyer|Huckleberry|Finn)/ : 2785.00 ms | 1976 /Tom.{10,25}river|river.{10,25}Tom/ : 50.00 ms | 2 /[a-zA-Z]+ing/ : 759.00 ms | 78423 /\s[a-zA-Z]{0,12}ing\s/ : 563.00 ms | 49659 /([A-Za-z]awyer|[A-Za-z]inn)\s/ : 699.00 ms | 209 /["'][^"']{0,30}[?!\.]["']/ : 52.00 ms | 8885 Total Time: 9179.00 ms ============================================================================== Delphi's own TRegEx with JIT: /Twain/ : 11.00 ms | 811 /(?i)Twain/ : 14.00 ms | 965 /[a-z]shing/ : 12.00 ms | 1540 /Huck[a-zA-Z]+|Saw[a-zA-Z]+/ : 3.00 ms | 262 /\b\w+nn\b/ : 126.00 ms | 262 /[a-q][^u-z]{13}x/ : 154.00 ms | 4094 /Tom|Sawyer|Huckleberry|Finn/ : 22.00 ms | 2598 /(?i)Tom|Sawyer|Huckleberry|Finn/ : 61.00 ms | 4152 /.{0,2}(Tom|Sawyer|Huckleberry|Finn)/ : 277.00 ms | 2598 /.{2,4}(Tom|Sawyer|Huckleberry|Finn)/ : 346.00 ms | 1976 /Tom.{10,25}river|river.{10,25}Tom/ : 12.00 ms | 2 /[a-zA-Z]+ing/ : 84.00 ms | 78423 /\s[a-zA-Z]{0,12}ing\s/ : 156.00 ms | 49659 /([A-Za-z]awyer|[A-Za-z]inn)\s/ : 35.00 ms | 209 /["'][^"']{0,30}[?!\.]["']/ : 18.00 ms | 8885 Total Time: 1350.00 ms As you can see the increase in performance is impressive. Credits Many thanks to @Mahdi Safsafi who provided the assembly code for __chkstk and other Delphi developers (@Kas Ob., @David Heffernan, @Remy Lebeau, @Fr0sT.Brutal) that have provided useful advice.

FLRE is the fastest of all! One single pascal file which is good The author is a kind of genius But not as extensively tested as PCRE poorly documented not very well supported the performance gain compared to PCRE+JIT is not that big System.RegularExpressions has a nicer interface All-in-all I would stick to System.RegularExpressions at least if you add JIT.

True. And for the last 3-4 years there was no improvement in Windows svg support. However converting text to path is a reasonable workaround. In any case it is not common to have text in toolbar icons etc.

I am not able to login for some reason.

I would use the TRTLCriticalSection which is a record defined in Windows.pas. TRTLCriticalSection = record DebugInfo: PRTLCriticalSectionDebug; LockCount: Longint; RecursionCount: Longint; OwningThread: THandle; LockSemaphore: THandle; Reserved: ULONG_PTR; end; A record helper is provided in SynchObjs.pas TCriticalSectionHelper = record helper for TRTLCriticalSection procedure Initialize; inline; procedure Destroy; inline; procedure Free; inline; procedure Enter; inline; procedure Leave; inline; function TryEnter: Boolean; inline; end; According to Eric It is much less prone to this issue (I don't have the reference though) and does not incur the overhead of object creation/destruction. The SpinLock is another option. So is the Windows Slim reader writer (SRW) lock. And of course you can use TMonitor which nowadays is comparable in performance to the CriticalSection. (SpinLock and SRW locks are faster). For anyone interested here is a record wrapper to SRW locks. (* Multiple Read Exclusive Write lock based on Windows slim reader/writer (SRW) Locks. Can be also used instead of a critical session. Limitations: non-reentrant, not "fair" *) TSlimMREWSync = record private Lock: TRTLSRWLock; public procedure Create; procedure BeginRead; procedure EndRead; procedure BeginWrite; procedure EndWrite; function TryRead: Boolean; function TryWrite: Boolean; end; { TSMREWSync } procedure TSlimMREWSync.BeginRead; begin AcquireSRWLockShared(Lock); end; procedure TSlimMREWSync.BeginWrite; begin AcquireSRWLockExclusive(Lock); end; procedure TSlimMREWSync.Create; begin InitializeSRWLock(Lock); end; procedure TSlimMREWSync.EndRead; begin ReleaseSRWLockShared(Lock); end; procedure TSlimMREWSync.EndWrite; begin ReleaseSRWLockExclusive(Lock); end; function TSlimMREWSync.TryRead: Boolean; begin Result := TryAcquireSRWLockShared(Lock); end; function TSlimMREWSync.TryWrite: Boolean; begin Result := TryAcquireSRWLockExclusive(Lock); end;

Worked earlier on but now is down again.

I had the same problem. I though I had installed the patch through Getit but it was not actually installed. After reading this thread I installed by the command prompt. It appears that just clicking on the bat file via the File Explorer did not work despite getting the elevation prompt.

lol. It reminded me of the Ecumenical Liberation Army from the Network film. Great film by the way.

You can apply it manually to your own version (it only takes a couple of minutes, because the changes are few) and you only need to do it once). You can then submit a pull request with the patch in your Delphi version.

Here it is not an issue of compiler/interpreter because PERL is using a C library anyway. Perl uses its own regular expression engine not PCRE. There are many other options, Google RE, Intel's Hyperscan to mention a couple. PCRE+JIT is one of the fastest around and most widely used. I should not forget to mention FLRE written in Pascal, which is probably the fastest of all! Sometime ago I had posted in Google+ a benchmark comparing many of the above, But I not sure how to access Google+ material. Also note that the number of matches differs between Delphi and Perl. This is not surprising, because there are subtle differences in how these engines work.

There is an RSP https://quality.embarcadero.com/browse/RSP-21733 that asks for PCRE JIT support in the Delphi RTL. If you want the extra PCRE performance please vote for this. Off-topic. What does RSP stand for?