forums.silverfrost.com

[mtwallet]

A number of clients have now referenced a problem with our application taking inordinate amounts of time to display dialogs etc.
At first these made no sense as the same actions on our PCs were immediate.
After much head scratching and testing we have isolated the problem to the length of time that certain PCs take to process the WINIO@ statements that contain %ib commands.
I have produced the following test program that takes timings during the code and writes them out at the end of the program.
We have complete access to a PC that experiences these issues until Wednesday pm due to the client wanting a solution to what is otherwise a problem that makes the use of our software untenable.
We have run a few tests today but have already run out of what else to do because it would appear to be clearly the processing of the WINIO@ statements. But until Wednesday any suggestions for testing will be welcome.
I have included the code except the Resources BITMAP entries as the "" entries will need replacing with bitmap file paths for your testing.

The following is the output from the test program (see below) first on a typical PC followed by one of the PCs experiencing the problem.
Typical timings output are (in seconds);
TMPSS1 = 'near 0'
TMPSS2 = 0.203
TMPSS3 = 0.344
TMPSS4 = 0.500
TMPSS5 = 0.562
Our clients PC posts the following values (in seconds);
TMPSS1 = 'near 0'
TMPSS2 = 43.84
TMPSS3 = 87.499
TMPSS4 = 130.015
TMPSS5 = 130.062
Our clients have high spec PCs that are brand new and if anything you would expect faster times rather than the 200 times slower that they are experiencing.

I am aware of the large number of icons in this example dialog but it does prove that the issue is relative to the number of %ib calls made and is as sequential across multiple dialogs as it is across one.
It would appear that the grouped %ibs are particularly affected.

Our standard application, on these PCs, is taking in the region of one to several minutes to load (up from just over a second on my PC) as we use %ib in our main window toolbars etc.

Any suggestions will be tested immediately. We are running out of time.

[mtwallet]

It would appear that my last post was not all saved.
This post contains the next segment that was not saved.

[mtwallet]

This should complete the code (problems with max characters per post)

[PaulLaidler]

It looks like ClearWin+ will be calling on the Windows API function LoadBitmap in order to load the bitmaps from the resource.

It is possible that LoadBitmap behaves differently for different operating systems, in particular if you run your 32bit application on a 64 bit machine and 64 bit operating system.

I am not familiar with the details, but I have seen suggestions on this forum that certain flags can be set in order to provide better 32bit compatibility.

Its a long shot but its the best I can suggest at the moment.

[mtwallet]

I presume the 'flags' that you mentioned pertain to the operating system?
Does anyone have any ideas what these 'flags' might be?

Further info that we have investigated along the lines that you mention;
1) Three of the problem PCs from different sites have a common element in that they were supplied with XP SP3 32 bit on machines built for Vista. The common hardware is Intel Core Duo CPUs.
2) We have already tried changing the Compatibility settings to 2000 but this changed nothing.
3) The other similar type Cad applications do not have this slowness problem.
4) The problem only appears with the %ib command and not with other similar commands e.g. %tb. Is this Loadbitmap API only relevant to %ib within Clearwin or do other commands use it? We would be willing to run specific tests between different commands that use the same API to test this idea.

[PaulLaidler]

The way that images are read from the resource is not unique to %ib but the only other obvious thing going on is the allocation of a small amount of memory. I cannot see anything else in the ClearWin+ code that might be sensitive to the OS.

Having said this, as another long shot you could try using the old memory model within salflibc.dll. If you are using the latest salflibc.dll then you can get back to the old memory model by setting the environment variable...


FTN95_NEW_MEMORY = FALSE

Conversely if you have an older (but not very old) version then you can try the new memory model by setting this variable to anything other then FALSE.

[lozzer]

Unfortunately, none of these suggestions has helped.

Is there any software which we could have to run on a client PC which we can use to work out exactly what is going on please?

We know that the problem is the result of the %ib call. We need some software which gives us the individual commands which are triggered by the use of this call and the timings for each element. Only then can we begin to understand what is going wrong.

As my colleague and I have mentioned several times, this is draining huge amounts of resource from our company at the moment and we are poised to react to any support which Silverfrost can offer.

My phone number is 01452 864244 if someone cares to call me.

Thanks.
_________________
Lozzer

[PaulLaidler]

Given time I can probably provide a salflibc.dll with a diagnostic facility. But I cannot do this immediately and the diagnostics will only take you to the next level of debugging.

There are other things you might consider.

1. What happens if you have fewer images?
2. What happens if you use one simple image at every position?
3. As a last resort, is it possible to use %tb instead?

[lozzer]

[PaulLaidler]

It has been suggested that the time is being lost in the process by which ClearWin+ creates grey images from the bitmaps.

If this is the case then an immediate work-around would be for me to provide a version that bypasses this process.

After that I could look at the efficiency of the process and/or provide a way for the user to supply the grey images.

[LitusSaxonicum]

Nigel,

I knew that %ib was slower than %tb, but have never seen it as slow as your experience.

I have a main program which can have the choice of three %ib toolbars options, or one %tb toolbar(s) option. The three %ib options correspond to the “coloured”, “flat” and normal styles. The %tb toolbars have an “Office 2003” look. The user can choose between the toolbar styles with a menu option, which is persistent between runs by means of an INI file setting. If the user chooses to swap, I close the main window (with DESTROY_WINDOW@ - for this you need the main window handle, and a “RESTART” code that is “TRUE” to redraw, or “FALSE” to exit the program) and then re-open it with the new settings. I found that the %ib options are slow. My fix for this was to redraw the initial “splash” screen so that the user can tell that something is happening. (You can fake this up with a progress bar – since it isn’t “the windows way” to keep starting and closing a program, then they’ll never cotton on if it occurs one time only). After all, many Windows programs start very slowly - Corel DRAW, MS Office and plenty of others. We just get spoilt by FTN95, as most things start quasi-instantly!

I agree with you that %ib handles the different Windows themes settings better than %tb. One way around this problem with %tb is to have your own “themes” in the program. Office 2007 does this, and at least has three themes – two of them them work well with the Blue and Silver themes in XP (and are named the same), Black presumably looks better with the Vista default. Mind you, redrawing all your icons with several backgrounds is a long-winded way to deal with the issue.

Why %tb buttons look so rubbish with some of the different Windows themes is that Clearwin draws them on a default background colour, that varies from theme to theme. Some of them won’t match your buttons well. Up to a point, you can overcome this by adding a %bm bitmap either before or after you set up the toolbars. Since the %tb buttons always come to the top, this %bm can be the right colour to match (or contrast) the %tb button backgrounds – it can be a “corporate colour” or whatever. Just draw it deep enough to fill the space below the menu bar where your toolbars appear. Mine is 3D style, which also helps to conceal the fact that it may not match well to the border of the main program window. More to the point, %tb buttons are spaced differently if the “Large fonts” setting is in effect (check that LOGPIXELSX and LOGPIXELSY in GetDeviceCaps are both 96 for the standard setting) – and so my background bitmap fills in the gaps so that the toolbars look like continuous ribbons. The background bitmaps also have stylish “ends” for the toolbar.

A problem with this approach is that you need enough background bitmap to cover the entire width of the Program Window. As my program starts up in full screen mode, I have had to cope with the user possibly having two 2560-pixel monitors (make the background bitmap 160 pixels wide, and repeat the %bm until you have enough ... 160 pixels multiplies to most screen widths). It doesn’t matter if you have too much width in the background bitmap(s).

If you want to see my examples, send me a private message with your e mail as I’ll need to enclose some image files.

%tb buttons don’t have mouseover sensitivity, which is also a bit of a problem if you want to detect that state.

The problem you report may not have anything to do with Clearwin. For example, Office 2007 programs start desperately slowly on some machines when started by clicking on a DOC or XLS file, and this is a conflict between SPOOLSV.EXE and a networked HP colour laser printer’s software. (They started fine if the program was selected first, and then you OPEN a file). This is a well-known problem that is difficult to resolve (although I had some success with PC Tools Registry Mechanic and removing surplus registry info, it was a serendipitous discovery that I got a fix). Your users' machines may have other program startup issues that they haven't found yet!

[lozzer]

Thank you for your comments and suggestions.

The problems have been tracked down to the Windows calls 'GetPixel' and 'SetPixel' which, for some reason run about 200 times slower on these computers. The common thread is that they are all new (or newish) computers which have been supplied as 'Downgrades' by the manufacturer and are installed with Windows XP Professional SP3. We put together a program in Delphi and it generated the same problems when we used the same calls.

I am not sure, but I think that they all have NVIDIA Graphics cards. The suggestion is that the problem lies with an inability of the OS to work efficiently with the latest Hardware, especailly when using the GetPixel and SetPixel calls.

We may well have to go back down the route of %tb, but we see this as a retrograde step and would involve a lot of work at this end, and as you say we'd lose the effects that Windows is able to provide when using %ib.
_________________
Lozzer

[PaulLaidler]

The image processing for %ib is significantly reduced when you apply the [coloured] option.

[PaulLaidler]

The latest position is that it does appear that there is a problem with certain NVIDEA graphics cards particularly with calls to GetPixel/SetPixel. Also NVidea have been notified and appear to be interested.

From the ClearWin+ side, it is possible for me to optimise the code for %ib in order to provide some improvement in response time but this does not address the core problem which seems to be in the graphics card.

Having worked out how to optimise the code for %ib, I will probably make this generally available in due course but probably not for the next release.

As a general rule, if programmers need optimum response times then ClearWin+ may not provide the best route. The aim with ClearWin+ is to provide something that is easy to program and is functional. For optimal performance you may need to invest a lot more time in the development process (probably not in Fortran).

[JohnHorspool]

Paul, I think you do yourself a disservice.

Myself and I suspect just about everyone else who use ClearWin+ do so because we are fortran programmers who wish to put a windows front end onto our programs without having to learn another language.

“….is easy to program and is functional” – ClearWin+ certainly achieves this !

Regarding performance, I have developed fairly sophisticated interfaces using ClearWin+ that perform just as well if not better than competing products. I have had some issues with OpenGL, but then this happens with other software as well.

I think most of us greatly appreciate the power of FTN95.