Recently we’ve noticed a bit of sluggishness creeping into the LiveCode engine, particularly when it comes to graphics. Over the last few weeks I’ve been working with Michael to investigate and put into action some ways to get the engine back up to speed and get your apps whizzing again.

Looking into this problem, we’ve identified one of the big contributing factors as the introduction of support for high-density displays – where previously an app on the iPhone may have covered an area of 320×480 pixels, on a device with a retina display it now covers 640×960 pixels – that’s 4 times the number of pixels that need to be drawn when updating the screen! This is even more noticeable on mobile devices, where the processing power can’t match that of the desktop.

So what can we do to speed things up a bit? One option is to go multi-threaded. A thread is a block of code that can be made to run independently of the main program. By splitting a task up into multiple threads, different tasks can be made to run concurrently rather than one after the other. Most modern processors have multiple cores – that is multiple separate CPUs that are each capable of running a single thread all at the same time. We can take advantage of this by splitting up the job of redrawing the screen into several smaller tasks, i.e. by splitting up the area that needs redrawing and giving each smaller area to a separate thread. This promises to deliver a pretty big speed-up when redrawing.

One other option that I’ve been working on involves making sure we don’t do more work when drawing than we need to.

There are many ways to try and make computer programs work faster. You can try to find inefficiencies in your code that make things slower than they need to be – perhaps you have a loop in which the same value is computed repeatedly, in which case it may be more efficient to compute that value once and store it in a variable to be referenced later. Another strategy is to make better use of the resources available – the example being the use of multi-threading discussed above. However, if you know a particular operation is going to take a long time maybe you can find a way to avoid doing it altogether, or as little as you can manage.

In recent years we introduced a couple of new graphical features that allow you to add color gradients to graphic objects and graphic effects to everything. These features both require a lot of computation to draw, and as such they can be the slowest to draw when updating the screen. We spent quite a lot of time and effort on making these as fast as possible, but even then they can slow things down considerably when the area they cover is large.

So let’s say you have a card with a nice gradient as the background. You click a button that performs some operation then updates the contents of a field and maybe toggles some other buttons on or off. If this all happens as a single operation then each of those objects affected will have to be redrawn at the same time. Whenever a change happens to an object that requires it to be redrawn (changing the color of a graphic, or updating the contents of a field for example), its enclosing rectangle will be added to the redraw region.

A region is a graphical programming object that collects together multiple rectangles as a single area and allows several useful operations to be performed on that region. You can add or exclude rectangles from the region, or combine that region with another. This makes them pretty useful for defining the areas of a scene that we need to redraw.

Once we know what areas of the window need redrawing the engine will then tell the windowing system (the part of the operating system responsible for handling windows) that we want to redraw, after which the engine will receive a message back telling which areas of the window to update. This allows the OS to have areas of the window redrawn if for instance another window is passed over ours.

Now we need to draw to the window in the area given to us by the OS. In order to prevent flickering as different objects are drawn we use double-buffering. This is a technique where an offscreen image (the buffer) is created into which we draw, after which the complete image is then drawn to the window, so only the end result of the redraw operation is seen.

How then do we reduce the amount of redrawing that gets done? Well, previously the engine would confine the drawing area to a rectangle by setting the clipping rect of the graphics context that is used to draw to the buffer. The old graphics context would only allow the clipping area to be set to a rectangle, so if the area being redrawn was composed of smaller rectangles with lots of space between them, there was no way to prevent those unneeded areas between from also being drawn into. By using the new graphics context introduced by the graphical refactor, and updating it to accept a region as the clipping area, we can now ensure that only those areas that need updating are redrawn, with those areas in between getting skipped over.

Going back to our example, we can see that previously a much larger area (the rectangle encompassing all the affected controls) would have been redrawn, whereas now only the much smaller individual areas covering the affected controls will be drawn. For a stack with an expensive (in terms of time needed to draw) background this provides a significant saving in the time spent updating the window.

This was a pretty satisfying job for me – I got to update some more of the older code in the engine, replacing lots of platform-specific region code with a single region object that could be used on all platforms – and one that was successful in improving the experience of users of LiveCode developed applications.

read more

HTML5 and now a Mobile LiveCode IDE I hear you all cry!…..well sort of 🙂

Before you continue reading this post, I have to make you aware that this is not a mobile IDE that we are working on in-house but a personal fun project (proof of concept) that I have started and like to dive into whenever I get a spare moment (which is very rarely).

There has been much discussion of a LiveCode IDE that runs on mobile devices. This would not only take the creation of LiveCode applications into the mobile space, but would also open up LiveCode to a whole new market.

So without further ado, I give you my LiveCode Mobile IDE!!! (Trumpets Please!)

Tada!

Now I know that my graphic design skills are nothing to shout home about, but all of that can come later. Getting the functionality done first is key.

So let me give you a brief overview of what I’ve accomplished so far:

• basic tools palette (buttons, fields and image objects)
• basic property inspector (name, label, visible & opaque properties)
• Ability to show and hide these palettes by clicking on relevant yellow sections
• Creation of control by dragging them from tools palette
• Move Controls after they have been placed
• Edit scripts of controls by long pressing the control
• Edit a field contents by double clicking control
• Works across supported platforms (minus server)

After I started scripting the above, I soon began to realise the sheer quantity of elements there are within the desktop IDE and what I have achieved so far is only the tip of the iceberg.

So let me explain how I accomplished some of this but please be gentle with my code as it can get quite unruly at points 😀

Palette Creation

The first step was creating both the tools and property inspector palettes. These are just grouped controls of graphics objects.  To show and hide the palettes, I simply applied a move command to show/hide them depending on their location. Below is the tools palette show/hide script

on mouseUp
if the loc of group "toolsPallete" is 54,360 then
move group "toolsPallete" to -36,360 in 100 milliseconds else
move group "toolsPallete" to 54,360 in 100 milliseconds
end if
end mouseUp

When working with the property inspector palette it knows which control to assign properties to via a global variable which contains the last selected control name. The name, label, visible & opaque properties of the control can then be assigned accordingly.

Creating Controls

Next is onto creating controls. There are various ways that this could be achieved, but I decided to go with a mouseDown on the card script. This meant that all scripts for this action are in one place. I then defined what happened during the mouseDown by checking if the mouse was within the rect of the tools palette via the mouseLoc function. The name of a created control is defined by the amount of pre-existing controls of that type currently present on the card.

local sMouseDown
global gControlName
-- creates controls from tools pallet group
on mouseDown
if the mouseLoc is within the rect of group "toolsPallet" then
put empty into gControlName
put true into sMouseDown
if the mouseloc is within the rect of graphic "buttonGraphic" then
lock screen
create button "button"
set the loc of it to the mouseLoc
set the name of it to (the short name of it && (the number of buttons of this card +1))
set the label of it to "button"
put the name of it into gControlName
set the script of gControlName to the cGrabMe of this stack
unlock screen
end if
if the mouseloc is within the rect of graphic "fieldGraphic" then
lock screen
create field "field"
set the loc of it to the mouseLoc
set the name of it to (the short name of it && (the number of fields of this card +1))
put the name of it into gControlName
set the backGroundColor of it to White
set the script of gControlName to the cFieldScript of this stack
unlock screen
end if
if the mouseloc is within the rect of graphic "imageGraphic" then
lock screen
create image "image"
set the loc of it to the mouseLoc
set the text it to the text of image "ic.png"
set the name of it to (the short name of it && (the number of images of this card +1))
put the name of it into gControlName
set the script of gControlName to the cGrabMe of this stack
unlock screen
end if
end if
end mouseDown
--allows created controls to be moved
on mouseMove
if sMouseDown is true then
if gControlName is not empty then
set the loc of gControlName to the mouseLoc
end if
end if
end mouseMove
--stops controls sticking to mouse loc
on mouseRelease
setInspector
put false into sMouseDown
end mouseRelease
on mouseUp
mouseRelease
end mouseUp
-- sets inspector values to control values
on setInspector
if gControlName is not empty then
put gControlName && "ID" && the id of gControlName into field "nameLabel" of group "inspectorGroup"
put the short name of gControlName into field "nameField" of group "inspectorGroup"
if "image" is not in gControlName then
put the label of gControlName into field "labelField" of group "inspectorGroup"
end if
end if
end setInspector
on updateScript pScript
set the script of gControlName to pScript
end updateScript

A few other things are happening on the card’s script.

• Setting the property inspector values when a control is created or when a control is moved
• Stop control sticking to the mouse position

Custom properties of the stack contain control scripts which deal with re-positioning the control and launching the script editor. The following is the script applied to a button:

global gControlName, gScript
local sMouseLocation
on mouseDown
put the mouseLoc into sMouseLocation
put the name of me into gControlName
setinspector
grab me
end mouseDown
on mouseStillDown
if the mouseLoc is sMouseLocation then
put the script of me into gScript
go to card "scriptEditor"
end if
end mouseStillDown

Script Editor

The script editor can be accessed by long pressing (mouseStillDown) on any create control. When a user does this, the script editor card is opened and the script of the control is shown.

You can then edit the script, hit the apply button and it takes you back to the main card where the control’s script should update automatically.

global gControlName, gScript
on mouseUp
put field "codeEditor" into tScript
go card "canvas"
send "updateScript tScript" to card "canvas"
end mouseUp

So there you have it, a very basic mobile IDE 🙂 . As I mentioned previously, there is still a lot of work to do and it will take some time for it to progress into more advance stages of development. (If there were only more hours in the day…)

I hope you enjoyed this post and for those who are interested, here is a link to the current version of the IDE. Please feel free to experiment with it and if you’re up for the challenge, add more features to it.

http://techsupport.on-rev.com/lcMobileEditor.zip

Let us know how you get on or if you have any other feedback in the comments below.

read more

With only 2 months to go until the Kick off of RunRevLive 2014 in San Diego, things are hotting up in the office with requests and interest, so I thought I would take a moment to answer your Top 10 Frequently Asked Questions…

Q.1: I booked a Premium / Budget Ticket – which nights are included in my overnight stay?  

A.1: In either Premium (Manchester Grand Hyatt) or Budget (The Embassy Suites) the Check In & Out days are the same. Check-In is Monday 1^st September with Check-Out on Friday 5^th September.  

Q.2: My travel In/Out of the San Diego requires me to stay an extra night(s), how do I book these please? 

A.2: Please book these directly though us, to ensure you do not need to change rooms and that you are included in our Preferential Rate & Group Booking Block. 

Please use the links below and select the multiple(s) of nights required. Once your Order has been confirmed, please email JoJo  to confirm required additional date(s): 

Embassy Suites:

https://livecode.com/store/conference/runrevlive14-budget-xtranight

Manchester Grand Hyatt:  

https://livecode.com/store/conference/runrevlive14-premium-xtranight 

Q.3: I booked Ticket only, but would now like to add Accommodation – is this possible? 

A.3: Why yes, of course! Please follow the steps as above and remember to confirm your Check-In & Check-Out dates by emailing JoJo.

Q.4: I am attending the Community Day but would like to stay overnight, is this possible? 

A.4: Again yes, of course – Please follow the steps in A.2 and all will be taken care of for you! 

Q.5: I am attending RunRevLive in San Diego, what is included in my Ticket? 

A.5: Whether you buy a Community Day Ticket or a 4-Day Pass, you can be sure of being well looked after. We start each day with Tea, Coffee, Juice & Snacks and keep you energised in between sessions with Morning & Afternoon Breaks as well as an informal Lunch.  

WiFi is available in the Conference area and we have both a dedicated Customer Services Representative and Conference Host to look after you and assist throughout. 

 We also have our Networking Evening on Tuesday 2^nd September, where you have the chance to meet with all the other Speakers and Attendees.. Plus (of course) the LiveCode Team. 

Q.6: Is the cost of WiFi included in the Hotel Rooms? 

A.6: For those of you staying at the Manchester Grand Hyatt, yes there is Complimentary WiFi in each Room booked with our Block Group Booking. 

If you are a guest at the Embassy Suites, we have negotiated a 50% Discount for all our Block Booked Attendees.  

Q.7: I have never been to San Diego, what is it like? 

 A.7: San Diego is the 8^th largest City in the USA and the 2^nd largest in California. Situated to the South of Los Angeles and adjacent to the Mexican Border, it as a warm and pleasant climate, with average September Temperature of Highs 77 & Lows 66 – That’s 25-19 Degrees C for us Europeans! 

San Diego International Airport is well serviced for both Domestic & International Flights and is only a 10 minute car journey away from the Conference Venue.

Q.8: If we’re not staying onsite, are there plenty of places to eat & drink? 

 A.8: Goodness yes. The ‘Gaslamp Quarter’ is a 16.5 block historical area in Downtown San Diego, which is a 5-10 minute walk from the front of the Manchester Grand Hyatt. Here you’ll find a selection of bars and eateries to suit all tastes and budgets. 

Wanted somewhere a little more on the water? Not to worry, Seaport Village is located directly to the back of the Hotel, running adjacent to the Harbour and Marina area. Offering a selection of Cafes and Restaurants, this area is also a perfect little shopping village, open from 10am – 10pm daily. Many of the local tours and attractions have a drop off / collection point here also.  

Q.9: I am thinking of bringing my Family or Partner with me. Is this possible and will they be bored whilst I attend the Conference sessions?  

A.9: Of course they are welcome! There is no additional cost for spouses sharing a room, however there may be if you decide to bring the whole family along. Not to worry, we have negotiated amazing discounted rates, so if you think you’d like to make this a mini-break, please email JoJo and she can help you plan your trip.

 As to will they be bored? Not. At. All. Please see my answers below to Questions 10! 

Q.10: I see there is “Free Time” on Friday afternoon and some evenings, any suggestions on what to do? 

A.10: This is one thing I loved about San Diego, the amount there is to do within the immediate vicinity. 

Want to pop over and look at the Old Town, Coronado *and* Balboa Park, but a little pushed for time? How about the Hop-On/Hop-Off Trolley Tour?  A great way to see the city and have your very own voiced guided tour. 

Fancy a ball game? PETCO Park houses the San Diego Padres and we’re sure there will be a game on whilst your in town!  

 Love Big Boats? How about the USS Midway Aircraft Carrier & Museum? Even better, this one is a 15 minute wander from the Conference venue along the Seaport Promenade. (There’s even a Pedi-Cab option to save your feet for the Midway itself). 

 

Add to all of this Jet Ski’s, Beaches, a Zoo and the Mexican / Little Italy areas and you are spoilt for choice. 

However, it wouldn’t be fair if I didn’t also point out the Top Gun factor. Yes, that iconic 80’s Film was filmed and set here in San Diego and Coronado Island. 

Don’t believe me? Check out this great article marking the highlights from the film 

And if you’re a die-hard fan (like me) how about a stop off at Kansas City BBQ. Opposite the Conference venue (2 minutes walk from the main front doors) and you can be transported into the film itself. Go On.. I dare you to try the piano!

 

Stop Press!. Q 11 I can’t be there in person, is there another way of taking part?

Yes! We’ve just announced the Simulcast – live streaming of this event. Get the Membership Pledge and view the whole proceedings from the comfort of your armchair!

read more