Fork me on GitHub

I know that with canvas you can clear just rects and rerender only portions of the screen. However, I'm wondering -- with canvas, is it possible to get 60fps by clearing the whole screen on every frame? I.e. using canvas as if it's OpenGL with a draw entire scene every frame. Is this achievable, or is this still too slow?


It will probably depend a lot on what you want to draw and on which device. In worse case your frame-rate drops. You could even make a function to detect a drop in frame rate, and then either set it fixed to less then 60, or start drawing less.


>is it possible to get 60fps by clearing the whole screen on every frame There were also technics to getting better optimizations by using buffer / invisible canvases, etc…


hidden canvases is very interesting


suppose what I'm rendering to screen is a datasructure formed as a tree


I can imagine sttaching meta objects to certain subnodes of the tree, which contains "a cache of what this subpart of the tree renders to" and using that to reduce overall render time


Hi, how do I convince my coworkers living in java and class based world of data driven development?


I got the feeling I am always hitting kind of a wall when talking about it as these concepts are so different and people just dont understand what I mean or can not see the value.


@sveri: I think the two easiest solutions to get coworkers that use clojure are: (1) apply to cognietct / juxt OR (2) start a company and only hire clojurians


I dont want my coworkers to use clojure, at least thats not the goal. Its hard talking about concepts when others dont have a clue about the direction I want to go in.


But other than that, the solution to switch jobs might still apply, thats true


I don't work for cognitect; I don't own cognitect stock. The other thing to keep in mind is: would you rather work with (1) people who don't even see the importance of FP or (2) people who invented clojure, clojurescript, datomic, om, and god knows what else


@sveri: I once had to implement a feature that would work in slightly different ways for different customers. The business also wanted to be able to easily tweak the parameters of the feature. It was pretty easy to sell the data-driven approach there — we just stored all the parameters in a lookup table which the business could change on their own, then had a thin wrapper around it in the Java code which we didn’t have to re-deploy just to try out a different variation.


also testing was much easier once we externalised all the interesting parameters to data


sveri ask them to have an internal competition running


come up with standard questions from great interviews like the one where you need to spiral print a matrix


and show them how clojure implementations are usually 10-100x less code


a smart software engineer understands this and sees it as an advantage


@sveri there's a great talk about that I'll try to find: the gist it's really really hard. The harder you push against the resistance the more you run the chance of them blaming you whenever something goes wrong with your code.