Picture Control Quirks

[Justin Goeres]

Can anyone explain this?

A Picture Control that has been painted transparent has a different Erase First behavior in the context menu.

Regular picture control, dropped right off the palettes:

Note that the Erase First item is enabled, and checked by default.

But, if we use the paintbrush to paint the interior of the Picture Control transparent and then bring up the context menu again:

Note that now Erase First is checked and disabled so it cannot be unchecked.

But there's more. If you try to set the Erase First behavior programmatically, LabVIEW doesn't generate an error and seems to accept the setting, but the change isn't reflected in the context menu:

Attached VI: Download File:post-2992-1228161220.vi

It also appears that, regardless of the behavior shown, a Picture Control that's been painted transparent ignores all programmatic Erase First settings and behaves as though it's set to Always Erase. This, in turn, means that if you set a Picture Control's background to transparent, it will always tend to flicker as you draw more stuff to it, unless you take special precautions (like deferring panel updates).

Why does a transparent-background Picture Control behave differently from a Picture Control with an opaque background?

[orko]

I recall reading somewhere that LabVIEW doesn't store the "old" picture when it writes a new one with the "erase first" option unchecked. This makes sense, since you wouldn't want every picture to be stored historically in memory (this could be considered a leak), but instead just storing the "flattened" result of all writes.

This makes me wonder if LabVIEW is accomplishing the "Erase First" behavior by masking the unused bits of subsequent writes with the background on each write? If so, then masking with a transparent bit (0) would make all of the unused bits transparent, regardless of what was there before.

Just a wild stab... I'll be curious to see what NI says.

[Darren]

I ran into this exact issue a while back...I posted the CAR number I filed on the corresponding thread on the NI forums.

-D

[Rolf Kalbermatter]

QUOTE (Justin Goeres @ Dec 1 2008, 02:55 PM)

Why does a transparent-background Picture Control behave differently from a Picture Control with an opaque background?

The reason is obvious. Transparent means whatever is behind has to show through. The only way to do that is by letting the parent redraw itself and then redraw its own contents on top of it. This by definition is redraw first at all times.

There is no other way to achieve real transparency. You can see that issue also with other controls that are overlapping and set to have parts transparent. Transparency in any UI object is a very difficult thing to handle correctly AND with good performance.

There is sort of a bug in here in the property node that COULD return an error when you try to change it but not in any other way. I guess the property node just ignores the change of the property though, since there wasn't a readily available error code to return.

Rolf Kalbermatter