There is an example of using opaqueness (I think in the reaction examples) as a means of fading in and fading out windows that are opened, if the user has the correct graphics settings in GUI-Prefs.
In order to implement this, isn't it necessary to simply change the WA_Override_Opaquencess to TRUE and set a WA_FadeTime value when defining your window object?
By default, this will also make it to that iconifying and de-iconifying will also fade out/fade in.
See my code example here: http://www.os4coding.net/source/162
In the midst of this giant code mess, you will see on lines 366 and 367 that I have indeed set the window parameters as mentioned above.
My windows DO fade in and fade out...but the timing associated with the fade in and fade out is really slow. Please note that I have changed the fade_time in main() from 50 * 1000 to 50000 by definition. Otherwise, I would think my code should work at the same fade in and fade out speed as the opaqueness demo...rather than being much slower.
When I change WA_FadeTime in my window object definition to make it smaller (faster) then instead of being a gradual fade change, it is blocky - you see discrete interations that makes it look choppy.
What am I doing wrong? This should be an easy one...but I must have missed something. What I can find in autodocs doesn't explain much, and seems to indicate that if I decrease the WA_FadeTime my window fade should just be quicker, not blockier.
Any help would be appreciated!
Thank you!
So, I took the opaqueness example and removed everything except opening a window and putting up an EXIT button. I also kept the initial settings of the WA_Opaqueness, WA_Override_opaqueness and WA_FadeTime in the window structure.
It still works as expected.
This exact same code in my Amisafe program (i.e. simply changing the above 3 parameters in the window structure) works differently than in this example...with the exact same values.
Why does a multitabbed listbrowser open more slowly using the same opaqueness settings than a simple window with one button? Could it be that intuition sees 4 tabs as being separate windows somehow, and applies the opaqueness FadeTime to each window?
Anyone have any ideas? Does anyone out there have a complex window interface with multiple tabs and listbrowsers who can add the three lines to their window structure settings:
WA_Opaqueness, 255, /* Initial opaqueness on opening (0..255) */
WA_OverrideOpaqueness, TRUE, /* Override global settings? (TRUE|FALSE) */
WA_FadeTime, 500000, /* Duration of transition in microseconds */
and let me know how it works?
Thanks!
Use the example that comes with the sdk, and increase the number of object in it. Compile and look if you can replicate the same behaviour of your code.
Hello,
my tool NetSpeedometer, available from OS4 Depot, makes use of window fading, have a look at its source code which is included in the lha archive, I hope it helps.
Also keep in mind that window fading requires a hicolor or truecolor screen with layer compositing enabled to work.
Regards
@Amigablitter
Use the example that comes with the sdk, and increase the number of object in it. Compile and look if you can replicate the same behaviour of your code.
Yes, I'll end up having to do that.....just to prove I am not crazy!
@Massi
my tool NetSpeedometer, available from OS4 Depot, makes use of window fading
Ah, your latest version. Just got it from OS4 depot. Looks like you only set the WA_FadeTime and nothing else. I'll try that and see what it does.
Thanks!
Okay, figured it out!
I loaded your example - netspeedometer, and compiled it with your make file. Tested it, fading works fine.
I then loaded your source file using Codebench, set the same default compile parameters that I use for amisafe, and guess what! Netspeedometer faded painfully slowly just like amisafe.
I quickly realized your makefile had different settings than what I have been using. When compiling normally, the SIZE of the window determines how fast it fades in and out, in conjunction with the WA_FadeTime! The bigger the window, the slower it is to fade.
I added -mcrt=newlib to my amisafe make and compiled it using a shell and now fading works properly!
However, when I add mcrt-newlib to codebench and compile, it seems to be ignored! I am adding it to the compiler switches in codebench and it does not seem to work. What am I doing wrong?
Newlib is the default library now. so it is no more needed by gcc unless you are using an ancient SDK..
Okay...this gets worse....
I thought it was compiling under something other than newlib, but alas, I was wrong. What was happening was that any time I was running codebench to compile, my window would fade slowly. When I quit codebench and compiled from a shell, my window faded correctly, in .5 seconds.
I took the code for netspeedometer and added the lines:
WA_InnerWidth, 800, /* window width */
WA_InnerHeight, 400, /* window height */
right under the WA_FadeTime in the window structure. This simply makes the netspeedometer window open larger (800 x 600).
If I run netspeedometer while codebench is running, thef ade is slow, perhaps 7 or 8 seconds. If I quit codebench and run netspeedometer, the fade is correct, 0.5 seconds.
Similarly, if I run MUIOWB and it is using a lot of CPU time, then I start netspeedometer, the fade is slow (as long as the window is large). With the window small, as is its default size, the fade is marginally slower but not overly noticeable.
So the WA_FadeTime seems to be dependant not only on the size of the window faded, but the amount of CPU usage of other tasks as well! I verified this with the original opaque example in reaction.
Can anyone else confirm this bahavior? It may still be that I have some sort of bad library or graphics problem that nobody else has. Or it could be that truly the fade time for opaqueness is affected by the window size and CPU usage of other programs.
this could be possible.. however i don't know how it works internally but it is possible that is heavily CPU dependant. Try to increase the process priority to see if something change (just to test purpose..)
A little more investigation shows that it is not Codebench itself, nor MUIOWB that causes the window fade to slow to a crawl.
I can run codebench, and as long as I do not have an active edit window, the fade time works fine. Once I open an active editing window, the fade slows down by a factor of 10 or so.
Similarly with MUIOWB, there is usually not a problem between MUIOWB running and the fade timing. BUT - if MUIOWB is in one of those states where it is using a lot of CPU time (typically when you are editing something like a forum message post), THEN the fade slows to a crawl.
CinnamonWriter does not affect the fade timing at all.
Changing the priority has no effect!
Seems perhaps there is a problem somewhere with text/string handling. I might have, for example, an old string library or .mcc being used. I need to figure out what is common between MUIOWB and Codebench with regard to string handling to see if I can track this down further.
Any ideas?
For me, this one sounds more like a problem with the amount of graphics memory available on your machine´s gfx card.
E.g. Cinnamon Writer is using a Simple Refresh window, where other programs like CodeBench and even OWB try to use Smart Refresh windows. Latter ones need more gfx memory.
You should first try to get some betatester with a very big gfx card (128MB or more video ram) and let him/her test the things you did. If the fading effect works fine for him/her all the time, its a low memory condition and the fading delay is caused by heavy data transfer action from/to the gfx card memory.
If this is the case, there is nothing you could do against this within your code, besides accept the fact and concentrate on other things of importance for your project ;-)
Coder Insane-Software
www.insane-software.de
@whose
Yes, you are absolutely correct. After some more testing, I discovered that the problem is indeed when I am running low on graphics memory. Codebench and MUIOWB, as you pointed out, can both use quite a bit of video memory, having so many windows open at once. Once I get down to a mere few thousand bytes of graphics memory, the fade-in / fade-out slows tremendously. Closing windows and freeing graphics memory allows the fade to run in its normal speed.
As you pointed out, there is nothing to be done about that. It is not a coding problem but a hardware limitation.
I will make a note of it in my AmigaGuide for Amisafe...the demo of which I hope to release soon.
Thanks!
Im glad that I was able to help you. Its quite frustrating to search for an error one thinks he made himself, and in the end its not a coding error, but a system limitation...
Actually, not the hardware is the problem, but the "deprecated" gfx subsystem (deprecated but still modernized. Some more work and I bet it would be a quite decent gfx subsystem!).
Edit: Oh well, I read my post before this one again... bad grammar. Me kraut :-)
Coder Insane-Software
www.insane-software.de