Howdy, Stranger!
It looks like you're new here. If you want to get involved, click one of these buttons!
Quick Links
Categories
- 7.8K All Categories
- 11 Help with translations
- 4.2K General questions
- 106 Roadmap
- 358 Game & application design
- 315 Plugins
- 70 User experience
- 74 Marketplace
- 290 Code snippets
- 34 Building a team?
- 269 Suggestions & requests
- 352 Announce your apps made with Gideros.
- 90 Step by step tutorials
- 659 Bugs and issues
- 195 Introduce yourself
- 236 Announcements
- 105 Forum talk
- 403 Relax cafe
Comments
> Guys, I'm doing a "promo" video for this live coding stuff. Do you have any high res images of the Gideros and ZeroBrane logos that you can send me?
ZeroBraneStudio/zbstudio/res/icons/ folder should have png icons of various sizes (up to 256x256). Let me know if you need anything else. Thanks!
best regards
What I may be considering doing is this (if you want to give it a shot yourself). Add a counter to wxEVT_IDLE event (that simply checks time). Reset that counter in wxEVT_STC_MODIFIED event. In DebuggerRefreshScratchpad add a check that only refreshes when the IDLE time (without EVT_STC_MODIFIED events) exceeds your threshold. A potential problem to handle is the fact that IDLE events are not called all the time (at least not on all platforms); in some cases they are called only after some other events, so you may need to "force" them with RequestMore method (http://docs.wxwidgets.org/2.8/wx_wxidleevent.html#wxidleeventrequestmore).
An alternative (and potentially a better) way may be to register a timer that will refresh scratchpad and reset that timer every time we get a new request for "scratching". This has a benefit of all the logic to be encapsulated in one place close to the scratchpad logic. When the time fires don't reset it right away, but wait for the first change. Essentially (this is inside DebuggerRefreshScratchpad):
1. Check if there is a timer; if there is, reset it; if not, set it.
2. In the timer handler, refresh the scratchpad; remove the timer.
Yet another (the simplest) way I usually use with scratchpad when I want to avoid the changes is to cause a simple compilation error, make all your changes, and then remove it. It is usually quick and painless and is the main reason why I have been hesitant to add all the logic I described above
I'm just trying to record a demo video and I thought this might make it run smoother. I think the second method sounds more like the way I'd do it so I'll take a look, although the wx stuff is all black magic to me.
I've discovered your final trick already - I'm currently putting a . where I want compilation to stop. That's certainly is good to stop the code re-running but still slows down typing.
best regards
The problem is with the speed of typing in the live coding editor window when it contains more that just a few lines. As I mentioned above, I had assumed this was to do with the frequency at which changes are pushed to the running app. I thought these were occurring with each character typed so I made an attempt to introduce a timer to throttle this (as per paul's suggestion #2 above). This does indeed seem to stop the program being compiled and updated too frequently but, sadly, the speed of typing in the editor remains far too slow; about 1 char every second for my modest single page of Lua code.
Unfortunately, I've run out of time to pursue this further right now, so I'm attaching a patch file for ZBS containing what I've done so far. It's very likely I've misunderstood something deep in the heart of ZBS. If we can get this working I'm happy to go back and do the video (I think I've got quite a nice little demo app prepared) but right now I just must get on with some "real" work :-O. As I say, the problem is not in the speed of updates to the app but in the speed at which one can type in the scratchpad editor.
best regards
Are you running the player on desktop or on iOS? If you're running the player on iOS, maybe the network connection is the main reason of the slow down. :-?
Also, when you "disable" scratchpad by introducing a compilation error, is it still slow even in that case? I'll be happy to take a look if you can send me the example you've been working with.
@paulclinger, thanks for the offer of help. First of all, I took another look and that code I posted before was less than correct (!!) and produced all sorts of strange problems (like updating the live code every time the mouse was moved). I think I've fixed this now and the new version only requires a change to the debugger.lua file. I've updated the zip attachment in my previous post.
Disabling the scratchpad with a syntax error makes no difference as far as I can tell. Here's a short video showing the problem:
I can send you the code if that would help but perhaps it would be best to do that via e-mail?
UPDATE: I've just found that if I turn off "Run as Scratchpad", the problem still occurs and it is slow to accept typing down in that onEnterFrame() method.
UPDATE2: It is nothing to do with "Run as Scratchpad" at all. If I start ZBS and just start typing without even starting the debug server, it is still very slow to accept text in some locations. I'm attaching a copy of that LivePad.lua file. Could this be anything to do with the new Gideros autocomplete that you've added?
best regards
Can you send me the project with all the files to paul@kulchenko.com? I'll definitely take a look and can run it on both Mac and Windows to see if it makes any difference. Just in case, what version of OSX and Gideros are you on? Thanks.
Try this. Copy that LivePad.lua file to a folder. Start ZBS and switch to that folder. DON'T start the debugger or do anything else. Open a new empty file and type "local canvas=self.canvas". That works fine for me. Now open that LivePad file, click before the first line and try and type the same thing. For me that is very slow.
Also I've noticed scrolling up and down that file seems slow too, but I don't have anything to compare that with.
I'm on a quad core iMac, running 10.7.4. I'm using Gideros 2012.8.4 but that's obviously not relevant.
Curiouser and curiouser.
UPDATE: It is the autoupdate. If I turn "Autocomplete Identifiers" off, the editing speeds up immeasurably.
best regards
Btw, you can disable Gideros auto-complete by removing "gideros" from this line in interpreters/gideros.lua: api = {"baselib", "gideros"}. See if it makes any difference.
@bowerandy, I can't reproduce this effect. I tried with and without auto-complete on the same file (at the top and in other places), but can't get any slowdown. Can you think of any other difference that may matter?
Hello paul, looking forward to use ZBS, will you post a blog about using ZBS with Gideros?
http://www.nightspade.com
Likes: atilim
We've now found that the cause was none of the above but, amazingly, was caused by the fact that I was using a Tacoma font in ZBS. Switching back to the standard font makes everything really smooth. Also, scrolling works as expected too.
@Nascode, I shall be shortly putting up a blog post on this too.
Best regards
Likes: atilim, gorkem