Revision history for KeyPgScreenlock


Revision [21125]

Last edited on 2016-03-13 10:25:19 by fxm [Formatting]

No Differences

Revision [20507]

Edited on 2016-02-10 16:08:18 by DkLwikki [Update link format]
Additions:
[[KeyPgDeclare|declare]] [[KeyPgSub|sub]] **Screenlock** ( )
Frame buffer memory may be freely accessed by using pointers (see [[KeyPgScreenptr|ScreenPtr]]) ONLY while the screen is locked. Primitive graphics statements (##[[KeyPgLinegraphics|Line]]##, ##[[KeyPgPset|PSet]]##, ##[[KeyPgDrawString|Draw String]]##, ...) may be used at any time.
The screen refresh remains locked until the use of ##[[KeyPgScreenunlock|Screenunlock]]## statement, which resumes it.
Calls to ##**Screenlock**## must be paired with a matching call to ##**[[KeyPgScreenunlock|Screenunlock]]**##. The graphics driver keeps track of how many times ##**Screenlock**## has been called using a counter. Only the first call to ##**Screenlock**## actually performs a locking operation. Subsequent calls to ##**Screenlock**## only increment the counter. Conversely, ##**[[KeyPgScreenunlock|Screenunlock]]**## only decrements the lock counter until it reaches zero at which time the actual unlock operation will be performed. Using ##[[KeyPgScreengraphics|Screen]]## or ##[[KeyPgScreenres|Screenres]]## will release all locks and set the lock counter back to zero before changing screen modes.
It is strongly recommended that the lock on a page be held for as short a time as possible. Only screen drawing should occur while the screen is locked, input/output and waiting must be avoided. In ""Win32"" and Linux the screen is locked by stopping the thread that processes also the OS' events. If the screen is kept locked for a long time the event queue could overflow and make the system unstable. When the induced lock time becomes too long, use preferably the method of double buffering (with ##[[KeyPgScreencopy|Screencopy]]##).
- Not available in the //[[CompilerOptlang|-lang qb]]// dialect unless referenced with the alias ##**""__Screenlock""**##.
- ##[[KeyPgScreengraphics|Screen (Graphics)]]## - Setting mode
- ##[[KeyPgScreenres|Screenres]]## - Setting mode
- ##[[KeyPgScreenunlock|Screenunlock]]##
- ##[[KeyPgScreenptr|Screenptr]]##
Deletions:
[[KeyPgDeclare declare]] [[KeyPgSub sub]] **Screenlock** ( )
Frame buffer memory may be freely accessed by using pointers (see [[KeyPgScreenptr ScreenPtr]]) ONLY while the screen is locked. Primitive graphics statements (##[[KeyPgLinegraphics Line]]##, ##[[KeyPgPset PSet]]##, ##[[KeyPgDrawString Draw String]]##, ...) may be used at any time.
The screen refresh remains locked until the use of ##[[KeyPgScreenunlock Screenunlock]]## statement, which resumes it.
Calls to ##**Screenlock**## must be paired with a matching call to ##**[[KeyPgScreenunlock Screenunlock]]**##. The graphics driver keeps track of how many times ##**Screenlock**## has been called using a counter. Only the first call to ##**Screenlock**## actually performs a locking operation. Subsequent calls to ##**Screenlock**## only increment the counter. Conversely, ##**[[KeyPgScreenunlock Screenunlock]]**## only decrements the lock counter until it reaches zero at which time the actual unlock operation will be performed. Using ##[[KeyPgScreengraphics Screen]]## or ##[[KeyPgScreenres Screenres]]## will release all locks and set the lock counter back to zero before changing screen modes.
It is strongly recommended that the lock on a page be held for as short a time as possible. Only screen drawing should occur while the screen is locked, input/output and waiting must be avoided. In ""Win32"" and Linux the screen is locked by stopping the thread that processes also the OS' events. If the screen is kept locked for a long time the event queue could overflow and make the system unstable. When the induced lock time becomes too long, use preferably the method of double buffering (with ##[[KeyPgScreencopy Screencopy]]##).
- Not available in the //[[CompilerOptlang -lang qb]]// dialect unless referenced with the alias ##**""__Screenlock""**##.
- ##[[KeyPgScreengraphics Screen (Graphics)]]## - Setting mode
- ##[[KeyPgScreenres Screenres]]## - Setting mode
- ##[[KeyPgScreenunlock Screenunlock]]##
- ##[[KeyPgScreenptr Screenptr]]##


Revision [16344]

Edited on 2012-09-16 10:48:48 by Chris319 [Update link format]
Additions:
Locks the working page's frame buffer
All of ""FreeBASIC's"" Graphics Library functions draw to a frame buffer and an automatic routine copies the frame buffer to the actual screen memory at each draw. If the user program does a lot of drawing, the automatic refreshes may take a significant amount of time.
Frame buffer memory may be freely accessed by using pointers (see [[KeyPgScreenptr ScreenPtr]]) ONLY while the screen is locked. Primitive graphics statements (##[[KeyPgLinegraphics Line]]##, ##[[KeyPgPset PSet]]##, ##[[KeyPgDrawString Draw String]]##, ...) may be used at any time.
The automatic refresh takes place only in the visible page of the frame buffer. ##**Screenlock**## has no effect when drawing to pages other than the visible one.
Deletions:
Locks the working page's framebuffer
All of ""FreeBASIC's"" Graphics Library functions draw to a framebuffer and an automatic routine copies the framebuffer to the actual screen memory at each draw. If the user program does a lot of drawing, the automatic refreshes may take a significant amount of time.
Framebuffer memory may be freely accessed by using pointers (see [[KeyPgScreenptr ScreenPtr]]) ONLY while the screen is locked. Primitive graphics statements (##[[KeyPgLinegraphics Line]]##, ##[[KeyPgPset PSet]]##, ##[[KeyPgDrawString Draw String]]##, ...) may be used at any time.
The automatic refresh takes place only in the visible page of the framebuffer. ##**Screenlock**## has no effect when drawing to pages other than the visible one.


Revision [15338]

Edited on 2011-10-03 06:16:14 by FxMwikki [Comment about an alternative method (double buffering) when the screen lock time is too long]
Additions:
It is strongly recommended that the lock on a page be held for as short a time as possible. Only screen drawing should occur while the screen is locked, input/output and waiting must be avoided. In ""Win32"" and Linux the screen is locked by stopping the thread that processes also the OS' events. If the screen is kept locked for a long time the event queue could overflow and make the system unstable. When the induced lock time becomes too long, use preferably the method of double buffering (with ##[[KeyPgScreencopy Screencopy]]##).
Deletions:
It is strongly recommended that the lock on a page be held for as short a time as possible. Only screen drawing should occur while the screen is locked, input/output and waiting must be avoided. In ""Win32"" and Linux the screen is locked by stopping the thread that processes also the OS' events. If the screen is kept locked for a long time the event queue could overflow and make the system unstable. When the induced lock time becomes too long, use preferably the method of double buffering (##[[KeyPgScreencopy Screencopy]]##).


Revision [15337]

Edited on 2011-10-03 06:11:08 by FxMwikki [Addition of comment about an alternative method (double buffering) when the screen lock time is too ]
Additions:
It is strongly recommended that the lock on a page be held for as short a time as possible. Only screen drawing should occur while the screen is locked, input/output and waiting must be avoided. In ""Win32"" and Linux the screen is locked by stopping the thread that processes also the OS' events. If the screen is kept locked for a long time the event queue could overflow and make the system unstable. When the induced lock time becomes too long, use preferably the method of double buffering (##[[KeyPgScreencopy Screencopy]]##).
Deletions:
It is strongly recommended that the lock on a page be held for as short a time as possible. Only screen drawing should occur while the screen is locked, input/output and waiting must be avoided. In ""Win32"" and Linux the screen is locked by stopping the thread that processes also the OS' events. If the screen is kept locked for a long time the event queue could overflow and make the system unstable.


Revision [14558]

Edited on 2010-01-08 22:34:41 by DoS386 [locked the mouse]
Additions:
{{fbdoc item="target"}}
- In DOS, the mouse arrow does not react to mouse movements while the screen is locked


Revision [13723]

Edited on 2008-09-14 09:34:57 by JeffMarshall [name case fixup]
Additions:
Framebuffer memory may be freely accessed by using pointers (see [[KeyPgScreenptr ScreenPtr]]) ONLY while the screen is locked. Primitive graphics statements (##[[KeyPgLinegraphics Line]]##, ##[[KeyPgPset PSet]]##, ##[[KeyPgDrawString Draw String]]##, ...) may be used at any time.
Deletions:
Framebuffer memory may be freely accessed by using pointers (see [[KeyPgScreenptr ScreenPtr]]) ONLY while the screen is locked. Primitive graphics statements (##[[KeyPgLineGraphics Line]]##, ##[[KeyPgPset PSet]]##, ##[[KeyPgDrawString Draw String]]##, ...) may be used at any time.


Revision [13709]

Edited on 2008-09-09 12:37:58 by CountingPine [Thanks, KristopherWindsor]
Additions:
All of ""FreeBASIC's"" Graphics Library functions draw to a framebuffer and an automatic routine copies the framebuffer to the actual screen memory at each draw. If the user program does a lot of drawing, the automatic refreshes may take a significant amount of time.
Framebuffer memory may be freely accessed by using pointers (see [[KeyPgScreenptr ScreenPtr]]) ONLY while the screen is locked. Primitive graphics statements (##[[KeyPgLineGraphics Line]]##, ##[[KeyPgPset PSet]]##, ##[[KeyPgDrawString Draw String]]##, ...) may be used at any time.
It is strongly recommended that the lock on a page be held for as short a time as possible. Only screen drawing should occur while the screen is locked, input/output and waiting must be avoided. In ""Win32"" and Linux the screen is locked by stopping the thread that processes also the OS' events. If the screen is kept locked for a long time the event queue could overflow and make the system unstable.
{{fbdoc item="filename" value="examples/manual/gfx/screenlock.bas"}}%%(freebasic)
'' Draws a circle on-screen at the mouse cursor
'free up CPU time
- New to ""FreeBASIC""
Deletions:
All FreeBASIC's Graphics Library functions draw to a framebuffer and an automatic routine copies the framebuffer to the actual screen memory at each draw. If the user program does a lot of drawing, the automatic refreshes may take a significant amount of time.
Framebuffer memory may be freely accessed by using pointers (see [[KeyPgScreenptr ScreenPtr]]) ONLY while the screen is locked. Primitive graphics statements (LINE, PSET, DRAW STRING,...) may be used at any time.
It is strongly recommended that the lock on a page be held for as short a time as possible. Only screen drawing should occur while the screen is locked, input/output and waiting must be avoided. In Win32 and Linux the screen is locked by stopping the thread that processes also the OS' events. If the screen is kept locked for a long time the event queue could overflow and make the system unstable.
%%(freebasic)
'manage framerate
- New to FreeBASIC


Revision [13708]

Edited on 2008-09-09 01:14:54 by KristopherWindsor [Added an example. Needs to be linked to something in the /examples/ FB folder]
Additions:
%%(freebasic)
Dim As Integer mx, my
Dim As String key
Screenres 640, 480, 32
Do
'process
Getmouse(mx, my)
key = Inkey()

'draw
Screenlock()
Cls()
Circle (mx, my), 8, Rgb(255, 255, 255)
Screenunlock()

'manage framerate
Sleep(18, 1)
Loop Until key = Chr(27) Or key = Chr(255, 107)
%%
Deletions:
See ##[[KeyPgScreenptr Screenptr]]## example.


Revision [13705]

Edited on 2008-09-07 12:30:00 by JeffMarshall [updated info on nested screenlocks]
Additions:
Calls to ##**Screenlock**## must be paired with a matching call to ##**[[KeyPgScreenunlock Screenunlock]]**##. The graphics driver keeps track of how many times ##**Screenlock**## has been called using a counter. Only the first call to ##**Screenlock**## actually performs a locking operation. Subsequent calls to ##**Screenlock**## only increment the counter. Conversely, ##**[[KeyPgScreenunlock Screenunlock]]**## only decrements the lock counter until it reaches zero at which time the actual unlock operation will be performed. Using ##[[KeyPgScreengraphics Screen]]## or ##[[KeyPgScreenres Screenres]]## will release all locks and set the lock counter back to zero before changing screen modes.
Deletions:
While calls to ##**Screenlock**## should be paired with calls to ##**[[KeyPgScreenunlock Screenunlock]]**## , the program keeps track of its internal status and there is no danger about locking the screen twice in a row as only the first lock is performed.


Revision [13442]

The oldest known version of this page was created on 2008-06-04 04:14:40 by DoS386 [updated info on nested screenlocks]
Valid XHTML :: Valid CSS: :: Powered by WikkaWiki



sf.net phatcode