3 ms·

"Does every single screen need to have 60 fps animations, with activities that launch from the exact x/y coordinate where my finger touches the screen?" This m

by Koromix 10y ago

"Does every single screen need to have 60 fps animations, with activities that launch from the exact x/y coordinate where my finger touches the screen?" This makes it sound like smoothly animating a few rectangles is hard. The only reason it is true is because the web stack is, for lack of a better word, complete crap. It was fine for rendering static text and a couple images with no graphics acceleration, I guess. Today, AAA games can redraw complete frames of 3D worlds inside of 16.66ms (along with processing physics / gameplay / networking / input) and I'm supposed to accept slow and janky GUIs on my desktop? I just can't. I tried Atom, and even though it's usable, it's not exactly snappy. The complete waste of my hardware's resources makes me too sad to enjoy any good feature it might have. The web is stuck with this, that's "fine" but could we keep the desktop out of it?

iamleppert 10y ago
Why do you think its so bad? Javascript and HTML are plenty fast, and if need something faster you have access to a raw GL context and associated APIs.
- Koromix 10y ago
  They are not plenty fast. You know you don't have a fast platform when the best you can do is scroll + a couple animations at the same time. And even then, HTML+JS apps often cannot do that without lag. Not saying that native apps are necessarily better (especially on Android), I die a little inside each time I unlock my phone and the unlock screen fails to keep up with my finger. We had smooth scrolling in the late eighties on the Amiga 2000 (7 Mhz and 1MB of RAM) with CygnusEd: https://www.youtube.com/watch?v=L41oIvre9K0 https://www.youtube.com/watch?v=L41oIvre9K0 The fact that we barely manage to do that with HTML+JS on what amounts to supercomputers (relative to the time) should not make anyone proud.
- wrl 10y ago
  If your plan for speeding up a slow user HTML/JS interface is to rewrite parts using WebGL, you're severely underestimating the amount of support code you'd need in order to make that happen. Coming from somebody who has developed and maintains OpenGL user interfaces, you're better off just writing the native app.

by Koromix 10y ago

iamleppert 10y ago

Why do you think its so bad? Javascript and HTML are plenty fast, and if need something faster you have access to a raw GL context and associated APIs.

Koromix 10y ago
They are not plenty fast. You know you don't have a fast platform when the best you can do is scroll + a couple animations at the same time. And even then, HTML+JS apps often cannot do that without lag. Not saying that native apps are necessarily better (especially on Android), I die a little inside each time I unlock my phone and the unlock screen fails to keep up with my finger. We had smooth scrolling in the late eighties on the Amiga 2000 (7 Mhz and 1MB of RAM) with CygnusEd: https://www.youtube.com/watch?v=L41oIvre9K0 https://www.youtube.com/watch?v=L41oIvre9K0 The fact that we barely manage to do that with HTML+JS on what amounts to supercomputers (relative to the time) should not make anyone proud.
wrl 10y ago
If your plan for speeding up a slow user HTML/JS interface is to rewrite parts using WebGL, you're severely underestimating the amount of support code you'd need in order to make that happen. Coming from somebody who has developed and maintains OpenGL user interfaces, you're better off just writing the native app.