RunRev LiveCode versions

v5.0 [Oct 11, 2011]
LiveCode 5 is the most advanced version of LiveCode yet. Read on to see how the new features of LiveCode 5 complement the already hugely popular LiveCode platform to bring you the quickest, easiest and most powerful cross platform development solution on the market.
Engine Changes
Pixel Perfect Intersect (5.0.0)
The intersect function has been updated to take an extra optional parameter:
intersect(object, object, [threshold])
The new method parameter can be one of the following:
• alpha value - An integer between 0 and 255 which specifies a threshold that the alpha value
of each pixel must be greater than or equal to in order to be counted during calculation of the
intersect.
• 'bounds': Specifies that the intersect should be calculated using the rects of the two objects.
This is the default method.
• 'pixels': Specifies the intersect should be calculated using the visible pixels of the object.
Graphics Architecture Improvements (5.0.0)
For 5.0.0, the graphics architecture has underwent a significant overhaul. In particular, the point at
which the engine redraws has been cleaned up and a new accelerated mode has been introduced.
Redraw Changes
The method which the engine uses to track and apply redraws has been improved. If no lock
screen is in effect, then any redraws will be flushed after each and every command has finished
executing.
If lock screen is in effect, then redraws will be flushed after the screen is completely unlocked -
either through a final unlock screen or when control returns to the event dispatch loop (which ever
happens first).
Additionally, redraws will be flushed after engine-triggered updates (e.g. moves resulting from the
move command, or gif animation).
Visual Effect Changes
If you wish to apply a visual effect at the point of an 'unlock screen' you must use:
lock screen for visual effect [in rect]
You must now tell the engine you intend to use a visual effect to display the changes.
Accelerated Rendering
A new 'accelerated rendering' feature is now available and can be used on a per-stack basis. This
optional rendering approach caches the visual appearance of objects, reducing the act of rendering
to compositing images together.
The accelerated rendering feature is controlled with the following stack properties:
• the compositorType
• the compositorCacheLimit
• the compositorTileSize
The compositor properties should be configured in preOpenStack or preOpenCard - they are not
persistent (not saved into the stackfile).
compositorType
set the compositorType of stack "my stack" to "none|software|coregraphics|opengl"
The compositorType determines what back-end to use for compositing the cached content. It can
be one of the following:
• empty (or 'none') - do not use accelerated rendering (the default).
• 'software' - use the built-in engine blending functions to composite (the same the engine uses
for inks)
• 'coregraphics' - use CoreGraphics to composite (Mac / iOS only)
• 'opengl' - use OpenGL to composite (iOS only)
compositorCacheLimit
set the compositorCacheLimit of stack "my stack" to 16 * 1024 * 1024
The compositorCacheLimit determines the maximum number of bytes the engine should use to
cache content for the stack. If the limit is not big enough to render the stack, accelerated rendering
will not be used and the default rendering mode will be used.
compositorTileSize
set the compositorTileSize of stack "my stack" to 16|32|64|128|256
The compositorTileSize determines how big the fragments of object images it caches should be. It
must be a power-of-two between 16 and 256 inclusive (i.e. 16, 32, 64, 128 or 256).
layerMode
The engine determines what to cache based on the value of the per-object layerMode property.
10
5.0.x Release Notes – Revision 7 – 2011-10-10
set the layerMode of group "my group" to "static|dynamic"
This property is (currently) one of:
• 'static' : the object will not be cached individually and only as part of the background
whenever possible.
• 'dynamic' : the object will be cached independently from all others.
• 'scrolling': applies to groups only and is used where the group contains contents to scroll.
In general, any objects which do not move/resize/change or do so very rarely should be set to be
'static'; and any object which moves/changes/resizes frequently (i.e. every frame) should be set to
'dynamic'. In particular, the only cost involved in moving a dynamic object is that of re-compositing
the scene - which is vastly cheaper (computationally) than redrawing.
The 'scrolling' layerMode can be used to good effect to cache scrolling group content. If a group is
completely unadorned (no border, no scrollbars), then the engine will take the bounds of the group
to be that of its contained objects and clip the rendering of those objects to the rect. In particular, it
will be the unclipped content that is cached - thus eliminating redraw overhead for scrolling.
Notes
The accelerated rendering mode only looks at top-level objects to determine what to cache - objects
within groups are always rendered as part of their (top-level) ancestor group.
Accelerated rendering comes with some restrictions:
• Bitmap effects which use the multiply and color dodge blend modes will not work correctly
on top-level objects.
• Only 'blendSrcOver' and the image processing blend inks will work on top-level objects.
• 'opengl' mode does not support any inks apart from blendSrcOver on top-level objects.
• Using an ink other than 'blendSrcOver' on a top-level object will implicitly make it use
'dynamic' layerMode
In general, to ensure the fastest possible redraw speed, note the following:
• Minimize top-level objects. The engine processes all top-level objects each redraw, therefore
if you have invisible objects and resources that are never directly displayed place them all in
an invisible group on the card.
• Only change object properties when necessary. Changes to many object properties will
result in the object requiring an update, therefore minimize such changes.
• Update all objects together. The screen is flushed after every command that caused an
update to be requested therefore try to update all objects on a card simultaneously within a
lock/unlock screen pair.
• Use opaque unadorned groups to aggregate objects. The engine is able to eliminate a good
proportion of content that is displayed behind opaque unadorned groups, so if you have a
number of controls which (together) cover a rectangular region, place them in an opaque
group.