var speed = parseFloat(wivCurve.parentNode.dataset.wivSpeed)
var height = parseFloat(wivCurve.parentNode.dataset.wivHeight)
var tightness = parseFloat(wivCurve.parentNode.dataset.wivTightness)
var thickness = parseFloat(wivCurve.parentNode.dataset.wivThickness)
var ctx = wivCurve.getContext("2d");
do this once on init, the canvas context remembers it anyway:
don't convert numbers and strings all the time, use numbers and init them to 0
//current frame is tracked on per wiv basis. This is to help with speed calculations
if (parseFloat(wivCurve.dataset.count) > 100000) {
wivCurve.dataset.count = "0";
}
wivCurve.dataset.count = (wivCurve.dataset.count ? parseFloat(wivCurve.dataset.count) : 0) + speed;
parseFloat(wivCurve.dataset.count) also is used a lot in that loop.
And don't set unneccessary canvas state, this should happen only once per draw loop iteration: [edit, actually, as I said above, the canvas contexts remember it individually, so do this once in initWiv(), and not in the draw loop at all, yay!]
ctx.lineWidth = thickness;
That's all just at first glance, but I bet you, this would help with slow laptops and whatnot :) Such "small" things really add up when you do them 60 times per second * number of borders. I don't know if setting the canvas width or height to the value it has anyway to clear it (instead of clearing/drawing a rectangle explicitly) is still a useful thing to do, but you might try that as well.
This is guilt-trippingly sweet, there's a certain charm I get from this, kind of like that of tacky Christmas sweaters or unironically used comic sans :)
I suspect that Firefox is relying on modern-ish GPU features to make things "fast", but Mesa is straining the CPU to emulate those features, which are missing from your older GPU. (Software going "I'll use the GPU, that must make things faster!" is what finally pushed me away from using an x60 as my daily driver).
Well... I've been thinking a lot about this terminology.
On one hand it is useless/oldschool/ugly/trash/weird kind of effect, but on the other hand it can be extremely effective (like described in motivation of my quirky-ux (see talk by Vitaly Friedman of smashingmagazine)).
tl;dr ...websites with a lots of character which break best practice guidelines and design rules are able to capture audience better and produce better results (turnover, traffic, user retention, etc.)
So I ended up finding a neutral sounding word:
QUIRKY - having or characterized by peculiar or unexpected traits or aspects.
I would gladly reformat quirky-ux to be primarely this collestion/list of quirky stuff, but maybe awesome-quirky makes more sense or awesome-quirky-ui or something similar...
Cool. I would say awesome-quirks sounds a bit better and also avoids the confusion with the meaning of quirks mode, the compatibility feature of browsers. I have created the list: https://github.com/dsalaj/awesome-quirks
Please contribute! If you really prefer the name awesome-quirksmode I have no problem with renaming the repo or adding you as a contributor so you can do it. Thanks for the feedback!
It can be use for form validation. If user doesn't enter an input, we can "wiggle" it for 2 seconds (together with a red error message). Recently I did just that :)
(edit: this assertion is incorrect, I skimmed the code too fast) I had no idea that you can draw on any element, not just canvas ones ... I thought there was a semantic meaning there ... apparently there isn't?
Ah yes I missed the var canvas line and just presumed the code was getting a context on the selected div instead, a feature I didn't know was possible (it isn't).
The canvas declaration is staring right at me now that I review it again. That's life...
Browsers are getting too feature laden. Soon nobody will be able to write a browser from scratch. Instead, let users implement the features they need, or let them use libraries if necessary.
Yes, sure, but thIs is one of those things we don't realise should be a core, kernel-level feature until it's put on our Christmas dinner plate (by all means keep things like security/auth/etc in libraries)
And don't set unneccessary canvas state, this should happen only once per draw loop iteration: [edit, actually, as I said above, the canvas contexts remember it individually, so do this once in initWiv(), and not in the draw loop at all, yay!]
That's all just at first glance, but I bet you, this would help with slow laptops and whatnot :) Such "small" things really add up when you do them 60 times per second * number of borders. I don't know if setting the canvas width or height to the value it has anyway to clear it (instead of clearing/drawing a rectangle explicitly) is still a useful thing to do, but you might try that as well.