picture fade out

[Norbert_B]

---

nrp wrote:

Based on the advice from Wiebe I made my splash screen fade out using transparency.

Oddly enough, on a batch of PCs that are clones of each other (identical HW, with the OS imaged from a single source) it fades out at different speeds. Some run far slower than the others, and I have no idea why!

---

I think your system is loaded very heavily and therefore you are observing threadswapping....

Norbert 

Message Edited by Norbert B on 02-12-2009 02:25 AM

[Wiebe@CARYA]

"nrp" <x@no.email> wrote in message
news:1233940207397-848548@exchange.ni.com...
> Based on the advice from Wiebe I made my splash screen fade out using
transparency.&nbsp;Oddly enough, on a batch of PCs that are clones of each
other (identical HW, with the OS imaged from a single source) it fades out
at different speeds. Some run far slower than the others, and I have no idea
why!

Probably, what Norbert said is what happening.

You might get better results using differential timing. Before starting the
loop, read out the current time (in seconds). In the while loop, read the
time again. Subtract the starttime from new time, and you have a "time
running" value. Correct it by some factor (for 5 seconds, devide by 5,
multiply by 100). Put this in the transparency property.

If you succeed, all the animations will go at the same speed. But this is
possible at the expence of the "smoothness" of the animation. So, you'll get
30 frames per second on a fast PC, but 10 fps on a slow one. Anything above
30 is percepted as smooth, so you need to put a wait of 1/30 sec, or 33 ms
in the loop.

Regards,

Wiebe.

[Yamaeda]

I tried using the Timed Loop structure with 40 ms frames for 25 fps. It still failed to keep the pace.

To me it looks like LabVIEWs window drawing sucks.

Resizing picture and window to roughly 400x200 makes it work good, but at 600x400 it's no chance.

/Y

[Norbert_B]

Please observe the CPU load of your system using the Windows Task Manager. If the load is around/above 80%, i'd say that this is normal behaviour. If the load is significantly lower (less than 50%), then this is something we have take a closer look into....

Norbert 

[Yamaeda]

The load is 50% (one processor fully occupied), which is the whole problem. It shouldn't take 2,2 GHz to calculate 1 windows transparacy.

(18% with my small picture which runs at correct speed)

With the big picture it's approx 800x600, ~500k pixels, @25 fps 12m pixels/sec.

1 core at 2,5 GHz with a superscalar architecture should do some 5 billion instructions/sec.

-----------------------------

417 instructions per pixel?

/Y

[Wiebe@CARYA]

A timed loop will not fix the problem. If the cycle takes longer then 25 ms,
the next one will execute immediately. The time delay will add up, and the
result will be that the cycles loop as fast as possible... This is exactly
the same as the original code, with a wait ms in a while loop. If the
execution takes longer then the wait ms time, the loop runs as fast as
possible.

I do agree, the graphic routines could be optimized a little more. But you
are trying to "alpha blend" 18 MBytes (600x400x3x25) per seconds, with the
overhead of the normal windowing functions. Are there other applications
that succeed in doing this?

Regards,

Wiebe.

[Ben]

I'd take a bit closer look to enusre both machines and software are actually identical.

Of particular interest is the graphics settings color depth, and graphic accelerator settings.

If you have another machine form that batch then try it out to make sure there is not an issue with that one machine. Who knows, maybe it has a bad cache.

Ben

[Wiebe@CARYA]

But the is a little bit more going on... LabVIEW might wait for vertical
retrace to happen. During this waiting, the (1) CPU might take 100%, since
the waiting is time critical. Also, the blending might be done by the GPU,
not the CPU. So this could bring bus speed and stuff like that into the
equation.

On my (much more modest) laptop (I think it's a 1.5 core 2 duo) I can run
the original VI at full screen (1280X800) with an image of 2800X2144 pixels
(at it's original resolution). Although LV is having problems compiling the
VI (after each change it takes about 10 seconds), the transparancy runs
without problems. With a scaled image (not at original size) it is also no
problem. Both CPU's use about 80% max, but on average I'd say about 30%.

Regards,

Wiebe.

[Neil.Pate]

It is possible the CPU is being used reasonably heavily, as I only put up the splash screen in the beginning while the application is initialising and a bit of data needs to be crunched through.

I kind of worked around the problem by deciding that anything more than 30 frames per second on the splash screen re-draw would be missed by most normal people, so I changed the transparency increment (i.e. instead of increasing the transparency by 1 every 5 milliseconds, I increased it by 5 every 20 milliseconds or something like that with the maths working out correctly to a 1/2 second fade in).

[Yamaeda]

Continuing on the Splash thing, i'm now trying to make it intelligent.

As such, i'm trying to check if my application has launched, and only then fade out.

There seems to be some labview problematic/bug connected with this, but and i'll get to that. 

I've managed to check if windows exists

I've managed to check if the window coordinates exists (thus being a visible window)

However, none of this works with LabVIEW windows!

Any ideas?

If you e.g. set the "get window refnum" to the title in Explorer you can get it to trigger when you select a folder and thus changes the window title, and it wont activate if the window is closed.

/Y