3 ms·

Besides the mouse scroll wheel hack (which is only necessary for Macs if memory serves), what other limitations did you need to circumvent in order to address s

Besides the mouse scroll wheel hack (which is only necessary for Macs if memory serves), what other limitations did you need to circumvent in order to address scrolling in Flash? I've built more than my fair share of scrollbars over the years in Flash, and the JS-mouse wheel-mac hack is the only hack I've needed. I can imagine that building a custom scroll component in Flash would be easier to do, and the code would be far more clean, than implementing in JS. Am I wrong?

milestinsley 17y ago
I had problems with clicking on the track to jump the scroller to a given position. Also, I find that the memory resources used by Flash when the scroller contains a lot of objects is unacceptably high resulting in slow scrolling; therefore I had to waste time doing some funky lazy-loading stuff also. I would say that implementing custom scroller in JS is far easier (and reliable) that Flash. And there are plenty of frameworks (ahem Cappuccino) where such controls are included. But scrollers are just one example of the UI controls the article talks about :)
- jawngee 17y ago
  When you write desktop apps, you have to do the same thing - usually (lazy loading). I'm not defending flash, I'm just saying. When I used to do Win32 programming, I'd usually cache a bitmap and scroll that. For larger stuff though, lazy loading all the way.
- amadiver 17y ago
  Not to besmirch your AS coding abilities, nor to reopen old wounds, but the dev in me is begging some questions and debugging your comment. Your first issue seems like it was likely caused by using an incorrect ratio of viewable content to viewport height. I can't say I've ever seen the Flash player give erroneous info as to where the mouse was positioned, and Flash's Number type is accurate enough for this type of operation. The second issue seems more likely to have been an issue with processor load rather than a memory, I'm guessing? I usually solve the issue with using TextField's cacheAsBitmap property. It uses more memory, at the expense of greater processor load. I develop on a low-powered Mac, and have never been disappointed by the tradeoff, but YMMV. Sometimes, playing with the AntiAliasMode of the TextField has unexpectedly good results (processor-wise), but I admit it's very fiddly :) Completely agree on the framework front; Abobe's attempts to solve UI issues in Flash have lead to an even more fractured dev response. Cappuccino's UI looks extremely clean, and seem to function remarkably well, without sacrificing so much on the filesize/response vectors. Again, just geeking out; I've been (and continue to be) in that position more times than I'd like to count in developing for Flash. Thanks for the great comment :)

milestinsley 17y ago

I had problems with clicking on the track to jump the scroller to a given position. Also, I find that the memory resources used by Flash when the scroller contains a lot of objects is unacceptably high resulting in slow scrolling; therefore I had to waste time doing some funky lazy-loading stuff also. I would say that implementing custom scroller in JS is far easier (and reliable) that Flash. And there are plenty of frameworks (ahem Cappuccino) where such controls are included. But scrollers are just one example of the UI controls the article talks about :)

jawngee 17y ago
When you write desktop apps, you have to do the same thing - usually (lazy loading). I'm not defending flash, I'm just saying. When I used to do Win32 programming, I'd usually cache a bitmap and scroll that. For larger stuff though, lazy loading all the way.
amadiver 17y ago
Not to besmirch your AS coding abilities, nor to reopen old wounds, but the dev in me is begging some questions and debugging your comment. Your first issue seems like it was likely caused by using an incorrect ratio of viewable content to viewport height. I can't say I've ever seen the Flash player give erroneous info as to where the mouse was positioned, and Flash's Number type is accurate enough for this type of operation. The second issue seems more likely to have been an issue with processor load rather than a memory, I'm guessing? I usually solve the issue with using TextField's cacheAsBitmap property. It uses more memory, at the expense of greater processor load. I develop on a low-powered Mac, and have never been disappointed by the tradeoff, but YMMV. Sometimes, playing with the AntiAliasMode of the TextField has unexpectedly good results (processor-wise), but I admit it's very fiddly :) Completely agree on the framework front; Abobe's attempts to solve UI issues in Flash have lead to an even more fractured dev response. Cappuccino's UI looks extremely clean, and seem to function remarkably well, without sacrificing so much on the filesize/response vectors. Again, just geeking out; I've been (and continue to be) in that position more times than I'd like to count in developing for Flash. Thanks for the great comment :)