[PLUGIN] Canvas

that would kind of defeat the whole purpose of using it, don't ya think? You could just use a smaller canvas.he idea is to build some kind of sprite sheet at runtime, out of many other sprites. I figured dealing with a single canvas would be better than several sprites. I suppose i could use multiple small canvases instead...

tulamide

That memory leak comes from the texture not being freed when the canvas is destroyed. It only occurs on xp with webgl on and I can't fix it... but I'm not sure why.

In other news I had a go at making a proper webgl fix and ran into too many issues to get it to work. C2's runtime isn't designed for it and I lack the technical knowledge, ability and time to get something working. So for the foreseeable future my recommendation is to use the plugin with webgl off for the best speed.

Alpro

I suppose it's doable but it doesn't really fit in with the canvas' purpose. Pasting a canvas with the spritesheet to a smaller one is a cleaner solution imo.

Paradox

I'm not offended at all. That's one nice looking icon. I'll include it in my next update. Thanks.

rojohound

Thank you for your effort! Also, with XP currently at around 20% market share and falling, this won't be much of an issue in future.

It keeps being a good and useful plugin <img src="smileys/smiley1.gif" border="0" align="middle">

R0J0hound

Thanks for taking a look at a full WebGL fix. Even without a full fix, the improvements so far have been great.

Is this something that Ludei could actually address from their end, or would the fix have to come from the plugin?

rojohound

Minor issues:

1) Using floats, as for example created by random(), in the color fields of the gradient function produces a javascript error.

For example:

"rgb(" & random(255) & ", 128, 128)" outputs a "...line 493 (col undefined)" error

"rgb(" & round(random(255)) & ", 128, 128)" works as expected (and any other expression generating an integer)

2) The gradient style "horizontal" reads "hoizontal".

3) Using floats, as for example created by random(), in the color field of the fill function does not produce a javascript error, but isn't working either. The canvas will be filled with black instead of the specified color.

For example:

"rgb(" & random(255) & ", 128, 128)" fills with black

"rgb(" & round(random(255)) & ", 128, 128)" works as expected

4) Using floats, as for example created by random(), in any field of the floodfill function does not produce a javascript error nor fill with black, but isn't working either. Javascript doesn't answer anymore and one can only stop the script.

For example:

random(100) in the x or y field, "rgb(" & random(255) & ", 128, 128)" in the color field, all lead to the script having to be stopped

round(random(100)) in the x or y field, or "rgb(" & round(random(255)) & ", 128, 128)" work as expected.

There may be other functions as well with inconsistencies, but I only tested those three.

I propose that all functions behave the same. If it isn't possible to convert float to int within the plugin, then it would be best to just draw black. If you feel uncomfortable with just drawing then all three should output a javascript error.

tulamide

I'm not real surprised browsers can be somewhat picky, and random goes all the way to the 14th space, which does seem a little excessive.

Honestly you should just be happy you can get away with not having to add a str() on there as well. heh

newt

<img src="smileys/smiley2.gif" border="0" align="middle" />

Serious, I do agree as far as I'm concerned. I certainly don't care much if I use random() or int(random()). It's the plugin showing different behaviors for the same issue that I wanted to point out. From a programmer's point of view, so to say. A consistent behavior can help much tracking down possible issues. I hope that I didn't instead leave the impression of being picky <img src="smileys/smiley9.gif" border="0" align="middle" />

picky

picky <img src="smileys/smiley19.gif" border="0" align="middle" />

tulamide

I wouldn't say you are being overly picky, Rgb should accept decimals, in fact the alpha channel goes from 0 to 1.

clrammer

It is something that would have to be fixed on the plugin side.

tulamide

That's not picky at all. I fully agree its ideal to have consistency. I'll shoot for the default behavior for an invalid color to use black instead as this is what html5 does. Gradient and fill should handle colors the same way. I'll have to see why gradient causes an error. Flood fill is a bit different as internally it uses numbers instead of a string. I should be able to fix that. Also thanks for pointing out the typo with horizontal.

I'll try to get an update out sometime this week. Keep up with the bug reports and feature requests.

newt

Actually the HTML colors only take integers for rgb colors even though alpha is a float. Right now the colors are passed as is. I'd prefer not to have to do analysis on the string if I can before passing it.

R0J0hound

I understand completely, especially after all that trouble I gave you with Firefox reading pixels wrong.

Thanks for still updating this.

I just noticed another thing relating WebGL performance in Windows.

In native Chrome the performance for me is great, with 250 fps with vsync disabled and 60 fps when enabled. Almost no performance hit when drawing to canvas every tick. In both Node-Webkit and Firefox, however, the frame rate drops to around 30 fps.

I wouldn't be surprised if Firefox did something different, but I wonder why the performance is so much worse in Node-Webkit compared to Chrome, as it supposedly uses the same render engine.

After the latest update, this only happens when clearing/updating the canvas (which I unfortunately do every tick). The performance is better with WebGL off, so it seems related to WebGL.

Any ideas what's causing this? Could it be related to the original WebGL issue?

I wouldn't be surprised if Firefox did something different, but I wonder why the performance is so much worse in Node-Webkit compared to Chrome, as it supposedly uses the same render engine.

it seems chrome dropped webkit and uses their own engine, `blink` or `binge`, something like that.

SirSpunky

It is most likely the webgl issue. If the performance is high then canvas2d isn't being used. If performance is low then webgl is being used. Different browsers have decide differently whether or not to use webgl or canvas2d depending on your graphics card. Node-webkit tries to force webgl to be enabled which may differ from what chrome usually does.

In other news... A NEW RELEASE. Download on first post.

[change] New icon thanks to paradox.

[fix] Invalid colors would break "gradient fill" and "flood fill".

• The default behavior when using a invalid color is black is used.

[add] Added expressions to get individual components from colors: red,blue,green, alpha.

[fix] A typo fix and a few other fixes that I don't recall.