my first public post to the list, pet project got a page at last

classic Classic list List threaded Threaded
21 messages Options
12
Reply | Threaded
Open this post in threaded view
|

my first public post to the list, pet project got a page at last

gershon
hello to all, would first like to thank Nicolas for all his amazing
work, also to Madrok for vast portions of this code, and general
support.

so here it is:
http://haxegui.blogspot.com/

and for the source & more info:
http://code.google.com/p/haxegui/

Cheers, gershon.


--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: my first public post to the list, pet project got a page at last

Zjnue Brzavi
> hello to all, would first like to thank Nicolas for all his amazing
> work, also to Madrok for vast portions of this code, and general
> support.
>
> so here it is:
> http://haxegui.blogspot.com/
>
> and for the source & more info:
> http://code.google.com/p/haxegui/

Very impressive ! Thank you....

Zjnue

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: my first public post to the list, pet project got a page at last

Armén
Nice work, but I am experiencing 85% CPU usage with your interface
idle. Just the animating progress bar. Have you gone all over the top
with timers? :-)

On Sun, Jul 12, 2009 at 00:02, Zjnue Brzavi<[hidden email]> wrote:

>> hello to all, would first like to thank Nicolas for all his amazing
>> work, also to Madrok for vast portions of this code, and general
>> support.
>>
>> so here it is:
>> http://haxegui.blogspot.com/
>>
>> and for the source & more info:
>> http://code.google.com/p/haxegui/
>
> Very impressive ! Thank you....
>
> Zjnue
>
> --
> haXe - an open source web programming language
> http://haxe.org
>

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: my first public post to the list, pet project got a page at last

Russell Weir
In reply to this post by Zjnue Brzavi
All Components in HaxeGUI are scripted using HScript. All events like mouse interaction, as well as
the styles are completely customizable in HScript, either as an overall style, or on a per component
basis. This allows you to dynamically change each component at runtime by overriding its script,
which could be loaded from a resource file, web location, or scripted right into the XML layout files.
Not only can the regular interaction events be overridden, but the style of the component itself,
so an individual standard button could basically be made to look any way you choose by simply
changing the hscript at runtime.

The console gives you full access to doing direct manipulation of components by code, but is a little
complicated to explain quickly, but has a pseudo-filesystem approach to moving up and down the
tree of components.

To resize or move components, simply ctrl-click them, then use the center point to move, or outside
points to resize.

If you are experiencing high load, it may just be the stats window, which you can close,
but there is certainly lots to trim down for speed yet, we've been busy fleshing out all the features,
so no optimizations have been done yet.

Russell
(freenode #haxe madrok)




On Sat, Jul 11, 2009 at 4:02 PM, Zjnue Brzavi <[hidden email]> wrote:
> hello to all, would first like to thank Nicolas for all his amazing
> work, also to Madrok for vast portions of this code, and general
> support.
>
> so here it is:
> http://haxegui.blogspot.com/
>
> and for the source & more info:
> http://code.google.com/p/haxegui/

Very impressive ! Thank you....

Zjnue

--
haXe - an open source web programming language
http://haxe.org


--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: my first public post to the list, pet project got a page at last

gershon
In reply to this post by Armén
10x for the comments, performance is one of the reasons its not on the haxelib yet...

about the timers, actually the main one, the one that watches for redraws is set to 300 in the version you've seen, which is slow for a redrawing timer, and the effects can clearly be seen (and are, only because this is still a development version) when resizing window.

as for the rest of them, here's a little snippet(courtesy of Madrok)  from the basic visual class, Component:

    private function onEnterFrame(e:Event) : Void
    {
        var now = haxe.Timer.stamp();
        var stepsF : Float  = (now - lastInterval) * intervalUpdatesPerSec;
        var steps : Int = Math.floor( stepsF );
        lastInterval += steps / intervalUpdatesPerSec;

        for(x in 0...steps) {
            ScriptManager.exec(this,"interval",{event:e});
        }
    }

wont go through the the works, but intervals allow different components to act more naturally and independently, like the Stepper buttons auto-repeating  at diffrent reates...

so yeah, i guess there's a bunch of timers hanging around...

my final remark would be, that even though the ProgressBar's interval is set for only 12fps than yes, those are quite cpu intense, and i'm exploring ways of optimizing drawing,
particularly, i'm thinking of double-buffering and "culling" the internal redraw functions to ease stress to the flash rendered.

sorry for a long post, gershon.

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: my first public post to the list, pet project got a page at last

Benjamin Dasnois
Hello,

That's really impressive! Good job guys! :)

Regards,

On Sun, Jul 12, 2009 at 12:43 AM, gershon<[hidden email]> wrote:

> 10x for the comments, performance is one of the reasons its not on the
> haxelib yet...
>
> about the timers, actually the main one, the one that watches for redraws is
> set to 300 in the version you've seen, which is slow for a redrawing timer,
> and the effects can clearly be seen (and are, only because this is still a
> development version) when resizing window.
>
> as for the rest of them, here's a little snippet(courtesy of Madrok)  from
> the basic visual class, Component:
>
>     private function onEnterFrame(e:Event) : Void
>     {
>         var now = haxe.Timer.stamp();
>         var stepsF : Float  = (now - lastInterval) * intervalUpdatesPerSec;
>         var steps : Int = Math.floor( stepsF );
>         lastInterval += steps / intervalUpdatesPerSec;
>
>         for(x in 0...steps) {
>             ScriptManager.exec(this,"interval",{event:e});
>         }
>     }
>
> wont go through the the works, but intervals allow different components to
> act more naturally and independently, like the Stepper buttons
> auto-repeating  at diffrent reates...
>
> so yeah, i guess there's a bunch of timers hanging around...
>
> my final remark would be, that even though the ProgressBar's interval is set
> for only 12fps than yes, those are quite cpu intense, and i'm exploring ways
> of optimizing drawing,
> particularly, i'm thinking of double-buffering and "culling" the internal
> redraw functions to ease stress to the flash rendered.
>
> sorry for a long post, gershon.
>
> --
> haXe - an open source web programming language
> http://haxe.org
>



--
DASNOIS Benjamin
http://www.benjamindasnois.com

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: my first public post to the list, pet project got a page at last

jlm@justinfront.net
In reply to this post by gershon
Well done guys big thumbs up ;J

On 11 Jul 2009, at 22:01, gershon wrote:

> hello to all, would first like to thank Nicolas for all his amazing
> work, also to Madrok for vast portions of this code, and general
> support.
>
> so here it is:
> http://haxegui.blogspot.com/
>
> and for the source & more info:
> http://code.google.com/p/haxegui/
>
> Cheers, gershon.
>
>
> --
> haXe - an open source web programming language
> http://haxe.org


--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: my first public post to the list, pet project got a page at last

Baluta Cristian
Can you give a real life example? I still don't see what is this useful for after viewing the video and the sample. And i personally think that flash is too slow to create guis, the windows are just not moving naturally, and this is annoying. If you've used mousewheel, you'll have to implement swfmacmousewheel for those who are mac users.
Otherwise, i'm sure was not easy to do, and congrats for it.

On Sun, Jul 12, 2009 at 6:01 AM, Justin Lawerance Mills <[hidden email]> wrote:
Well done guys big thumbs up ;J


On 11 Jul 2009, at 22:01, gershon wrote:

hello to all, would first like to thank Nicolas for all his amazing
work, also to Madrok for vast portions of this code, and general
support.

so here it is:
http://haxegui.blogspot.com/

and for the source & more info:
http://code.google.com/p/haxegui/

Cheers, gershon.


--
haXe - an open source web programming language
http://haxe.org


--
haXe - an open source web programming language
http://haxe.org



--
Băluță Cristian
http://ralcr.com
http://imagin.ro

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: my first public post to the list, pet project got a page at last

gershon
have'nt yet spawned a "real" example from this code, but a guil builder is not that far away, which should yield more practical examples.

one example i do have, which broke during my massive commits to the svn :), is a layout for a step-sequencer, using play\pause buttons and a stepper for the bpm, 16 radioboxes blink accordingly, over a matrix of checkboxes. the code is visual only, does not play and not optimized, but like i said,  its only an example ..

10x for the mousewhell tip, will look into it, especially i'm interested in external mouse event injection, for use on a cpp platform, something like hikari (http://www.ogre3d.org/forums/viewtopic.php?t=41999) does on ogre, and toui, for multi touch platforms, like the iphone and tabletpc, both of which would probably impact performence even more...

about the speed, i noticed that running online with the plugin version of player has mouse interaction issues (like window-dragging lags), might be the browser, would apreciate any feedback on that, anyway, the flash rendered does all the work there as its a simple startDrag, which makes me wonder again if there is room for optimization...



On Sun, Jul 12, 2009 at 8:56 AM, Baluta Cristian <[hidden email]> wrote:
Can you give a real life example? I still don't see what is this useful for after viewing the video and the sample. And i personally think that flash is too slow to create guis, the windows are just not moving naturally, and this is annoying. If you've used mousewheel, you'll have to implement swfmacmousewheel for those who are mac users.
Otherwise, i'm sure was not easy to do, and congrats for it.


On Sun, Jul 12, 2009 at 6:01 AM, Justin Lawerance Mills <[hidden email]> wrote:
Well done guys big thumbs up ;J


On 11 Jul 2009, at 22:01, gershon wrote:

hello to all, would first like to thank Nicolas for all his amazing
work, also to Madrok for vast portions of this code, and general
support.

so here it is:
http://haxegui.blogspot.com/

and for the source & more info:
http://code.google.com/p/haxegui/

Cheers, gershon.


--
haXe - an open source web programming language
http://haxe.org


--
haXe - an open source web programming language
http://haxe.org



--
Băluță Cristian
http://ralcr.com
http://imagin.ro

--
haXe - an open source web programming language
http://haxe.org


--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: my first public post to the list, pet project got a page at last

Tony Polinelli
it all runs perfectly well on my laptop (new macbook) - so i'm very
impressed - you might need more performance for older systems, but for
the furure this looks very promising. gret work!

On 7/12/09, gershon <[hidden email]> wrote:

> have'nt yet spawned a "real" example from this code, but a guil builder is
> not that far away, which should yield more practical examples.
>
> one example i do have, which broke during my massive commits to the svn :),
> is a layout for a step-sequencer, using play\pause buttons and a stepper for
> the bpm, 16 radioboxes blink accordingly, over a matrix of checkboxes. the
> code is visual only, does not play and not optimized, but like i said,  its
> only an example ..
>
> 10x for the mousewhell tip, will look into it, especially i'm interested in
> external mouse event injection, for use on a cpp platform, something like
> hikari (http://www.ogre3d.org/forums/viewtopic.php?t=41999) does on ogre,
> and toui, for multi touch platforms, like the iphone and tabletpc, both of
> which would probably impact performence even more...
>
> about the speed, i noticed that running online with the plugin version of
> player has mouse interaction issues (like window-dragging lags), might be
> the browser, would apreciate any feedback on that, anyway, the flash
> rendered does all the work there as its a simple startDrag, which makes me
> wonder again if there is room for optimization...
>
>
>
> On Sun, Jul 12, 2009 at 8:56 AM, Baluta Cristian
> <[hidden email]>wrote:
>
>> Can you give a real life example? I still don't see what is this useful
>> for
>> after viewing the video and the sample. And i personally think that flash
>> is
>> too slow to create guis, the windows are just not moving naturally, and
>> this
>> is annoying. If you've used mousewheel, you'll have to implement
>> swfmacmousewheel for those who are mac users. Otherwise, i'm sure was not
>> easy to do, and congrats for it.
>>
>>
>> On Sun, Jul 12, 2009 at 6:01 AM, Justin Lawerance Mills <
>> [hidden email]> wrote:
>>
>>> Well done guys big thumbs up ;J
>>>
>>>
>>> On 11 Jul 2009, at 22:01, gershon wrote:
>>>
>>>  hello to all, would first like to thank Nicolas for all his amazing
>>>> work, also to Madrok for vast portions of this code, and general
>>>> support.
>>>>
>>>> so here it is:
>>>> http://haxegui.blogspot.com/
>>>>
>>>> and for the source & more info:
>>>> http://code.google.com/p/haxegui/
>>>>
>>>> Cheers, gershon.
>>>>
>>>>
>>>> --
>>>> haXe - an open source web programming language
>>>> http://haxe.org
>>>>
>>>
>>>
>>> --
>>> haXe - an open source web programming language
>>> http://haxe.org
>>>
>>
>>
>>
>> --
>> Băluță Cristian
>> http://ralcr.com
>> http://imagin.ro
>>
>> --
>> haXe - an open source web programming language
>> http://haxe.org
>>
>


--
Tony Polinelli
http://touchmypixel.com

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: my first public post to the list, pet project got a page at last

Armén
In reply to this post by gershon
I am in no position to use this list as a "strong suggestion" channel,
but since you posted a snippet and it does run slow on my Pentium M
2.0Ghz laptop, which I consider still viable for GUIs :-) - I would
like to dig deeper into the slowness issue.

You mention onEnterFrame function for a "basic visual class,
Component". Is this component a base class for all and any GUI
elements? This would mean there is a timer for EACH element present in
the GUI - a text control, button, checkbox, radio button etc.

I am gussing since you wrote such a library, you are not an amateur.
Do not misunderstand me, I just try to help, using my own case as
study. In fear of sounding intruding (and I assure you I am not) - you
don't run that onEnterFrame call for EVERY widget, do you? That would
be a MAJOR waste of resources.

Also, can you please elaborate what does "the main one, the one that
watches for redraws" mean? Flash Player manipulates display list
automatically, unless you manually composite bitmaps using the
flash.display.BitmapData.draw method. You only need to respond to user
events. And of course, the only thing that would need to respond to
timer event would be an animated progress bar, given that it needs to
animate at some usable framerate.

I don't pretend to be a smart ass, I am just genuinely interested in
your explanations, if you are so generous to have time to provide
them. I am developing a GUI myself, not as generic, but still quite
extensive, progress bars and all.

Of course, I could just dig into the source code of HaXeGUI, if you
think that would explain it better...

On Sun, Jul 12, 2009 at 00:43, gershon<[hidden email]> wrote:

> 10x for the comments, performance is one of the reasons its not on the
> haxelib yet...
>
> about the timers, actually the main one, the one that watches for redraws is
> set to 300 in the version you've seen, which is slow for a redrawing timer,
> and the effects can clearly be seen (and are, only because this is still a
> development version) when resizing window.
>
> as for the rest of them, here's a little snippet(courtesy of Madrok)  from
> the basic visual class, Component:
>
>     private function onEnterFrame(e:Event) : Void
>     {
>         var now = haxe.Timer.stamp();
>         var stepsF : Float  = (now - lastInterval) * intervalUpdatesPerSec;
>         var steps : Int = Math.floor( stepsF );
>         lastInterval += steps / intervalUpdatesPerSec;
>
>         for(x in 0...steps) {
>             ScriptManager.exec(this,"interval",{event:e});
>         }
>     }
>
> wont go through the the works, but intervals allow different components to
> act more naturally and independently, like the Stepper buttons
> auto-repeating  at diffrent reates...
>
> so yeah, i guess there's a bunch of timers hanging around...
>
> my final remark would be, that even though the ProgressBar's interval is set
> for only 12fps than yes, those are quite cpu intense, and i'm exploring ways
> of optimizing drawing,
> particularly, i'm thinking of double-buffering and "culling" the internal
> redraw functions to ease stress to the flash rendered.
>
> sorry for a long post, gershon.
>
> --
> haXe - an open source web programming language
> http://haxe.org
>

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: my first public post to the list, pet project got a page at last

Niel Drummond-3
In reply to this post by Tony Polinelli
Tony Polinelli wrote:
> it all runs perfectly well on my laptop (new macbook) - so i'm very
> impressed - you might need more performance for older systems, but for
> the furure this looks very promising. gret work!
>  
I concur.. the hscript rendering technique is a compelling way of
approaching theming.. looking forward to playing a little with it. ;-)

- Niel

> On 7/12/09, gershon <[hidden email]> wrote:
>  
>> have'nt yet spawned a "real" example from this code, but a guil builder is
>> not that far away, which should yield more practical examples.
>>
>> one example i do have, which broke during my massive commits to the svn :),
>> is a layout for a step-sequencer, using play\pause buttons and a stepper for
>> the bpm, 16 radioboxes blink accordingly, over a matrix of checkboxes. the
>> code is visual only, does not play and not optimized, but like i said,  its
>> only an example ..
>>
>> 10x for the mousewhell tip, will look into it, especially i'm interested in
>> external mouse event injection, for use on a cpp platform, something like
>> hikari (http://www.ogre3d.org/forums/viewtopic.php?t=41999) does on ogre,
>> and toui, for multi touch platforms, like the iphone and tabletpc, both of
>> which would probably impact performence even more...
>>
>> about the speed, i noticed that running online with the plugin version of
>> player has mouse interaction issues (like window-dragging lags), might be
>> the browser, would apreciate any feedback on that, anyway, the flash
>> rendered does all the work there as its a simple startDrag, which makes me
>> wonder again if there is room for optimization...
>>
>>
>>
>> On Sun, Jul 12, 2009 at 8:56 AM, Baluta Cristian
>> <[hidden email]>wrote:
>>
>>    
>>> Can you give a real life example? I still don't see what is this useful
>>> for
>>> after viewing the video and the sample. And i personally think that flash
>>> is
>>> too slow to create guis, the windows are just not moving naturally, and
>>> this
>>> is annoying. If you've used mousewheel, you'll have to implement
>>> swfmacmousewheel for those who are mac users. Otherwise, i'm sure was not
>>> easy to do, and congrats for it.
>>>
>>>
>>> On Sun, Jul 12, 2009 at 6:01 AM, Justin Lawerance Mills <
>>> [hidden email]> wrote:
>>>
>>>      
>>>> Well done guys big thumbs up ;J
>>>>
>>>>
>>>> On 11 Jul 2009, at 22:01, gershon wrote:
>>>>
>>>>  hello to all, would first like to thank Nicolas for all his amazing
>>>>        
>>>>> work, also to Madrok for vast portions of this code, and general
>>>>> support.
>>>>>
>>>>> so here it is:
>>>>> http://haxegui.blogspot.com/
>>>>>
>>>>> and for the source & more info:
>>>>> http://code.google.com/p/haxegui/
>>>>>
>>>>> Cheers, gershon.
>>>>>
>>>>>
>>>>> --
>>>>> haXe - an open source web programming language
>>>>> http://haxe.org
>>>>>
>>>>>          
>>>> --
>>>> haXe - an open source web programming language
>>>> http://haxe.org
>>>>
>>>>        
>>>
>>> --
>>> Băluță Cristian
>>> http://ralcr.com
>>> http://imagin.ro
>>>
>>> --
>>> haXe - an open source web programming language
>>> http://haxe.org
>>>
>>>      
>
>
>  


--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: my first public post to the list, pet project got a page at last

gershon
10x for great feedback guys, any future posts with a mention to performance please specify  a bit more, using the standalone debug player, at ~120ms intervals after a few mintues of runtime(stats might need refresh), i get a minFPS as low as 5fps, and the avgFPS, generaly declining :(, is roughly ~80-90fps, and is very resposive.

the Stats window does'nt boot properly, sorry for that, have'nt written a proper graph plotter yet also, this is just dirty line drawing for arrays, an should undergo optimization too...

Martin, happily, please supply a google mail address to be added to our svn commiters, same goes for anyone on the list.


"the main one, the one that watches for redraws", is a timer in the "main" class, haxegui.Haxegui, which boots the whole thing up, starts all managers, loads the style, and keeps a list of "dirty" objects. This is called defered rendering by the adobe guys, and does basically the same as the invalidation in flex, a property can change several times between frames you see, especially while in the component's init stage, so instead of redrawing the component raises its dirty flag, which gets pulled down once its redrawn to screen.

the process is'nt perfect, and still lacks features, like obfstructed components still raising their dirty flag, which naturaly led me to think about manually composing the display list to bitmaps, as you've very un-smart-ass-ingly written, and i might have mentioned in a previous post here... ;)

Component has a static rasterize() method which renders any component, with given quality (not my code, though easy enough to get, draw it to a smaller bitmap and then strech that) to a BitmapData, but i need a good strategy on using it, as flash already caches anything drawn with filters to bitmaps (almost everything is haxegui has atleast a dropshadow!)

ok, now to make things right, here's the missing code, Russell, you the man.

    /**
    * Starts an interval timer, which calls the "interval" action, after waiting [wait] seconds
    *
    * @param updatesPerSecond Number of times per second the interval action will be called
    * @param wait Number of seconds to wait before the first update.
    **/
    public function startIntervalDelayed(updatesPerSecond : Float, wait : Float) : Void {
        stopInterval();
        if(updatesPerSecond < 1) return;
        if(Math.isNaN(wait)) wait = 0.0;
        lastInterval = haxe.Timer.stamp() + wait;
        intervalUpdatesPerSec = updatesPerSecond;
        this.addEventListener(flash.events.Event.ENTER_FRAME, onEnterFrame);
    }

    /**
    * Stop the current interval timer
    **/
    public function stopInterval() : Void {
        this.removeEventListener(flash.events.Event.ENTER_FRAME, onEnterFrame);
    }


so as you can see, onEnterFrame is never called directly (~600 objects on stage, that would indeed be much), instead, the interval is called, which performs the action at an independent fps, timer based, which might be a little expensive but gives great freedom.

i've successfuly got tweens running inside these intervals, all is very accurate and performs well, a game i'm working on utilizing haxegui, does those on 1024x768px bitmaps!

setting\overriding  the action (runtime too) is as simple as writing hscript in a <script> tag in the xml file, or just calling the setAction("interval", "hscript goes here") for the component.

this will be the last post of this length, the next will be on blog,

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: my first public post to the list, pet project got a page at last

Don-Duong Quach
Wow.  How did I miss this?!  Amazing work guys!

-Don Q.

On Tue, Jul 14, 2009 at 2:21 PM, gershon <[hidden email]> wrote:
10x for great feedback guys, any future posts with a mention to performance please specify  a bit more, using the standalone debug player, at ~120ms intervals after a few mintues of runtime(stats might need refresh), i get a minFPS as low as 5fps, and the avgFPS, generaly declining :(, is roughly ~80-90fps, and is very resposive.

the Stats window does'nt boot properly, sorry for that, have'nt written a proper graph plotter yet also, this is just dirty line drawing for arrays, an should undergo optimization too...

Martin, happily, please supply a google mail address to be added to our svn commiters, same goes for anyone on the list.


"the main one, the one that watches for redraws", is a timer in the "main" class, haxegui.Haxegui, which boots the whole thing up, starts all managers, loads the style, and keeps a list of "dirty" objects. This is called defered rendering by the adobe guys, and does basically the same as the invalidation in flex, a property can change several times between frames you see, especially while in the component's init stage, so instead of redrawing the component raises its dirty flag, which gets pulled down once its redrawn to screen.

the process is'nt perfect, and still lacks features, like obfstructed components still raising their dirty flag, which naturaly led me to think about manually composing the display list to bitmaps, as you've very un-smart-ass-ingly written, and i might have mentioned in a previous post here... ;)

Component has a static rasterize() method which renders any component, with given quality (not my code, though easy enough to get, draw it to a smaller bitmap and then strech that) to a BitmapData, but i need a good strategy on using it, as flash already caches anything drawn with filters to bitmaps (almost everything is haxegui has atleast a dropshadow!)

ok, now to make things right, here's the missing code, Russell, you the man.

    /**
    * Starts an interval timer, which calls the "interval" action, after waiting [wait] seconds
    *
    * @param updatesPerSecond Number of times per second the interval action will be called
    * @param wait Number of seconds to wait before the first update.
    **/
    public function startIntervalDelayed(updatesPerSecond : Float, wait : Float) : Void {
        stopInterval();
        if(updatesPerSecond < 1) return;
        if(Math.isNaN(wait)) wait = 0.0;
        lastInterval = haxe.Timer.stamp() + wait;
        intervalUpdatesPerSec = updatesPerSecond;
        this.addEventListener(flash.events.Event.ENTER_FRAME, onEnterFrame);
    }

    /**
    * Stop the current interval timer
    **/
    public function stopInterval() : Void {
        this.removeEventListener(flash.events.Event.ENTER_FRAME, onEnterFrame);
    }


so as you can see, onEnterFrame is never called directly (~600 objects on stage, that would indeed be much), instead, the interval is called, which performs the action at an independent fps, timer based, which might be a little expensive but gives great freedom.

i've successfuly got tweens running inside these intervals, all is very accurate and performs well, a game i'm working on utilizing haxegui, does those on 1024x768px bitmaps!

setting\overriding  the action (runtime too) is as simple as writing hscript in a <script> tag in the xml file, or just calling the setAction("interval", "hscript goes here") for the component.

this will be the last post of this length, the next will be on blog,

--
haXe - an open source web programming language
http://haxe.org


--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: my first public post to the list, pet project got a page at last

Gamehaxe
In reply to this post by gershon
Hi,
Just looking at haxegui, and the use of hxscript.
I think you are using hxscript a bit too much.
Don't get me wrong - I think it is a good idea,
but I think it should be optional.  More for uis specified
by XML from a rad tool, eg

<button id="ok" mouseClick="Main.go()">Ok</button>

but not:
var button = new Button("Ok");

button.mouseClick = "Main.go();";

instead:

button.mouseClick = function() { Main.go(); }

And then use a helper function: something like:

button.mouseClick = Script.create("Main.go();");

So for a small amount of extra keyboard typing, you
get compile-time checks, and extra syntax options without
losing you scripting ability.

You could even take a "Dynamic" and check to see if
it is a string or a function (actually, maybe you are
already doing this ?).

If you are coding the ui with class files, then you certainly
want to use real haxe.  If you are reading from an
XML file, then creating the script is only done in one
place, so there is no issue there either.

I like the idea of this project, I hope this helps.

Hugh

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: my first public post to the list, pet project got a page at last

Max S-3
In reply to this post by Russell Weir
I confirm, 50-70% cpu load on Athlon X2 with stats window open. After
closing it drops to 2-5% when progress bar is off-screen and 10% when
it's on. Congrats :)

2009/7/12 Russell Weir <[hidden email]>:

> All Components in HaxeGUI are scripted using HScript. All events like mouse
> interaction, as well as
> the styles are completely customizable in HScript, either as an overall
> style, or on a per component
> basis. This allows you to dynamically change each component at runtime by
> overriding its script,
> which could be loaded from a resource file, web location, or scripted right
> into the XML layout files.
> Not only can the regular interaction events be overridden, but the style of
> the component itself,
> so an individual standard button could basically be made to look any way you
> choose by simply
> changing the hscript at runtime.
>
> The console gives you full access to doing direct manipulation of components
> by code, but is a little
> complicated to explain quickly, but has a pseudo-filesystem approach to
> moving up and down the
> tree of components.
>
> To resize or move components, simply ctrl-click them, then use the center
> point to move, or outside
> points to resize.
>
> If you are experiencing high load, it may just be the stats window, which
> you can close,
> but there is certainly lots to trim down for speed yet, we've been busy
> fleshing out all the features,
> so no optimizations have been done yet.
>
> Russell
> (freenode #haxe madrok)
>
>
>
>
> On Sat, Jul 11, 2009 at 4:02 PM, Zjnue Brzavi <[hidden email]>
> wrote:
>>
>> > hello to all, would first like to thank Nicolas for all his amazing
>> > work, also to Madrok for vast portions of this code, and general
>> > support.
>> >
>> > so here it is:
>> > http://haxegui.blogspot.com/
>> >
>> > and for the source & more info:
>> > http://code.google.com/p/haxegui/
>>
>> Very impressive ! Thank you....
>>
>> Zjnue
>>
>> --
>> haXe - an open source web programming language
>> http://haxe.org
>
>
> --
> haXe - an open source web programming language
> http://haxe.org
>

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: my first public post to the list, pet project got a page at last

gershon
In reply to this post by Gamehaxe
please see http://haxegui.blogspot.com/2009/07/comparision-of-coding-styles.html, to see a demo of the same thing written in both haxe and hscript, hopefully making more sense into our script usage...



On Wed, Jul 15, 2009 at 3:00 PM, Hugh Sanderson <[hidden email]> wrote:
Hi,
Just looking at haxegui, and the use of hxscript.
I think you are using hxscript a bit too much.
Don't get me wrong - I think it is a good idea,
but I think it should be optional.  More for uis specified
by XML from a rad tool, eg

<button id="ok" mouseClick="Main.go()">Ok</button>

but not:
var button = new Button("Ok");

button.mouseClick = "Main.go();";

instead:

button.mouseClick = function() { Main.go(); }

And then use a helper function: something like:

button.mouseClick = Script.create("Main.go();");

So for a small amount of extra keyboard typing, you
get compile-time checks, and extra syntax options without
losing you scripting ability.

You could even take a "Dynamic" and check to see if
it is a string or a function (actually, maybe you are
already doing this ?).

If you are coding the ui with class files, then you certainly
want to use real haxe.  If you are reading from an
XML file, then creating the script is only done in one
place, so there is no issue there either.

I like the idea of this project, I hope this helps.

Hugh

--
haXe - an open source web programming language
http://haxe.org


--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: my first public post to the list, pet project got a page at last

Gamehaxe
Hi,

I guess i agree with this:

please note, that had this not been a demonstration, i would have probably  
gone with a 3rd hybrid coding style, using hscript in the haxe .hx file,  
instead of multiple classes...

except change "hscript" to "haxe callbacks".

eg:

hours = new Component(this);
hours.init();
hours.redraw = function(opts:Dynamic) {
        hours.graphics.clear();
        this.graphics.lineStyle(2, Std.int(Math.random() * 0xFFFFFF), 1, true,
                                                        flash.display.LineScaleMode.NONE,
                                                        flash.display.CapsStyle.ROUND,
                                                        flash.display.JointStyle.ROUND);
        var r = Math.min( Std.int((cast hours.parent).box.width)>>1,  
Std.int((cast hours.parent).box.height)>>1 );
        hours.graphics.moveTo(0,0);
        hours.graphics.lineTo(0,-.75*r);
}

Which is I guess what you are getting at, but it
uses haxe instead of hscript.  You only need to put the
keyword "dynamic" infront of your redraw proc to be able to do this.

Hugh


> please see
> http://haxegui.blogspot.com/2009/07/comparision-of-coding-styles.html, to
> see a demo of the same thing written in both haxe and hscript, hopefully
> making more sense into our script usage...
>
>
>
> On Wed, Jul 15, 2009 at 3:00 PM, Hugh Sanderson  
> <[hidden email]>wrote:
>
>> Hi,
>> Just looking at haxegui, and the use of hxscript.
>> I think you are using hxscript a bit too much.
>> Don't get me wrong - I think it is a good idea,
>> but I think it should be optional.  More for uis specified
>> by XML from a rad tool, eg
>>
>> <button id="ok" mouseClick="Main.go()">Ok</button>
>>
>> but not:
>> var button = new Button("Ok");
>>
>> button.mouseClick = "Main.go();";
>>
>> instead:
>>
>> button.mouseClick = function() { Main.go(); }
>>
>> And then use a helper function: something like:
>>
>> button.mouseClick = Script.create("Main.go();");
>>
>> So for a small amount of extra keyboard typing, you
>> get compile-time checks, and extra syntax options without
>> losing you scripting ability.
>>
>> You could even take a "Dynamic" and check to see if
>> it is a string or a function (actually, maybe you are
>> already doing this ?).
>>
>> If you are coding the ui with class files, then you certainly
>> want to use real haxe.  If you are reading from an
>> XML file, then creating the script is only done in one
>> place, so there is no issue there either.
>>
>> I like the idea of this project, I hope this helps.
>>
>> Hugh
>>
>> --
>> haXe - an open source web programming language
>> http://haxe.org
>>



--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: my first public post to the list, pet project got a page at last

gershon
agreed, only i have to check with Russell why was it that we changed dynamic methods, and are now overriding...

another reason i wrote it like that is to keep it along the general style of haxegui, which does use multiple classes per file, the StyleCompiler  looks for a directory with the class' name, and collects all .hscript files to proper xml <script> tags.

could be seen as a 4th way of doing it, and it keeps code organized, minimal and dependent.

so in this example, had i wanted to use that 4th way, i could move all init() functions to onLoaded.hscipt and redraw() to redraw.hscript, and have:

assets/styles/toys/AnalogClock/redraw.hscript
assets/styles/toys/AnalogClock/onLoaded.hscript

assets/styles/toys/HoursHand/redraw.hscript
assets/styles/toys/HoursHand/onLoaded.hscript
...
...
...

leaving me with bare-bone, readable classes, and easy to change actions, with no need to endlessly scroll down to find that specific one...

10x for the feedback, though next time please use the blog's comments, this thread is too general


On Wed, Jul 15, 2009 at 7:11 PM, Hugh Sanderson <[hidden email]> wrote:
Hi,

I guess i agree with this:

please note, that had this not been a demonstration, i would have probably gone with a 3rd hybrid coding style, using hscript in the haxe .hx file, instead of multiple classes...

except change "hscript" to "haxe callbacks".

eg:

hours = new Component(this);
hours.init();
hours.redraw = function(opts:Dynamic) {
       hours.graphics.clear();
       this.graphics.lineStyle(2, Std.int(Math.random() * 0xFFFFFF), 1, true,
                                                       flash.display.LineScaleMode.NONE,
                                                       flash.display.CapsStyle.ROUND,
                                                       flash.display.JointStyle.ROUND);                
       var r = Math.min( Std.int((cast hours.parent).box.width)>>1, Std.int((cast hours.parent).box.height)>>1 );
       hours.graphics.moveTo(0,0);
       hours.graphics.lineTo(0,-.75*r);
}

Which is I guess what you are getting at, but it
uses haxe instead of hscript.  You only need to put the
keyword "dynamic" infront of your redraw proc to be able to do this.

Hugh



please see
http://haxegui.blogspot.com/2009/07/comparision-of-coding-styles.html, to
see a demo of the same thing written in both haxe and hscript, hopefully
making more sense into our script usage...



On Wed, Jul 15, 2009 at 3:00 PM, Hugh Sanderson <[hidden email]>wrote:

Hi,
Just looking at haxegui, and the use of hxscript.
I think you are using hxscript a bit too much.
Don't get me wrong - I think it is a good idea,
but I think it should be optional.  More for uis specified
by XML from a rad tool, eg

<button id="ok" mouseClick="Main.go()">Ok</button>

but not:
var button = new Button("Ok");

button.mouseClick = "Main.go();";

instead:

button.mouseClick = function() { Main.go(); }

And then use a helper function: something like:

button.mouseClick = Script.create("Main.go();");

So for a small amount of extra keyboard typing, you
get compile-time checks, and extra syntax options without
losing you scripting ability.

You could even take a "Dynamic" and check to see if
it is a string or a function (actually, maybe you are
already doing this ?).

If you are coding the ui with class files, then you certainly
want to use real haxe.  If you are reading from an
XML file, then creating the script is only done in one
place, so there is no issue there either.

I like the idea of this project, I hope this helps.

Hugh

--
haXe - an open source web programming language
http://haxe.org




--
haXe - an open source web programming language
http://haxe.org


--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: my first public post to the list, pet project got a page at last

Russell Weir
The system, yes, is entirely hscript... so yes, although haxe dynamic methods work
just fine, we can't use them if we want to define the actions from arbitrary text, as
we can using hscript. This will allow the introspector to also become the code input
window for all the scriptable events on a control as well.

This means we can change any appearance, mouse or keyboard event, data event,
literally anything, right in the running gui, then export to XML on the fly.

Yes, we lose haxe type checking and compiling, but I think the tradeoff is worth it.
Hscript is certainly fast enough for the gui.

Now just have to do something about that processor hog stats window... ;)

R


On Wed, Jul 15, 2009 at 11:32 AM, gershon <[hidden email]> wrote:
agreed, only i have to check with Russell why was it that we changed dynamic methods, and are now overriding...

another reason i wrote it like that is to keep it along the general style of haxegui, which does use multiple classes per file, the StyleCompiler  looks for a directory with the class' name, and collects all .hscript files to proper xml <script> tags.

could be seen as a 4th way of doing it, and it keeps code organized, minimal and dependent.

so in this example, had i wanted to use that 4th way, i could move all init() functions to onLoaded.hscipt and redraw() to redraw.hscript, and have:

assets/styles/toys/AnalogClock/redraw.hscript
assets/styles/toys/AnalogClock/onLoaded.hscript

assets/styles/toys/HoursHand/redraw.hscript
assets/styles/toys/HoursHand/onLoaded.hscript
...
...
...

leaving me with bare-bone, readable classes, and easy to change actions, with no need to endlessly scroll down to find that specific one...

10x for the feedback, though next time please use the blog's comments, this thread is too general



On Wed, Jul 15, 2009 at 7:11 PM, Hugh Sanderson <[hidden email]> wrote:
Hi,

I guess i agree with this:

please note, that had this not been a demonstration, i would have probably gone with a 3rd hybrid coding style, using hscript in the haxe .hx file, instead of multiple classes...

except change "hscript" to "haxe callbacks".

eg:

hours = new Component(this);
hours.init();
hours.redraw = function(opts:Dynamic) {
       hours.graphics.clear();
       this.graphics.lineStyle(2, Std.int(Math.random() * 0xFFFFFF), 1, true,
                                                       flash.display.LineScaleMode.NONE,
                                                       flash.display.CapsStyle.ROUND,
                                                       flash.display.JointStyle.ROUND);                
       var r = Math.min( Std.int((cast hours.parent).box.width)>>1, Std.int((cast hours.parent).box.height)>>1 );
       hours.graphics.moveTo(0,0);
       hours.graphics.lineTo(0,-.75*r);
}

Which is I guess what you are getting at, but it
uses haxe instead of hscript.  You only need to put the
keyword "dynamic" infront of your redraw proc to be able to do this.

Hugh



please see
http://haxegui.blogspot.com/2009/07/comparision-of-coding-styles.html, to
see a demo of the same thing written in both haxe and hscript, hopefully
making more sense into our script usage...



On Wed, Jul 15, 2009 at 3:00 PM, Hugh Sanderson <[hidden email]>wrote:

Hi,
Just looking at haxegui, and the use of hxscript.
I think you are using hxscript a bit too much.
Don't get me wrong - I think it is a good idea,
but I think it should be optional.  More for uis specified
by XML from a rad tool, eg

<button id="ok" mouseClick="Main.go()">Ok</button>

but not:
var button = new Button("Ok");

button.mouseClick = "Main.go();";

instead:

button.mouseClick = function() { Main.go(); }

And then use a helper function: something like:

button.mouseClick = Script.create("Main.go();");

So for a small amount of extra keyboard typing, you
get compile-time checks, and extra syntax options without
losing you scripting ability.

You could even take a "Dynamic" and check to see if
it is a string or a function (actually, maybe you are
already doing this ?).

If you are coding the ui with class files, then you certainly
want to use real haxe.  If you are reading from an
XML file, then creating the script is only done in one
place, so there is no issue there either.

I like the idea of this project, I hope this helps.

Hugh

--
haXe - an open source web programming language
http://haxe.org




--
haXe - an open source web programming language
http://haxe.org


--
haXe - an open source web programming language
http://haxe.org


--
haXe - an open source web programming language
http://haxe.org
12