Leaderboard

A new development snapshot of IDE Fix Pack for 10.3 Rio is available. The Win64 (DCC64) and Android (DCCAARM) compiler patches should now work as excepted. Changes: Added: Support for Delphi 10.3 Rio Added: Fix for TStringList.IndexOfName bug (RSP-21633) Added: Fix for access violoation in the Welcomepage JScript9.dll binding Added: TCustomListBox.ResetContent is skipped if the handle isn't created yet Added: DFM Streaming optimizations Added: FillChar uses Enhanced REP MOVSB/STOSB cpu feature if available for large sizes. Added: Enabled CPU LOCK string assignment optimization for local variables Added: -Oe (experimental optimizations) and -x-cgo compiler option extension (Remove of some unneccessary push/pop operations) Added: Expression Evaluator allows array access to pointers even if the type wasn't declared with {$POINTERMATH ON} Added: New compiler option extensions: -x--compileonly, -x--reslist, -x--depfile, -x--unitstats Added: More performance optimization for the DCC64 compiler Added: TStringBuilder.SetLength optimization [RSP-19178] Added: TStrings.GetDelimitedText optimization Fixed: Packages with duplicate units may not have caused a fatal compiler error. IDEFixPackD103Reg64.7z fastdccD103vDev.7z

Delphi Developers Archive (Experimental) for the Google + Delphi Developers Community is online. https://delphi-developers-archive.blogspot.com The posts are searchable by tag list or free text search. FYI - This is work in progress, and I hope to improve the following issues: - Some posts have erroneous titles - Some posts are missing attribution of the original poster - Some 600 posts are missing due to an inexplicable quota error during import Comments on the archived posts are currently disabled until the import is finalized. Comments appreciated.

Users of ModelMaker may appreciate the availability of a Modelmaker IDE Integration Expert for Delphi 10.3 Rio. Note: ModelMaker is a separate Native Delphi Visual modeling and Refactoring tool based on UML™ 2 technology. Not to be confused with MMX Code Explorer. More info here: ModelMaker IDE Integration Expert for Delphi 10.3 Rio released

The code: var C: AnsiChar := #$0A; if C in [#$A, #$D] then Generates the following assembly code in 32 bits. Project2.dpr.26: var C: AnsiChar := #$0A; 004F9C10 C645FF0A mov byte ptr [ebp-$01],$0a Project2.dpr.41: if C in [#$A, #$D] then 004F9C14 8A45FF mov al,[ebp-$01] 004F9C17 2C0A sub al,$0a 004F9C19 7404 jz $004f9c1f 004F9C1B 2C03 sub al,$03 004F9C1D 751C jnz $004f9c3b On the other hand var C: Char := #$0A0A; if C in [#$A, #$D] then generates the following: Project2.dpr.26: var C: Char := #$0A0A; 004F9C10 66C745FE0A0A mov word ptr [ebp-$02],$0a0a Project2.dpr.41: if C in [#$A, #$D] then 004F9C16 668B45FE mov ax,[ebp-$02] 004F9C1A 6683E80A sub ax,$0a 004F9C1E 7406 jz $004f9c26 004F9C20 6683E803 sub ax,$03 004F9C24 751C jnz $004f9c42 Notice that it handles the wide char correctly. However the compiler issues the following warning: [dcc32 Warning] Project2.dpr(41): W1050 WideChar reduced to byte char in set expressions. Consider using 'CharInSet' function in 'SysUtils' unit. Question 1: Why the warning is issued, given that the generated code does not reduce the wide char to a byte? Question 2: Doesn't this mean that RSP-13141 has been resolved except for the warning? In the discussion of that issue @Arnaud Bouchez points out that the warning is misleading. In 64 bit the generated code looks much more complex: Project2.dpr.26: var C: Char := #$0A0A; 00000000005716E8 66C7452E0A0A mov word ptr [rbp+$2e],$0a0a Project2.dpr.41: if C in [#$A, #$D] then 00000000005716EE 480FB7452E movzx rax,word ptr [rbp+$2e] 00000000005716F3 6683E808 sub ax,$08 00000000005716F7 6683F807 cmp ax,$07 00000000005716FB 7718 jnbe TestCharInSet + $35 00000000005716FD B201 mov dl,$01 00000000005716FF 8BC8 mov ecx,eax 0000000000571701 80E17F and cl,$7f 0000000000571704 D3E2 shl edx,cl 0000000000571706 480FB60556000000 movzx rax,byte ptr [rel $00000056] 000000000057170E 84C2 test dl,al 0000000000571710 0F95C0 setnz al 0000000000571713 EB02 jmp TestCharInSet + $37 0000000000571715 33C0 xor eax,eax 0000000000571717 84C0 test al,al 0000000000571719 7422 jz TestCharInSet + $5D Question 3: Why is the code is so more complex in 64 bits? Please forgive my ignorance.

Instead of last "Size" reference there should be "Size - 1". Fixed.

Thanks very much for the efford, looks good to me. Search seems to do well in full text, at first sight, great.

As has been clarified by Hick Hodges a few times before (when he was working for Emba), all is exactly as Andy wants it. And he does have access to the source as per agreement. And no he does not get paid (as far as we know) and (as far as we know) that's how he wants it. This point keep coming up again and again and it's getting rather old, just be happy with the work Andy is doing and take your blessings where you can get them. Yes Emba should do more, better, faster etc but it is as it is.

Here's how I would solve it - in theory: Assign each tile a sequential number. Since you know the size of the target bitmap (TargetSizeX*TargetSizeY) and you know the size of each tile (TileSizeX*TileSizeY), calculating the tile number is simple: TileCountX := ((TargetSizeX + TileSizeX-1) div TileSizeX); TileCountY := ((TargetSizeY + TileSizeY-1) div TileSizeY); TileCount := TileCountX * TileCountY; // Tile number goes from 0 to TileCount-1 // Tile coords from Tile number TileX := (TileNumber mod TileCountX) * TileSizeX; TileY := (TileNumber div TileCountY) * TileSizeY; The job of reading a tile from the database can be delegated to one or more tasks, depending on how you choose to partition the workload. A DB tasks reads a request from a (threadsafe) queue, performs the database request, stores the result in the request object and notifies the requestor that the result is ready. The request object contains: 1) Tile number, 2) Result bitmap and 3) Signal object (e.g. an event handle). Create a number of tasks to render the tiles. Each task grabs a Tile Number (just use a InterlockedIncrement() on a shared integer), creates a DB request object, queues it and waits for the result. Once the result is ready the task draws the tile onto the target bitmap (*) and starts over. To avoid cache conflicts it would be best if the Tile Numbers currently being worked on are as far apart as possible, but I guess the DB overhead will make this optimization irrelevant. *) A TBitmap32 is just a chunk of sequential memory and since none of the tile tasks will write to the same memory it is not necessary to lock the target bitmap. So in short: One thread pool to render the tiles and one thread pool to read from the database. A work queue in between them. However like @Cristian Peța said, unless you are using some super fast ninja science fiction database, there's no reason to try to optime the rendering much. All the tiles can probably be rendered in the time it takes to make a single database request. In fact, using graphics32, a thread context switch will take far longer that drawing a single tile. So in practice I would probably just do away with the DB tasks and execute the database request directly from the rendering tasks.

Pipeline would work as you can run each stage in more than one parallel task (by using .NumTasks). But Parallel.BackgroundWorker is probably more appropriate.

I just compiled for curiosity . On D10.2.3 XE8 i took out VirtualTreesD and included jedi.inc thats it. It compiled. I did not install.