On Tuesday 22 April 2014 20:57:16 you wrote:

On 04/23/2014 11:26 AM, Greg Madden wrote:

...

Wheezy amd 64, TDE 3.5.13.2.

I use Gwenview to view .tiff files, these are Architectural D drawings scanned to .tiff. They range in size: 350K>1.1M.

The feature I kike about Gwenview as a viewer is I can view a directory full of tiff files and browse thru them using the toolbar.

The downside, it seems, is that after viewing about 10 or so files all 8gb of memory is used, all other apps have been swapped out so checking mail or any other task is slow ..actually the workstation becomes to slow to be productive.

Memory is not released between file views..is this normal? This is first app I have noticed using all memory so quickly..seems unusual.

Thanks

Greg I am using the pclos-remaster-TDE.(kde3.5.13) My system has 3Gb memory. I have opened both TB and FF. I opened Gwenview and browsed about 50 Pictures all jpg and around 300 to 600K. I have no memory problems as far as I see. TB works as always, and yes, FF seems to be slower, but nothing that annoys me

I have no tiff files to try . Try a reboot , if you didn't do already, and see ' if ' there is a difference

Hey its Linux, and a workstation, no reboots :-) To track memory usage open an xterm, use top or htop. I can watch the memory usage dynamically as I browse thru images with Gwenview, and starting, stoping other apps and vm's.

I tried browsing a folder of jpegs , I get the same results as you did.

This is something the tiff files do not do, memory usage increases until it is all gone..fairly quickly on some tiffs. The tiff format "structure was designed to be easily extendible", and can vary, though the files I get are from a service that scans drawings and supplies tiffs to members, should be typical.

On Wednesday 23 April 2014 00:17:48 you wrote:

...

This is something the tiff files do not do, memory usage increases until it is all gone..fairly quickly on some tiffs. The tiff format "structure was designed to be easily extendible", and can vary, though the files I get are from a service that scans drawings and supplies tiffs to members, should be typical.

Greg, this smells like a memory leak bug. If you can reproduce this on a regular basis, could you file a bug report in bugszilla? Please add steps to reproduce the problem and in case the problem only shows up with some particular images, please attach an example of pictures that can be used to debug it.

Thanks Michele

Thanks, filed, uploaded one typical tiff file.

On 04/25/2014 08:54 AM, Michele Calgaro wrote:

...

Thanks, filed, uploaded one typical tiff file. Peace, Greg

Thanks Greg, we will look at that sooner or later...... just be patient, it will be after v14.0.0 is out :)

Michele

---

To unsubscribe, e-mail: trinity-users-unsubscribe@lists.pearsoncomputing.net For additional commands, e-mail: trinity-users-help@lists.pearsoncomputing.net Read list messages on the web archive: http://trinity-users.pearsoncomputing.net/ Please remember not to top-post: http://trinity.pearsoncomputing.net/mailing_lists/#top-posting

Which will be ?? approx 1 month -- approx 2 months -- approx 3 months ? just asking, for reason I don't have a clue Thanks

...

Which will be ?? approx 1 month --  approx 2 months -- approx 3 months  ?

When it is ready?

We have a list of bugs to resolve before releasing v14.0.0. You can keep up with it at this link: http://bugs.pearsoncomputing.net/show_bug.cgi?id=2014

So far we have solved 42 bugs. There are 63 bugs remaining + 12 conditional ones (which probably will go into v14.0.0 nevertheless). This was done in about 5 or 6 weeks so far, so a little slower than initially thought.

Based on the number of bugs, I think it is realistic to say that *at least* 3 more months of development are needed, potentially more if some bugs prove to be nasty ones. It is difficult to make a more correct estimation, mainly because we do not know our workload for coming months, so we don't know how much time we have available for TDE. Anyhow the target has been defined and we are slowly moving towards it. So we will get there in the end :-)

Hope this gives you a good idea of where v14.0.0 is at the moment. Cheers Michele

...

Anyhow the target has been defined and we are slowly moving towards it. So we will get there in the end :-)

So we'll get it when it is ready - like Debian.

Basically yes, but the target is no longer floating :-)

If using TDE means using Wheezy (1) 1instead of Jessie (2), why then I'll use Wheezy instead of Jessie. ;-) :-)

Actually if you prefer to use Jessie instead of Wheezy, you can try the nightly builds of v14.0.0. They are quite stable and rarely something is broken. My system is Jessie, so I do all development there and haven't had any major problem in more than a year, except for the occasional FTBFS when a library gets updated.

Cheers Michele

I think 3 to 4 months to solve 62 bugs ( +12 ) is very reasonable , taken into consideration the limited manpower the project has.

It should be doable, but as said some bugs may take longer than others to be fixed. After those bugs are fixed, we will have a period of testing before the final release (probably a RC1 and RC2 at that time will be appropriate). As for further maintenance releases (v14.0.x) we will try to deliver every 3 months, regardless of the number of bugs fixed in between. Instead minor releases (v14.x.0) will take longer, perhaps once a year. All this is an approximation, nothing is fixed in stone ;-)

Also, I suppose it is OK with you to "copy&paste" your reply to others....>>outside the project !

No problem, go ahead. It is just an indication of what the project status is at the moment. Everything could change from one day to another, but it is good to have some sort of road map looking ahead.

Cheers Michele