lock screen

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

lock screen

Lars Brehmer
Thanks for responses.  I saw the debug mode note, but I am not in  
debug mode and it's both the IDE and the standalone.  Here's where  
the flicker occurs:

1.  lock screen
      go stack "abc"
      go stack "cde" -- a smaller stack that is now in front of  
"abc," all other open stacks behind that.
      insert after.......--
      unlock screen -- you clearly see a white flash of stack "abc" ,  
then "abc" goes to it's correct appearance, then "cde" appears. I't  
as if the
      end mouseUp
      screen was never locked and unlocked.  At this point data is  
entered into a field on "cde"

2.  lock screen
      go invisible stack "ghi"
      copy contents of various fields on ''ghi" into fields on "abc"
      close stack "cde"
      close stack "ghi"
      open stack "jkl"
      insert after...etc
      unlock screen
      end mouseUp -- now it looks just like after the first lock  
screen, except "jkl" has replaced "cde" - however the various steps  
flash white       even  though the screen was locked while this took  
place!

3.  lock screen
      close stack "jkl"
      palette stack "abc"
      unlock screen
      end mouseUp -- this time no white flash but "abc" vanishes  
briefly and reappears in palette mode.  This one I can live with  
because there is no white flash, but what did the lock screen  
supposedly do?

4.  (this one is the least important because it is rarely, if ever at  
all, used, but I am trying to understand this lock screen thing.)
      Screen is as it is after 3 with "abc" in palette mode.
      lock screen
     topLevel stack "abc"
     go stack "cde" --in one case
     go stack "jki" -- the the other case
     unlock screen
     end mouseUp -- as "abc' goes from palette to topLevel, is  
briefly disappers and reappears with very, very slight flash.  Again,  
buffer is always checked in the inspector.

As I said yesterday, I conquered the same problem eslwhere by  
locating the stacks at -5000,-5000, making the changes and then  
putting the stacks at their correct locations, but this hasn't worked  
for the above, still lots of flashes going on on the screen.

from the docs:

A handler may need to open a stack and then close it before the  
handler is completed, or to move or change the appearance of a number  
of objects on the screen. If the screen is locked before these  
changes occur, the user does not see the changes happen on screen.  
Locking the screen can prevent user confusion or unsightly screen  
flashing. It also increases the speed of the handler, since  
Revolution does not have to redraw all the intermediate states of the  
screen.

Well, this is not happeneing here!

Cheers,

Lars




 
     
_______________________________________________
use-revolution mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
Reply | Threaded
Open this post in threaded view
|

Re: lock screen

ScottR
Recently, Lars Brehmer  wrote:

> from the docs:
>
> A handler may need to open a stack and then close it before the
> handler is completed, or to move or change the appearance of a number
> of objects on the screen. If the screen is locked before these
> changes occur, the user does not see the changes happen on screen.
> Locking the screen can prevent user confusion or unsightly screen
> flashing. It also increases the speed of the handler, since
> Revolution does not have to redraw all the intermediate states of the
> screen.
>
> Well, this is not happeneing here!

Hi Lars:

First of all, locking the screen doesn't affect the entire screen, it
affects the display of the contents of the default stack.  So if you lock
the screen, you can still move stacks around the screen and hide/show them,
but any updates to the *contents* of the default stack will not be visible
until the current handler ends you call unlock screen.  Lock screen is often
used when initializing a stack's objects, populating objects with content,
or employing a visual effect, such as:

 lock screen
 go next card
 unlock screen with visual dissolve

Locking screen will not get rid of any split-second flash that may be
visible before a stack is opened or made visible.

All this being said, in my own work I am encountering what I think is an
intermittent positioning bug where trying to set a stack's location to
something outside the screenRect will fail and a white flash flash equal to
the screen's rect will be briefly visible before the stack is drawn.  But I
haven't been able reproduce this consistently.

FWIW, the only way I know to get rid of any flash before displaying a stack
is to use Trevor DeVore's window external and making a stack transparent
before showing it.  I believe this only works on OSX currently.

Regards,

Scott Rossi
Creative Director
Tactile Media, Multimedia & Design
-----
E: [hidden email]
W: http://www.tactilemedia.com

_______________________________________________
use-revolution mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
Reply | Threaded
Open this post in threaded view
|

Re: lock screen

Klaus major-k
In reply to this post by Lars Brehmer
Hi Lars,

in additon to what Scott Rossi posted, you can always access data  
from stacks that are not open!
(Substacks or even stackfiles on the hard disk!)

Just use the exact and long descriptor.

Like:

...
put CR & fld "xyz" of cd abc" of stack "cde" after fld "bbc" of cd  
"mtv" of stack "acdc"
...

etc... you get the picture.

So maybe you can eliminate the "opening" of your stacks completely or  
at least
reduce to a minimum...


Regards

Klaus Major
[hidden email]
http://www.major-k.de

_______________________________________________
use-revolution mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution