Hi Michael and all,

I'm not sure what you mean by webkit. Although, one I've found is this one at http://webkit.org/ an open source project.

I have used Moi on Linux but I find it generally a lot slower. But having Moi running 'natively' on Linux would be so cool (and useful).

Mark.

Hi Mark,

> I'm not sure what you mean by webkit. Although, one
> I've found is this one at http://webkit.org/ an open
> source project.

Yup, that's it.


> I have used Moi on Linux but I find it generally a lot slower.

Were you using a virtualization system?

The WINE system is not a virtual machine system, it actually loads and executes application code directly so if it works out it should likely be fast.

- Michael

Hi Micheal,

> Were you using a virtualization system?

No, just wine. I installed directx 9 to get Moi to run properly.

It may run slowly though because my system is P4 478 socketed PC. I'm upgrading soon so I'll let you know how the speed is then.

regards,
Mark.

P.S. I can try a virtualization install of Moi3d if the results would be useful?

Hi Mark,

> P.S. I can try a virtualization install of Moi3d if
> the results would be useful?

No, that's ok - I do know that MoI runs ok under virtualization on the Mac already.

- Michael

>No, it's using the regular JavaScriptCore engine (nitro) that normally goes with WebKit. But it does have the JIT engine enabled, it's fairly close in performance to V8.

Awesome! I've mostly been using node.js (which is built using V8), but I've also been keeping an eye on the Javascript arms race in general, so a nitro powered MoI should be pretty hot as well. It's too bad IE9 wasn't coming out about a year earlier, you might not have needed to go to all this trouble.

With all the raw scripting performance you're going to have in the new version, hopefully you'll be able to expose more functionality to the scripting API as well...

Hi Dave,

> It's too bad IE9 wasn't coming out about a year earlier,
> you might not have needed to go to all this trouble.

Well, IE9 doesn't run on Windows XP, so it would have been hard to make a dependency specifically on that.

Really the main reason why I'm switching over is to make for a more stable platform so that MoI's UI will run on the same engine on every installation, rather than depending on what version of IE is on any one particular Windows installation.

Having an increase in script performance is more of a nice side benefit...

- Michael

> Well, IE9 doesn't run on Windows XP, so it would have been hard to make a dependency specifically on that.

Doh! Forgot about that.

> Really the main reason why I'm switching over is to make for a more stable platform so that MoI's UI will run on the same engine on every installation, rather than depending on what version of IE is on any one particular Windows installation.

Sure, I get that. That will be a big win.

> Having an increase in script performance is more of a nice side benefit...

Well, I'm still hopeful about being able to do more with scripting in MoI, so WebKit/nitro sounds really exciting to me. Looking forward to trying this out sometime...

Hi Dave - also another nice benefit with being based off of a modern version of WebKit is being able to use CSS3 (with some extensions even) for the UI now. This allows for a lot more stuff like gradients and rounded corners, etc... Previously that sort of stuff was done by lots of little images.

- Michael

> Hi Dave - also another nice benefit with being based off of a modern version of WebKit is being able to use CSS3 (with some extensions even) for the UI now. This allows for a lot more stuff like gradients and rounded corners, etc... Previously that sort of stuff was done by lots of little images.

Yes, that will be extremely useful. I've been busy stocking up my library with HTML5, CSS3 and Javascript books for a while now (for other projects). The <canvas> element could also prove useful for creating custom UI components as well. I'm really looking forward to getting under the hood of this new MoI version...

Hi Dave, so the only caveat is that I've got a few different chunks of WebKit disabled in order to reduce the size of the installer.

An increase in installer and download size is the major downside to switching over to the engine being included with MoI.

<canvas> does work though, but I have SVG disabled.

- Michael

> Hi Dave, so the only caveat is that I've got a few different chunks of WebKit disabled in order to reduce the size of the installer.

> An increase in installer and download size is the major downside to switching over to the engine being included with MoI.

> <canvas> does work though, but I have SVG disabled.

Hmm, I wouldn't think that could be more than a few megabytes plus or minus. Even here in the Philippines, that isn't anything to worry about. Downloading modo 501 was around 2 GB, and that didn't take all that long. Well, it's your call, but I for one would vote for providing as much function as possible. I realize you probably won't need all the bells and whistles (like SVG) for the core MoI support, but it sure seems like it opens up lots of 3rd party possibilities if you throw in the kitchen sink :-)

Hi Dave, well a few megabytes to me is significant. Just in general I place quite a bit of value on having a nice lightweight download and installation. It is true that is not valued by a lot of developers anymore but I think that's a shame though.

It seems pretty unlikely that SVG would ever get used for UI - and UI is the thing that WebKit is used for with MoI...

If someone in the future comes up with some good use for SVG for MoI UI, then that could be possible to turn back on later on.

- Michael

> Hi Dave, well a few megabytes to me is significant. Just in general I place quite a bit of value on having a nice lightweight download and installation. It is true that is not valued by a lot of developers anymore but I think that's a shame though.

I hear you. I once lead a team that sweat blood to get a complete BASIC programming environment to run in 14KB (IBM System/34 BASIC, back in the day).

> It seems pretty unlikely that SVG would ever get used for UI - and UI is the thing that WebKit is used for with MoI...

I tend to agree with you. I'm planning to use <canvas> in some other projects I'm working on, but SVG has never really appealed to me, so I won't bemoan it not being there in MoI.

> If someone in the future comes up with some good use for SVG for MoI UI, then that could be possible to turn back on later on.

Fair enough. Are there any other major functional pieces of WebKit you are planning on leaving out?

Hi Dave,

> Fair enough. Are there any other major functional pieces
> of WebKit you are planning on leaving out?

There are some other various stuff - web workers, SQL Lite database storage, video support. To enable some of these things would involve pulling in additional support libraries as well.

> I'm planning to use <canvas> in some other projects
> I'm working on, but SVG has never really appealed to
> me, so I won't bemoan it not being there in MoI.

<canvas> seems to be getting used much more frequently for interactive type stuff.

(note to others - this is referring to SVG not so much as a file format, more about its dynamic scripting object model and event handling, etc... )

- Michael

> There are some other various stuff - web workers, SQL Lite database storage, video support. To enable some of these things would involve pulling in additional support libraries as well.

More hmm...hopefully this is mostly just a matter of setting some build switches on your part and that your previous statement about presenting a compelling case for including missing WebKit components applies here as well. I'm not sure what having/not having these components means at this point, since I'm personally still trying to sort through how all these technologies fit together. But hopefully it will be easier to convince you to include one of these components than it would be to convince you to write 10,000 lines of new C++ code to implement some new MoI feature :-)

> <canvas> seems to be getting used much more frequently for interactive type stuff.

I've heard it argued that SVG presents a richer interaction model than <canvas>, since much of the DOM event handling model reaches down into and applies to the SVG elements, but I'm not really convinced. Seems to me that creating a <canvas>-based component should not be any harder than creating a custom component using any other GUI toolkit. I've got a couple of components I'm planning on implementing using <canvas>, so hopefully I'll have some first hand experience soon.

Hi Dave,

> More hmm...hopefully this is mostly just a matter of setting
> some build switches on your part

Well yeah that, plus also distributing the additional DLLs that depend on such features, that's the part that really starts to bloat up the installer size.


> But hopefully it will be easier to convince you to include one
> of these components than it would be to convince you to
> write 10,000 lines of new C++ code to implement some
> new MoI feature :-)

I would say that sounds pretty likely! :)

But also at some point I do want to have things set up so that MoI plug-ins could include C++ DLL code of their own mixed together with script.

Just in general there isn't as much of a concept that MoI scripts have to be in some high security sandboxed environment as in a regular web browser environment. So there are already a lot of stuff that you can do in a MoI script like access the Windows FileSystemObject scripting API which is not allowed to be accessed from a regular web browser for example.

- Michael

Hi Dave,

> I've heard it argued that SVG presents a richer
> interaction model than <canvas>, since much
> of the DOM event handling model reaches down
> into and applies to the SVG elements, but I'm
> not really convinced.

There just does not seem to be much action happening around interactive SVG - it seems that all the demos and frameworks that are popping up for games for example are using <canvas> instead.

It kind of seems to me like it has been a mistake to have both of these as completely separate things - something like a <canvas> that had a standard scene graph/metafile type library with it (that you could optionally use or not) that included hit testing would make more sense. That seems to be how things are going anyway with various libraries building on <canvas>.

- Michael

> Well yeah that, plus also distributing the additional DLLs that depend on such features, that's the part that really starts to bloat up the installer size.

Of course. Just thinking aloud about a future scenario where I dream up a really cool idea for a MoI plugin, but it needs WebKit component "X".

Perhaps once you're ready to start doing some customer alpha/beta testing you could provide a separate "developers only" download containing a set of drop-in replacement DLL's containing the full WebKit component suite for the more adventurous souls to work with. If nothing interesting seems to come out of it during the test phase, then they never make it into the final release build. Sounds like it might not be too much work on your part to set up. Just a thought...


> But also at some point I do want to have things set up so that MoI plug-ins could include C++ DLL code of their own mixed together with script.

Yeah! +1 for that.

> Just in general there isn't as much of a concept that MoI scripts have to be in some high security sandboxed environment as in a regular web browser environment. So there are already a lot of stuff that you can do in a MoI script like access the Windows FileSystemObject scripting API which is not allowed to be accessed from a regular web browser for example.

I just saw a codeplex project yesterday (Javascript .NET) that integrates .NET with the V8 engine. Something similar for Nitro could really open up the scripting API for MoI. Might be something I'll look into later...

> It kind of seems to me like it has been a mistake to have both of these as completely separate things - something like a <canvas> that had a standard scene graph/metafile type library with it (that you could optionally use or not) that included hit testing would make more sense. That seems to be how things are going anyway with various libraries building on <canvas>.

Well, the Web has been built on mistakes and false starts. In this case the overlap between SVG and <canvas> seems mostly harmless (except for the browser bloat). But Javascript JIT's/graphics libraries combined with hardware accelerated <canvas> sure seems to be the likely winner at this point...

Hi Dave,

> In this case the overlap between SVG and <canvas> seems
> mostly harmless (except for the browser bloat).

Well, the other harm would come just from considerable browser development time sunk into some area that may not pan out.

The level of complexity involved with the whole SVG object model seems to be pretty extensive, for example there are 491 files in WebKit's \svg folder... That's a huge amount of effort in development, testing, bug fixing, ...

Certainly it's true that it is hard to know in advance which particular technology is going to become highly used or not... But on the other hand having too many huge mechanisms implemented and needed to be maintained can make it harder for browsers to be nimble as well.

- Michael