| Author |
 Topic  |
|
|
brucepolky
7 Posts |
 Posted - May 18 2013 : 21:09:43
|
I have some code that resizes all images in a folder.
It calls a thread that does the resizing for each of the images.
The code has worked well in my application for a number of years.
When the same code is compiled in the 64bit (Delphi XE3) if fails. Sometimes it shows an violation error as soon as it tries to reference the TImageEnView component inside the thread. Sometimes it just hangs everything including XE3. Sometimes it ties all processors up for as long as you let it run.
Is the ImageEnView component thread safe in 64Bit?
|
|
|
brucepolky
7 Posts |
Posted - May 19 2013 : 00:28:57
|
I have reduced the code down to the smallest project I can and added it to the post. If anybody can look at it and see what is causing the problem it would be appreciated.
450 Bytes |
 |
|
|
brucepolky
7 Posts |
Posted - May 19 2013 : 00:33:52
|
OK, so I cannot post it that way.... Code example is below, Two units:
unit UnFmMain;
interface
uses
Winapi.Windows, Winapi.Messages, System.SysUtils, System.Variants, System.Classes, Vcl.Graphics,
Vcl.Controls, Vcl.Forms, Vcl.Dialogs, UnThTHumb, Vcl.StdCtrls;
type
TForm1 = class(TForm)
WorkPath: TEdit;
Label1: TLabel;
BtRun: TButton;
procedure BtRunClick(Sender: TObject);
private
{ Private declarations }
public
{ Public declarations }
end;
var
Form1: TForm1;
implementation
{$R *.dfm}
procedure TForm1.BtRunClick(Sender: TObject);
Var
Counter : Integer;
ThreadList : Array [1..10] of THThumb;
ThreadDataList : Array [1..10] of ThumbData;
begin
For Counter := 1 to 10 do
begin
ThreadDataList[Counter].WorkDir := WorkPath.Text;
ThreadDataList[Counter].FileName := IntToStr(Counter) + '.jpg';
ThreadList[Counter] := ThThumb.Create(False, @ThreadDataList[Counter]);
end;
{endfor}
end;
end.
unit UnThThumb;
interface
uses
Windows, Classes, SysUtils, Graphics, Forms, hyiedefs,
ImageEnView, StdCtrls, Dialogs;
type
ThumbData = Record
WorkDir : String;
FileName : String;
end;
pThumbData = ^ThumbData;
THThumb = class(TThread)
Private
LocData : ThumbData;
protected
procedure Execute; override;
public
constructor Create(CreateSuspended : Boolean;
InData : pThumbData);
end;
implementation
constructor THThumb.Create(CreateSuspended : Boolean;
InData : pThumbData);
begin
inherited Create(CreateSuspended);
LocData.WorkDir := InData^.WorkDir;
LocData.FileName := InData^.FileName;
Priority := tpNormal;
FreeOnTerminate := True;
end;
{#######################################################################################}
procedure THThumb.Execute;
{#######################################################################################}
Var
IV : TImageEnView;
begin
IV := TImageEnView.Create(Nil);
IV.IO.LoadFromFile(LocData.WorkDir + '\' + LocData.FileName);
If Not IV.IO.Aborting then
begin
IV.Proc.Resample(300, 300, rfFastLinear);
IV.IO.SaveToFileJpeg(LocData.WorkDir + '\th' + LocData.FileName);
end;
{endif}
IV.Free;
Terminate;
end;
end.
|
|
|
|
fab
1310 Posts |
Posted - May 19 2013 : 00:36:26
|
| Please try also current version (4.3.1), because it fixes some bugs related to 64 bit. |
|
|
|
brucepolky
7 Posts |
Posted - May 19 2013 : 12:08:33
|
| Downloaded 4.3.1. But it did not make any difference to this problem. |
|
|
|
fab
1310 Posts |
Posted - May 20 2013 : 01:51:25
|
| Ok, I can replicate now. Please contact support in order to receive an updated version that fixes this problem. |
|
|
|
brucepolky
7 Posts |
Posted - Jun 04 2013 : 03:08:43
|
I finally was able to implement the update. It stops the error, but it also negates the whole threading advantage. It looks like the system now forces all the work to be done in the main thread, irrespective of whether it is called as a separate thread or not.
When I run the threaded code and the non threaded code, it takes almost exactly the same time to complete the job. I have run both while watching the resource monitor and it seems that the threaded version is still only utilising one processor at any one time, irrespective of how many threads I create.
I have had to force multi threading by a back door method to keep my customers happy. The main program repeatedly calls a completely separate application to work on each image. It works, but it is very messy. |
|
|
|
fab
1310 Posts |
Posted - Jun 06 2013 : 13:11:53
|
This fix doesn't do it. There is a critical section only when external DLL is loaded and unloaded, no more.
The "main thread" limitation doesn't come from ImageEn.
I can only suggest to avoid to use TImageEnView inside the thread, but only TIEBitmap connected to TImageEnProc and TImageEnIO. |
|
|
| |
Topic |
|
|
|
Search
TImageEnView Thread Safe in 64Bit
