Okay, this is a long way from being complete, but as an experiment it's pretty interesting -- same Fan code running either as an app or in the browser.
Couple issues in the browser; first, I need a repaint implemented on WidgetPeer.js. Without it I'm having to do a relayout on events, and so updates are very slow. Save the code and run it locally and you'll see what I mean -- it's instantaneous that way.
Another thing is, events: only mousedown was implemented, so I added handlers for up, over, out, move, mapped to the corresponding FWT events. The FWT hover and wheel events don't have an obvious JS analog that I know of.
I had to tiptoe around the JS natives that aren't implemented yet, but that's understandable. Overall I'm pretty impressed that it's as far along as it is. Once the JS implementation gets fleshed out and fully tested, this is gonna be a pretty impressive thing.
alexlamslTue 22 Sep 2009
Hmm - got a JS error under IE8 (Vista)
Webpage error details
User Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.0; Trident/4.0; SLCC1; .NET CLR 2.0.50727; Media Center PC 5.0; InfoPath.2; .NET CLR 3.5.30729; .NET CLR 3.0.30729)
Timestamp: Tue, 22 Sep 2009 00:03:12 UTC
Message: Object expected
Line: 1477
Char: 1
Code: 0
URI: http://www.kevinleekelley.info:8088/sys/pod/fwt/fwt.js
KevinKelleyTue 22 Sep 2009
Thanks for the info. I've been using Google Chrome and Firefox, haven't got to IE testing yet.
Cross-browser issues is probably going to be the big deal here, no surprise.
brianTue 22 Sep 2009
That's very cool!
Let's make sure we try to track everything you discover missing/wrong in JS-FWT so nothing gets swept under the rug.
Maybe just keep a running ticket with a bunch of bullets - I'll let Andy decide how he wants to handle it.
Hmm - got a JS error under IE8 (Vista)
Nothing has been tested in IE yet - our development has been in FF, Chrome, and Safari.
KevinKelleyTue 22 Sep 2009
running ticket with a bunch of bullets
Will do. Tomorrow, though.
andyTue 22 Sep 2009
Looks pretty sweet!
I haven't been able to keep up with IE at the moment, but the core runtime and FWT are known to work. The bugs are typically minor ones, like a trailing comma, or differences in the Event API. So I don't see any major hurdles in getting it up and running on IE7+ (IE6 will not be supported).
Yes, I would like to support Opera. I test less often than IE, but like IE there shouldn't be any major hurdles.
Last I checked, Opera does not support text on the HTML canvas, so that will not work completely. An option there is too fallback to using JavaFx/Flash like we do for IE.
Got to have Widget.repaint implemented for programmatic changes to UI. I'm using relayout to get an update, but of course that's (relatively speaking) dog-slow.
fwt::Event.pos is relative to the containing widget; but dom::Event.x and y (which get converted into fwt::Events) are relative to the browser page.
assigning a new string to a UI label's .text ought to trigger a repaint, and doesn't. (I think this applies in general: assignment to a visible field of a UI element ought to automatically onPaint it)
Not sure about this one, but Combo doesn't seem to be acting right -- don't seem to be getting onChange events. Haven't investigated it yet tho.
In Firefox at least, font.width throws, and font.toSize doesn't give the requested size.
Unimplemented APIs:
Range.each, Range.contains
StrBuf.get and StrBuf.set
List.size field setter (one-shot allocate an array of null)
StrBuf.join -- this one was hard to track; I'd get an exception in event-handler code, and try to use catch (Err e) {echo(e)} which would then fail in Event.toStr, with a "there is no join function" error.
Sudoku solver is a good test for browser JS capabilities: there's a hard "core" of algorithm code, and a non-trivial front end UI.
As to the core: the current implementation, which runs nicely fast, the algorithm uses a sparse matrix implemented with a 730-element and a 324-element List of row and column header nodes, and about 3200 dynamically-allocated (once at page load) constraint nodes.
As a simpler first step I implemented the constraint matrix as a 730x324 = 230K-element 2D array; it worked, but sent the browser into "page unresponsive" mode for a couple minutes on startup. Running as a Fan app, that implementation started with hardly noticeable delay. So, JS in browser is pretty good, but be careful with heavy code. If you do something that isn't supported well, it can easily be a couple orders of magnitude slower than "real" code.
As to the UI side, the main issue is cross-browser support for the HTML Canvas; the biggest problem with that (aside from missing repaint ) is in using fonts. Firefox for example seems not to want to give me the font size/style I ask for; also it throws exceptions on measuring a string.
Webkit-based browsers seem to do pretty good with it. Fonts are clean, and speed is high. In fact I kicked off a Safari daily-build (current) and was surprised: it seemed a lot faster yet than the release browser.
Widget.repaint is a bit hairy, since we don't have a true repaint (outside of Canvas). The current implemention should be more performant than a relayout, but still has room for optimization. I'll have to look at the code for each widget to minimize reflows.
Auto-repainting when setting display properties falls into this category as well. I'll need to spend some time looking at how it behaves with the rendering engine before I fix.
KevinKelley Mon 21 Sep 2009
Okay, this is a long way from being complete, but as an experiment it's pretty interesting -- same Fan code running either as an app or in the browser.
Couple issues in the browser; first, I need a
repaintimplemented on WidgetPeer.js. Without it I'm having to do arelayouton events, and so updates are very slow. Save the code and run it locally and you'll see what I mean -- it's instantaneous that way.Another thing is, events: only
mousedownwas implemented, so I added handlers forup,over,out,move, mapped to the corresponding FWT events. The FWThoverandwheelevents don't have an obvious JS analog that I know of.I had to tiptoe around the JS natives that aren't implemented yet, but that's understandable. Overall I'm pretty impressed that it's as far along as it is. Once the JS implementation gets fleshed out and fully tested, this is gonna be a pretty impressive thing.
alexlamsl Tue 22 Sep 2009
Hmm - got a JS error under IE8 (Vista)
KevinKelley Tue 22 Sep 2009
Thanks for the info. I've been using Google Chrome and Firefox, haven't got to IE testing yet.
Cross-browser issues is probably going to be the big deal here, no surprise.
brian Tue 22 Sep 2009
That's very cool!
Let's make sure we try to track everything you discover missing/wrong in JS-FWT so nothing gets swept under the rug.
Maybe just keep a running ticket with a bunch of bullets - I'll let Andy decide how he wants to handle it.
Nothing has been tested in IE yet - our development has been in FF, Chrome, and Safari.
KevinKelley Tue 22 Sep 2009
Will do. Tomorrow, though.
andy Tue 22 Sep 2009
Looks pretty sweet!
I haven't been able to keep up with IE at the moment, but the core runtime and FWT are known to work. The bugs are typically minor ones, like a trailing comma, or differences in the Event API. So I don't see any major hurdles in getting it up and running on IE7+ (IE6 will not be supported).
helium Tue 22 Sep 2009
This is what it looks like in Oprea.
Will Opera be supported in the future?
andy Tue 22 Sep 2009
Yes, I would like to support Opera. I test less often than IE, but like IE there shouldn't be any major hurdles.
Last I checked, Opera does not support text on the HTML canvas, so that will not work completely. An option there is too fallback to using JavaFx/Flash like we do for IE.
andy Tue 22 Sep 2009
Pushed Kevin's patch for mouse events.
changset
KevinKelley Tue 22 Sep 2009
Some notes on JS.
Fan vs. JS implementation differences:
Widget.repaintimplemented for programmatic changes to UI. I'm usingrelayoutto get an update, but of course that's (relatively speaking) dog-slow.onPaintit)font.widththrows, andfont.toSizedoesn't give the requested size.Unimplemented APIs:
catch (Err e) {echo(e)}which would then fail in Event.toStr, with a "there is nojoinfunction" error.Sudoku solver is a good test for browser JS capabilities: there's a hard "core" of algorithm code, and a non-trivial front end UI.
As to the core: the current implementation, which runs nicely fast, the algorithm uses a sparse matrix implemented with a 730-element and a 324-element List of row and column header nodes, and about 3200 dynamically-allocated (once at page load) constraint nodes.
As a simpler first step I implemented the constraint matrix as a 730x324 = 230K-element 2D array; it worked, but sent the browser into "page unresponsive" mode for a couple minutes on startup. Running as a Fan app, that implementation started with hardly noticeable delay. So, JS in browser is pretty good, but be careful with heavy code. If you do something that isn't supported well, it can easily be a couple orders of magnitude slower than "real" code.
As to the UI side, the main issue is cross-browser support for the HTML Canvas; the biggest problem with that (aside from missing
repaint) is in using fonts. Firefox for example seems not to want to give me the font size/style I ask for; also it throws exceptions on measuring a string.Webkit-based browsers seem to do pretty good with it. Fonts are clean, and speed is high. In fact I kicked off a Safari daily-build (current) and was surprised: it seemed a lot faster yet than the release browser.
andy Wed 23 Sep 2009
Fixed a few things:
Widget.repaint is a bit hairy, since we don't have a true repaint (outside of Canvas). The current implemention should be more performant than a relayout, but still has room for optimization. I'll have to look at the code for each widget to minimize reflows.
Auto-repainting when setting display properties falls into this category as well. I'll need to spend some time looking at how it behaves with the rendering engine before I fix.
KevinKelley Wed 23 Sep 2009
Great news, I'll try this stuff out today.
andy Thu 24 Sep 2009
font.width should be working now - see #760.
andy Fri 2 Oct 2009
Added support for Combo.onModify - changeset