Hi,
IMHO this is going to flicker somewhat whatever you do, since you need
to erase the FixedText and the paint another one.
On the Mac you see this not because all drawing is double buffered; you
do the "flickering" stuff in the back buffer which then gets copied in a
single step when the mac comes around to update the actual window.
If you wanted to emulate this behavior on all platforms you could have
your own control that does this using a VitualDevice to prepare its text
and then only copy that to the window when the ::Paint method gets
called. But that is probably a bit overblown.
You could also simplify things by not having different FixedTexts but
using only one, calling SetText on that one FixedText when you need to
change the text. This will also flicker at least a little since here
also the window needs to get erased and then the new text drawn. But it
will save a lot of clip region operations (removing the FixedText from
the parents clip region and inserting the other one) which will gain
some performance.
If you have flickering already, do not use SetPaintTransparent and set a
normal background (like solid white for instance). Transparent painting
always causes the all parents up to the first opaque (not transparent)
parent to restore the view, so a lot more painting gets done until
finally the text can be drawn; transparent windows will cause more
flicker, not less.
Just my 2 cents, pl
On 1/18/11 9:51 AM, eric b wrote:
Hi,
I have refresh ( flickering ?) issue with FixedText controls in
Toolbox, but only on Windows and Linux. On Mac OS X, things are
perfect, no problem.
Specifications are :
Let's consider a rectangle (for instance, a button), in a toolbox object.
* when the mouse cursor rolls over on button, the
VCLEVENT_TOOLBOX_HIGHLIGHT is sent when entering in the button rectangle.
* when the mouse cursor goes out of the area, the
VCLEVENT_TOOLBOX_HIGHLIGHTOFF is sent.
Receive VCLEVENT_TOOLBOX_HIGHLIGHT triggers a aFixedText.Show()
Receive VCLEVENT_TOOLBOX_HIGHLIGHTOFF triggers all FixedText controls
to be hidden ( e.g. aFixedText.Hide() )
So when the mouse cursor is moved from left to right, we see the
following events occur :
VCLEVENT_TOOLBOX_HIGHLIGHT is catched, next is
VCLEVENT_TOOLBOX_HIGHLIGHTOFF ... VCLEVENT_TOOLBOX_HIGHLIGHT ... and
so on, alternatively.
The result is :
no text shown ... show fixed text1 .. hide all fixed text ... show
fixed text2 ... hide alll
The relevant code is :
IMPL_LINK( BackingWindow, DecoToolboxHdl, VclWindowEvent*, pEvent )
{
if( pEvent && pEvent->GetId() == VCLEVENT_TOOLBOX_HIGHLIGHT )
{
#ifdef DEBUG
fprintf(stdout, "Toolbox nItemId = %d \n",
maToolbox.GetHighlightItemId() );
#endif
switch ( maToolbox.GetHighlightItemId() )
{
case nItemId_Calc:
maCalcMessageText.Show();
break;
case nItemId_Draw:
maDrawMessageText.Show();
break;
case nItemId_Impress:
maImpressMessageText.Show();
break;
case nItemId_Info:
maOpenMessageText.Show();
break;
case nItemId_Writer:
maWriterMessageText.Show();
break;
case nItemId_Extensions:
case nItemId_Reg:
case nItemId_TplRep:
default:
break;
}
}
else if( pEvent && pEvent->GetId() == VCLEVENT_TOOLBOX_HIGHLIGHTOFF )
{
maCalcMessageText.Hide();
maDrawMessageText.Hide();
maImpressMessageText.Hide();
maOpenMessageText.Hide();
maWriterMessageText.Hide();
}
return 0;
}
The issue :
When moving the mouse cursor fastly between two buttons, sort of
flicker appear, probably caused by either performance issue, or
something missing in the code. In my mind, the term flicker, happens
to be the FixedText background who appears (just "flickering"), and
this causes a very bad user experience : most of children, play with
the show / hide startcenter feature naturaly ...
If this can help, at initialisation, I have used
SetPaintTransparent(), for every FixedText control, and tested Erase()
and several other methods since, to make the FixedText control
background transparent (means : no longer displayed). Unfortunaly,
nothing helped until now.
Is there something missing, or is the current solution plain wrong
(please tell me why), or is there a better implementation on Mac OS X
than elsewhere ? (double buffering or something issue on Linux, or
missing Invalidate somewhere or ... ? ). Other possibility : did I
implement the algo ( Show() / Hide() ) at too hight level, causing
performance issues ? But then, why Mac OS X fine in this case ?
The current workaround I had in mind was to use a timer: enter in a
rectangle triggers a timer (e.g 200 ms or a same magnitude value) .
The first time we roll over a button, the Timer starts. If ever other
VCL events are detected, until the timeout is reached, no way to hide
/ show again (using Timer::bIsActive() information ). This means,
there will be always a delay before a string appears, starting the
second time we roll over a button with the mouse cursor. But I
consider this solution as a workaround, and I ask here for something
better.
I'm not a native speaker, and my english is not precise, so feel free
to ask for further information.
Thanks in advance for any help !
Eric Bachard
--
<http://www.oracle.com/>
Philipp Lohmann | Software engineer
OracleOpen Office Development
ORACLE Deutschland B.V. & Co. KG | Nagelsweg 55 | 20097 Hamburg
ORACLE Deutschland B.V. & Co. KG
Hauptverwaltung: Riesstr. 25, D-80992 München
Registergericht: Amtsgericht München, HRA 95603
Komplementärin: ORACLE Deutschland Verwaltung B.V.
Rijnzathe 6, 3454PV De Meern, Niederlande
Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697
Geschäftsführer: Jürgen Kunz, Marcel van de Molen, Alexander van der Ven
<http://www.oracle.com/commitment>
Oracle is committed to developing practices and products that help
protect the environment
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@gsl.openoffice.org
For additional commands, e-mail: dev-h...@gsl.openoffice.org
