Evaluating LiveCode...strange pauses, garbage collection?

[kcorey]

Hi All,

I'm trying to evaluate LiveCode, but running into something strange. Livecode (5.0.0 trial) on a Hackintosh (core 2 duo cpu, 2GB ram) running 10.6.8.

Create a new main stack, put two labels called 'xloc' and 'yloc' on the card, then put this code on the card:

Code: Select all

on mouseMove h,v
   doMove h,v
end mouseMove

on touchMove h,v
   doMove h,v
end touchMove

on doMove h,v
   put h into field "xloc"
   put v into field "yloc"
   
   if not exists(graphic "demo" of card "easel") then create graphic "demo"
   
   set the style of graphic "demo" of card "easel" to "line"
   set the endArrow of graphic "demo" of card "easel" to false
   set the lineSize of graphic "demo" of card "easel" to 30
   set the arrowSize of graphic "demo" of card "easel" to 10
   set the foreColor of graphic "demo" of card "easel" to 0,255,0
   set the height of graphic "demo" of card "easel" to height of card "easel"
   set the width of graphic "demo" of card "easel" to width of card "easel"
   set the points of graphic "demo" to h,v & cr & h,v
end doMove

Switch to 'Browse' mode. Now move the mouse over the card, and you should see a large green dot following the mouse, right?

Well, sometimes you do.
Sometimes, though, you see a large green line that runs top to bottom on the card.
Sometimes, you see a green square, and the beachball comes on, and takes a while (> 1 second) to go away.

So, just out of curiosity, I set the target to be the iPad simulator, and ran it there. I don't get the pauses, which is great, but I also don't get the white card or the green dot. I see the numbers changing in the labels, so I know the event handler is being called, but nothing else seems to be happening.

Am I doing something completely bone-headed here? Am I tickling a garbage collection condition? Why the different behaviour between the app running on a Mac and on the iPad?

Thanks,

-Ken

[kcorey]

Just for the record, when built as a standalone Mac universal application, I'm not seeing the pauses either.
That appears to be an artifact of being in the IDE.

Also, that "large green line" I'm seeing is precisely the height of the card...(even if I resize the card), and the pointer is directly in the middle of the line.

If I pause moving the mouse, the system seems to catch up, and then draws points until I start moving the mouse too fast again.

-Ken

[Dixie]

Hi

Why not just...

Code: Select all

on mouseMove 
   set the loc of grc 1 to the mouseLoc
end mouseMove

What else do you need for a graphic to follow the mouse ?

Dixie

[kcorey]

Hi Daisy,

Thanks for replying.

Where I would like to go with this is something to allow something like finger painting...so it's a bit more than just an item following the mouse.

I *think* the problem with my code is that I wasn't calling 'lock screen' before drawing the dot, and 'lock screen' after the dot. Once I've done that the performance greatly increases.

Now, if I can only figure out how to programatically edit bitmap images!

-Ken

[bn]

Hi kcorey,

try this script:

Code: Select all

on mouseMove h,v
      doMove h,v
end mouseMove

-- either mouseMove or touchMove
--on touchMove h,v
--      doMove h,v
--end touchMove

on doMove h,v
   lock screen
   -- forces screen update
   put h into field "xloc"
    -- forces screen update
   put v into field "yloc"
   
   
   if not exists(graphic "demo" of card "easel") then 
      
      -- only do it if graphic "demo" does not exist
      create graphic "demo"
      
      set the style of graphic "demo" of card "easel" to "oval"
      set the width of graphic "demo" of card "easel" to 30
      set the height of graphic "demo" of card "easel" to 30
      set the backgroundColor of graphic "demo" of card "easel" to 0,255,0
      set the lineSize of grc "demo" to 0
      set the opaque of grc "demo" to true
      
      
      --      set the style of graphic "demo" of card "easel" to "line"
      --      set the endArrow of graphic "demo" of card "easel" to false
      --      set the lineSize of graphic "demo" of card "easel" to 30
      --      set the arrowSize of graphic "demo" of card "easel" to 10
      --      set the foreColor of graphic "demo" of card "easel" to 0,255,0
      
      --      -- no need if you only want a circle of 30 points
      --      set the height of graphic "demo" of card "easel" to height of card "easel"
      --      set the width of graphic "demo" of card "easel" to width of card "easel"
   end if
   
   -- set the loc, not the points, also forces screen update
   set the loc  of graphic "demo" to h,v 
   unlock screen
end doMove

there were several things you did that were redundant:
either mouseMove or touchMove, mouseMove also works on iOS
You did test if grc "demo" is there but even if it is there you set all the properties again which force a screen update
lock screen/unlock screen helps Livecode to do the scren update when all your settings forcing a screen update are done.

If you want a green dot to move it is easier to make an oval graphic and set its loc instead of the points. Actually in a graphic you usualy set the points only if you want to change the appearance of a line/polygon/curve graphic.
When you set the width/height of graphic "demo" that gives you the stripes, it is not necessary to set the width and height in your original script.


And I see Dixie was faster then I was Hi Dixie.

Kind regards

Bernd

[Dixie]

Hi...

I have attached a stack that might help you to get started with your 'finger painting'... just try writing or drawing some squiggles on the card... try running it in the IDE and/or in the iphone simulator..

Hope it helps

Dixie

Hi Bernd, long time...

[kcorey]

Ah, what great input! Thank you both for taking the time. I can see how recreating the graphics settings on each frame would cause problems.

It's becoming clear to me now.

Dixie, in the finger painting snippet you gave me, does everything just default to a "useful" value? I don't see where you make the "grc draw", your code simply assumes it is there and gets on with it...or did I just not see where it is being created?

An interesting thing about livecode is that it feels, in some respects, like forth. The application one is building is a live thing, and when you package it, its current state is packaged with it. For example, scribble a bit, then test it on the iPad simulator,or create a standalone Mac app, and it starts with the same scribble that was on the screen at package time. Funky!

Also, is the app in development always live? If I've written a mouse move event, then that event is still being fired even if the pointer tool is selected.

Do I just need to know not to do that (in this case, protect the mouse move event by only capturing when the mouse is down)?

Is there a way to say "No, really, don't process events right now, I'm designing"?

-Ken

[bn]

Hi Ken,

usually you don't want to rely just on mouseMove. The user would would be confused if just by moving the mouse the green point would be moving. In touch operated environments the mouseMove only fires if there was a touch before and the mouse/finger is moved around.

What I do in situations like that is I do a mouseDown handler. The mouseDown handler initializes whatever is needed and then the mouseMove takes over. MouseMove only handles what is needed for the move, no initialization etc. MouseUp cleans up afterwards.

Code: Select all

-- script local variable that persists between calls. 
-- and is set to true by mouseDown, false by mouseUp

local sTrack = false  

on mouseDown
   if not exists(graphic "demo" of card "easel") then 
      lock screen
      create graphic "demo"
      set the style of graphic "demo" of card "easel" to "oval"
      set the width of graphic "demo" of card "easel" to 30
      set the height of graphic "demo" of card "easel" to 30
      set the backgroundColor of graphic "demo" of card "easel" to 0,255,0
      set the lineSize of grc "demo" to 0
      set the opaque of grc "demo" to true
      unlock screen
   end if
   
   put true into sTrack
end mouseDown

on mouseMove h,v
   if not sTrack then exit mouseMove
   lock screen
   put h into field "xloc"
   put v into field "yloc"
   set the loc  of graphic "demo" to h,v 
   unlock screen
end mouseMove

on mouseUp
   put false into sTrack
end mouseUp

now the mouseMove message only moves the graphic if the mouse is down/the finger slides on the touch device.

Please note the use of a script local variable. This type of varible is available to the handlers in the script where it is declared (more precisely to handlers that are below the declaration of the script local variable. That is the reason why most everyone declares them at the top of a script. It persists between calls. It is cleared when closing the stack. I find this type of variable very handy. They can be initialized with a default value.

In the IDE during development you could also choose in menu Development -> Suppress Messages. This will prevent messages being sent. But some things that depend on messages will not work either.

Kind regards

Bernd