| T O P I C R E V I E W |
| Bernhard |
Posted - Jun 04 2020 : 14:17:30
Hi!
I have written a program to apply various filters to images, based on an ImageenMView, from which I select the images and work on them in a window with Imageenview. Everything worked out wonderfully in the test phase. Now I have compiled with statically linked libraries to distribute it as a compact program to other users (In project options "Use dynamic RTL"=False and "Use runtime packages"=False).
But the program now failed, when running without the IDE. I found then, that it only works if I set storeType to the slow ietNormal mode. As soon as I use the faster thumbnails (ietThumb or ietFastThumb), the program freezes as soon as it calls the FillFromDirectory method. Any idea what can be the reason?
I use C++Builder Rio 10.3 Update 3 and ImageEN 9.1.0. I tried it with 9.0 too, with the same result.
Greetings
Bernhard |
| 20 L A T E S T R E P L I E S (Newest First) |
| xequte |
Posted - Jul 12 2020 : 20:32:48
Thanks for the feedback, Andy.
If you do see any ImageEn specific issues, I'd like to try a simple demo that reproduces it.
Nigel
Xequte Software
www.imageen.com
|
| Andy_Bell |
Posted - Jul 12 2020 : 13:39:58
I don't know if this will help, but in my own (non ImageEn) C++ Builder Code I have experienced a similar lockup when using threads.
In the end I tracked it down to, not lock up between the threads, but the main VCL thread being overrun with messages.
At first I coded it with the thread calling PostMessage(...) whenever the UI needed to update itself. If the task was trivial, such as updating a simple progress meter, then no problems occurred.
However, if the UI had more to do then it would sometimes lock up. By using a logging component (such as LMD's Logger or CodeSite) I could see that the threads were still running but the UI was locked up.
Sometimes, if I waited long enough for the threads to complete their work, the UI would return to life and the logger would then suddenly show all the PostMessages being received.
From this my deduction was that if the UI could not process the update before the threads sent the next PostMessage then the whole thing would lock up and the PostMessages would either be queued of never get processed.
In the end I solved it by the threads never sending the UI any messages other than to say they were finished. Instead they would update a shared object (using a Critical Section or some other thread safe method) and the UI would simply look at this every so often by using a timer.
The UI would disable the timer until its work was done, and thereby not get the a backlog of messages to process.
On one of my PCs, an older, slower one, this has allowed me to run far more threads without getting any lock ups...
This may or may not be related to what you're experiencing. But the nature of your problem sounds similar to mine. Ironically, ImageEn's considerable performance improvement in the last release makes this sort of problem more likely - the threads may now be producing thumbnails faster than the UI can display them...
Andy |
| Bernhard |
Posted - Jun 30 2020 : 06:27:01
Hi Nigel
Thanks for the offer! Unfortunately, I currently only have c ++ builder installed and cannot do anything with pas files. If I have a little more time again, I will install my old delphi-ide on another system and then I will contact you again.
Greetings
Bernhard |
| xequte |
Posted - Jun 22 2020 : 17:28:44
Hi Bernhard
I did a comparison between iemview.pas 8.7.6 and 9.0.0. I couldn't find a smoking gun, but there are some big changes that we could disable to narrow down a cause (filtering, TImageEnView updating, etc).
If you want to pursue it, I can send you an updated version of iemview.pas.
Nigel
Xequte Software
www.imageen.com
|
| Bernhard |
Posted - Jun 22 2020 : 04:04:29
Hi Nigel,
The only difference is that they run Adobe Apps with all background services that Adobe installs and uses. Unfortunately, I need both Adobe and my own program on the same machine.
After the old Delphi program worked, I tryed something else: I uninstalled the new ImageEN and installed the old ImageEN version 8.7.6. Now my C++ program seems to be a little bit slower, but it runs on all machines without problems. So I will no longer upgrade, but will continue to use the old version, even if it does not have all the functions of the new version.
Many regards
Bernhard |
| xequte |
Posted - Jun 21 2020 : 16:16:51
Hi Bernhard
Sorry, I'm not really sure what to suggest. We've not had any other reports of TImageEnMView freezes. Is there something else in common on the machines that it occurs?
Nigel
Xequte Software
www.imageen.com
|
| Bernhard |
Posted - Jun 21 2020 : 06:44:59
Hi Nigel,
I used to program in delphi and only recently switched to C ++. Now I have brought out an old program written in delphi, which also uses ImageENMView. This runs easily on computers with Adobe apps, I see no problems. Apparently the problem arose with the further development of the ImageENMView class. |
| xequte |
Posted - Jun 16 2020 : 00:45:50
Hi Bernhard
Sorry the documentation is not adequate there. HighlightedPixel has no effect unless TImageEnView.DisplayGridKind = iedgPixelGrid and the image is zoomed in enough for the pixel grid to be visible (e.g. 500%):
https://www.imageen.com/help/TImageEnView.DisplayGridKind.html
I will improve the documentation for 9.1.1.
Nigel
Xequte Software
www.imageen.com
|
| Bernhard |
Posted - Jun 14 2020 : 10:35:10
Hi Nigel
I have now tested the demo on other machines and found that the program causes problems if Adobe Creative Cloud is also installed on the computer. Even if it starts without errors, it will be very slow on these machines, although they are the fastest available to me. It starts much faster on slower machines without Adobe Creative Cloud. And I've never seen the error on machines without Adobe Creative Cloud.
I don't know how this is linked together. Adobe may turn system calls so that they run via its own DLLs, which is known to cause problems. I cannot investigate this further with my resources and my limited knowledge of the Windows API.
But finally another question: I tested the following lines of code:
TPoint tp;
tp.X = 200;
tp.y = 200;
View1-> HighlightedPixel = tp;
View1-> Update ();
If I understood everything correctly, then the image pixel would have to be framed. But nothing changes on the screen. Am I doing something wrong?
Many Regards
Bernhard |
| Bernhard |
Posted - Jun 11 2020 : 18:09:55
Hi Nigel,
the whole application locks, i can no longer interact with it. Only a hard termination ist possible. Therefor I thought it was a deadlock between threads.
Typical scenario: I start the program, everything works, I do some work without any problems and then end the program. Then I start it again, the window appears, but TreeView and FolderView only show white areas. Nothing happens even after two or three hours. Windows task manager shows that there is no activity. I have to shut down it on the hard way. The next time it starts, it sometimes works again, sometimes it doesn't. Sometimes I can only start the program normally again when I delete its registry entries.
I can not determine a dependency on the image types, it does not matter which file types are in the folder.
Many Regards
Bernhard |
| xequte |
Posted - Jun 11 2020 : 16:14:35
Hi Bernhard
When you say "freezing" do you mean the whole application locks up and you cannot interact with it in any way, or do you mean the TImageEnMView stops updating its thumbnails?
Does it only happen with specific images or image types? I.e. is it fine on a folder of PNG files, but fails with PSD files, for example?
Nigel
Xequte Software
www.imageen.com
|
| Bernhard |
Posted - Jun 11 2020 : 06:38:13
Hi Nigel
Sure, the real cause seems to be producing and loading the thumbnails in multiple threads. The following facts show that.
I have expanded the program with RichEdit and ImagenENMView is now filled when I press a button. The button triggers some lines of code:
// -------------------------------------------------------------
// nextFolder is a String containing the folder path
1 RichEdit->Lines->Add("MView set to: " + nextFolder);
2 RichEdit->Update();
3 Application->ProcessMessages();
4 MView->Folder = nextFolder;
5 RichEdit_Main->Lines->Add("New MView folder: " + MView->Folder);
If the program freezes, line 5 is no longer reached. So it gets stuck when ImageENMView is filled with thumbnails. And as I wrote earlier: If I set StoreType to ietNormal, there are no problems.
And if I set ThreadPoolSize to Zero, the problem goes away too.
As far as I have determined so far, the problem does not occur on all computers. So there seems to be a strange interaction between the IEMView threads and Windows 10.
I hope that I can test the program in the next few days on additional machines with different configurations. But after that it becomes difficult for me because I have too little experience with the Windows API.
Many Regards
Bernhard |
| xequte |
Posted - Jun 10 2020 : 16:40:46
Hi Bernhard
Yes, we tried a lot of different scenarios but did not see the issue. Maybe the TIEFolderTree is a red herring. Perhaps there is some failure when loading the thumbnails??
Nigel
Xequte Software
www.imageen.com
|
| Bernhard |
Posted - Jun 10 2020 : 03:47:07
Hi Nigel,
Thank you for testing. This is a strange thing!
Did you change the window size and the treeview width with the splitter, quit the program and restart? Or selected another folder with multiple images, quit and restart? These are the typical situations in which the program freezes.
If I set Threadpoolsize to 0, the problem is gone. So it may be a deadlock. However, the program then becomes slow in typical applications with a relatively large number of Photoshop files in a folder.
Is it because of the configuration of the OS? I will test on more machines and hope that will bring more insights.
Many Regards
Bernhard |
| xequte |
Posted - Jun 09 2020 : 18:03:25
Hi Bernhard
Hmmm, I was not able to reproduce the crash on any of our test machines which makes the issue very difficult to narrow down.
Both components use threads. Try changing these options:
TIEFolderTree.UpdateAutomatically := False;
TImageEnFolderMView.AutoRefresh := False;
TImageEnFolderMView.ThreadPoolSize := 0;
By default, TImageEnMView does not store any content between sessions, unless you have enabled TImageEnMView.DiskCache.Enabled. Also, if you use TImageEnMView.EnableLoadExplorerThumbnails then Windows Explorer may cache thumbnails.
Nigel
Xequte Software
www.imageen.com
|
| Bernhard |
Posted - Jun 09 2020 : 08:46:58
Hi Nigel,
Here is additional information from the windows event log:
Das Programm TestMView.exe Version 1.0.0.0 hat die Interaktion mit Windows beendet und wurde geschlossen. Überprüfen Sie den Problemverlauf in der Systemsteuerung "Sicherheit und Wartung", um nach weiteren Informationen zum Problem zu suchen.
Prozess-ID: 26ec
Startzeit: 01d63e576e30d4ff
Beendigungszeit: 5
Anwendungspfad: C:\Program Files (x86)\BeWie\TestMView.exe
Bericht-ID: 8456766b-21d2-436e-846b-424490d3dc3f
Vollständiger Name des fehlerhaften Pakets:
Relative Anwendungs-ID des fehlerhaften Pakets:
Absturztyp: Cross-thread
Could it be a deadlock or another problem between simulaneously running threads? That would match the unpredictable error behavior.
Many Regards
Bernhard
|
| Bernhard |
Posted - Jun 09 2020 : 05:54:06
Hi Nigel
Thank you for quick answer!
I will send you a folder with an renamed exe file and a picture collection.
The error is not exactly reproducible. It rarely occurs on the computer on which C + Builder and ImageEn packages are installed. Often on other computers, but not always. On a system with a Celeron processor and small core memory, the program runs slower but surprisingly error-free. Therefore, it can be a coincidence that it works better on the C ++ Builder system, maybe other factors play a role.
Delays seems to change something. If I put a ShowMessage() at the beginning of the FormShow event handler, the program then almost always runs reliably. But if I delay the initialization with a timer, it doesn't help.
There are obviously other factors that play a role. For example, the size and number of image files in the selected folder. Or if I change the folder and select a folder on another drive, the error rate at the start of the next session seems to be increased. If I change the width of the TreeView, the error occurs mostly in the following session.
Do the ImageENView components themselves store information (ie. about the thumbnails) on the hard disk or in the registry, which are then evaluated in the next session?
Many Regards
Bernhard |
| xequte |
Posted - Jun 08 2020 : 22:33:07
Hi Bernhard
I don't see a crash with your demo here. Are there any steps I need to take?
Do any changes you make to initialization make any difference? e.g. deferring setting the TIEFolderTree folder or AttachedMView properties?
Can you send me your demo exe too (you'll need to rename its file extensions to something like .notexe).
Nigel
Xequte Software
www.imageen.com
|
| Bernhard |
Posted - Jun 07 2020 : 07:45:25
Hi Nigel,
now I have a simple demo, which demonstrates the problem.
There seems to be some interaction between the ImageEN classes during initialization that I don't understand.
Can I send you a zip file with the demo and the project code? Where does it have to send to?
Many Regards
Bernhard |
| Bernhard |
Posted - Jun 05 2020 : 03:37:58
Hi Nigel!
I wrote a simple example and it worked perfectly. My much more complex program still shows the error. Apparently there are other factors involved in the occurrence of the error. I have to do some research, if I know more, I'll get back to you.
Many regards
Bernhard |
Search
