ImageEn for Delphi and C++ Builder ImageEn for Delphi and C++ Builder

 

ImageEn Forum
Profile    Join    Active Topics    Forum FAQ    Search this forumSearch
 All Forums
 ImageEn Library for Delphi, C++ and .Net
 ImageEn and IEvolution Support Forum
 TImageEnView Thread Safe in 64Bit

Note: You must be registered in order to post a reply.
To register, click here. Registration is FREE!

View 
UserName:
Password:
Format  Bold Italicized Underline  Align Left Centered Align Right  Horizontal Rule  Insert Hyperlink   Browse for an image to attach to your post Browse for a zip to attach to your post Insert Code  Insert Quote Insert List
   
Message 

 

Emoji
Smile [:)] Big Smile [:D] Cool [8D] Blush [:I]
Tongue [:P] Evil [):] Wink [;)] Black Eye [B)]
Frown [:(] Shocked [:0] Angry [:(!] Sleepy [|)]
Kisses [:X] Approve [^] Disapprove [V] Question [?]

 
Check here to subscribe to this topic.
   

T O P I C    R E V I E W
brucepolky 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?

7   L A T E S T    R E P L I E S    (Newest First)
fab 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.
brucepolky 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 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 Posted - May 19 2013 : 12:08:33
Downloaded 4.3.1. But it did not make any difference to this problem.
fab 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 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.


brucepolky 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