lazy rendering

[Aeva]

This would be an alternative to pipeline, or maybe just an alternative mode, wherein you define which browser events that you want to trigger the pipeline to update the scene. This is necessary for games that are designed to be able to run on slower machines, for which repeatedly rebuilding the scene on every frame is costly and unnecessary.

[wijnen]

This would probably help. If it isn't too hard, I'd also really like to see the non-canvas approach that uses divs; by skipping rendering passes, ganis would probably not animate as well. Perhaps the "root" element (currently a canvas) should be a div and depending on the user requesting 2-D or 3-D rendering, it gets many divs or a single canvas as a child node, generated by m.grl?

[Aeva]

The main problem with a non-gl mode is that everything currently is integrated pretty directly into webgl, and the code is organized to do that well. I am interested in a 2D mode, but I still need to work out how that would work exactly.

Whereas, I think lazy rendering would have fixed the performance problems you were having last weekend + would have allowed you to explore using 3D assets. But you are right, this doesn't play well with animations.

Another way the 2D mode could work is utilizing the html overlay functionality. Gani objects could be rendered and animated there, but then the level could be rendered using lazy evaluation. That would allow for animation of characters, while still allowing for things like compositing effects and the like to be applied to the background at least.

[wijnen]

I tried using text overlays during the weekend, but it pretty much made Firefox hang. That's why for the story parts in the game, I hide the canvas and use a div. So I'm not sure how well that will work.

Anyway, I'm happy to have a look at it to see if I can come up with a proposal, but only if you are open to it. I'd understand if you like things the way they are, because my guess is that it would add code all over the place. Then again, it may be possible to keep it largely separated.

Please let me know if I should work on a proposal.

[Aeva]

Without lazy rendering, it has to recalculate the position of the div overlay every frame, so this is not entirely surprising.

I am interested in what you would propose, but I cannot promise that I will run with it. I do want m.grl to be able to be useful on less capable machines, but if the proposal would require a dramatic amount of rearchitecting, it won't be feasible to implement in the near term.

[wijnen]

On Fri, Aug 28, 2015 at 11:38:49AM -0700, Aeva Palecek wrote:

I am interested in what you would propose, but I cannot promise that I will run with it.

Of course; it's a proposal, not a command. ;-) My point was that if you are already know it's unlikely that you'll incorporate it, I wouldn't bother looking at it.

I do want m.grl to be able to be useful on less capable machines, but if the proposal would require a dramatic amount of rearchitecting, it won't be feasible to implement in the near term.

Knowing myself, the proposal will probably be in the form of an implementation, if at all possible. I'll have a look what I can come up with.

[Aeva]

closing this issue for now until somebody calls for it lol