Tcsc, I’ll need to.

Pio: I get that if I’m changing the this context, but I never reference this from those functions

Shahinian: IIRC, bind is so complex that it cannot be entirely polyfilled.

Thomlison: Dolby, I suppose I could refactor to use your pattern without too much work, it just seems like such a to-do

Asencio: Well, the spec for Function#bind is two whole freaking pages.

Creswell: Maybe I’ll just have faith that its optimization will be improved in newer engines

Bowgren: Yeah, it does *a lot*

Empleo: Jkoudys: if the usage isn’t affecting your performance, you don’t really need to care about it. Otherwise, you can use more static things, like the partial2 function above

Shahinian: Scary stuff:

Ornelaz: Wow, “don’t use this in production because it’s weird”

Grensky: Dolby, my latest profiles show the overhead is _way_ in canvas rendering, hence why I’m looking at optimizing that now

Kapler: It’s about 99% of the CPU for regular execution

Ornelaz: Wow, thats crazy, it shouldn’t be nearly that bad

Gadbaw: Tcsc, it may not be that it’s bad, just that the rest of the code is really low-impact

Adil: Keep in mind it’s running instructions originally intended for a 4MHz cpu, and one that’s waiting on interrupts for a good chunk of that to save power

Ornelaz: I doubt it, it has to be telling you to update something

Cetta: Yeah, because every cycle is rendering. That’s the first optimization I’m doing right now

Quillian: Just a flag to not re-render unless the VRAM has been updated

Ornelaz: Are you doing putImageData on an onscreen canvas?

Ornelaz: Because you should do 100% of your rendering onto an off screen canvas, and then do drawImage at the end with that

Merling: Tcsc, no, putImageData is for my offscreen canvas. It gets drawImage’d to my visible canvas

Lavigne: Help! line 6 is throwing me an error “unexpected value ’s’ “, which is the first character in pageValue. why is that?

Ornelaz: Do you clearImage befroe doing putImageData

Brodigan: But I am just thinking about webgl right now, and how much more fun it would be to try that out now, so I might just drop all that code by tomorrow

Ornelaz: Because you should use a separate canvas

Ornelaz: Put imagedata on that

Oser: Tcsc, no I don’t clearImage

Ornelaz: Then it has to read pixels first

Ornelaz: Which is a very slow operation

Ornelaz: If you want to do webgl you might see a speed up, but you wouldn’t if you’re going to need to do pixel manipulation a lot

Roers: Tcsc, I’m also applying a pixel shader for my scaling algo, so it’ll hit webgl eventually

Pinkstaff: Writing a scaling algo in pure JS 2d canvas was absolutely painful and absurdly slow

Ornelaz: Oh you’re not doing nearest neighbor?

Ornelaz: Yeah for that probably you will want to make the gpu do it

Mcgarrity: Tcsc, putting in this sweet scaler:

Ornelaz: I love shadertoy so much

Gipple: Yeah I just discovered it. I’m not really a graphics guy, but I’m really enjoying the chance to declare floats in a webapp. This’ll be my first webgl project ever

Ornelaz: You will want that to be an option though, since thats a nontrivial amount of work for a shader, and on my laptop hovers between 40 and 60fps

Westendorf: Tcsc, absolutely – it’s not even desirable for every game

Ornelaz: The guy that made shader toy’s website has all sorts of great articles about graphics too:

Hannay: Tcsc, I’ll need to eventually support some of the later-day techniques that really pushed the limits of the GPU, e.g. this guy who rendered a bump-map renderer on a gameboy: