Communism – Capitalism
overanxious – carefree
gas – electricity
Neither extreme is good. But there's more than just black and white!
It's hybrid-time! …
beta 6:
unbelievably (even to me! :lol:) improved the dragging performance of the scroll bars :up:
Looks to me like it's ready for an RC soon. What do you think? 🙂
beta 5:
I added the possibility to scroll elements via the arrow keys. In contrast to the mouse wheel implementation I decided not to start scrolling the page when the element reaches the top / bottom since you usually only intend to scroll this particular element if you click it (There's one little moment of scrolling happening to the page which is needed for modern scroll to realize that the element finished scrolling).
I once again stripped down the scrolling function for the arrow keys. There's just one single calculation left: the amount of scroll to be done. So that's as minimalist as it can possibly get :up:
For those of you who are wondering right now what that intro has to do with modern scroll, here's the answer: 😉
Iframes don't leave any choice, but to use solution number two (referring to the last post) cause it's the only way to get rid of the standard bars whereas the normal page's performance is better with solution number one.
That's why I hereby made modern scroll "bi-solutional" 😆
It hopefully resolves most of the issues and speeds up things again.
I additionally rewrote parts of the scrolling functions to get maximum performance out of them and tried to implement the needed "modal"-awareness (the main page used to scroll, too whenever an inner element was scrolled).
I think it's a huge step into the right direction :up:
Let me know about your experience with it 😉
Augmented Utility 
Comments on: "modern scroll 1.5 beta 4 – 6" (43)
:cheers: Great!
Long time no performance improvement in Opera, glad at-least you are doing your job good. 😆
Sure :chef:
Let's see now if this does improve things.
Originally posted by Acryion:
Terrific! That's what I hoped to hear :love:Originally posted by Acryion:
There's no choppiness for me (and I'm using a really cheap low-end laptop…). But even if it was noticeable to me: I can only work with what Opera can deliver. I'm always trying to optimize performance of each and every scrolling function so I guess that's the best it will get (with the knowledge that I possess at the moment) 😉
By Extension Tab I mean Opera's page where all the installed extensions are listed :D. (How should I call it? :D)
Gotcha! (I don't know how to call it either. I guess extension tab is fine. :D)Interesting. But definitely not the fault of any extension cause it can't be manipulated like all internal pages. So that has to be a "bug"(?) in Opera – once again… :whistle:
In other news, this update fixed my scrolling problems on http://computergames.ro/ and also fixes the double scrolls bars, normal and Modern ones. Now Modern Scrolls works as intended again.Thank you! Outstanding job!
There is some occasional choppiness in the Extensions Tab.Also, can you do something about the mild choppiness happening on http://www.ign.com/ ? It mostly happens in the upper-half of the page.
Thanks again man, at least someone is working hard out there trying to fix bugs ( some people should learn from you 😉 ) :Dso, I tried this one, and I'm sorry to say that the performance is way slow when the GUI of the extension is shown ( scrollbar), when it's hidden, the scrolling is just amazingly fast.the other bug I reported yesterday is gone ( twitter's bug ) thanks for the quick fix.well, I will try playing with the extension options maybe changing something there will hopefully fix the slowness. PS: smooth scrolling disabledwin8good luck :up:
Sally K. writes:Mostly great, so far, thanks :). |||| Put.io modal thing is better, but not fully functional. With mouse, the modal frame alone scrolls until it reaches the end of its travel, but *then* the background page starts scrolling until it reaches the end of *its* travel. Of course the user needn't/shouldn't keep scrolling once the modal frame is fully scrolled, so it's a minor bug, but I thought I should mention it. More seriously, the arrow keys *only* scroll the background page, not the modal iframe. |||| Oddly, using the mouse to set a number within M.Scroll's prefs (e.g. Width or Opacity: even just one mouse click to climb from, say, 3 to 4) sends the scrollbar flashing wildly, the numbers climbing wildly, and my CPU to 100%. I then have to disable JS to make it stop. Entering numbers directly into the boxes (e.g. 3 or 4) works fine. Weird. On Opera 12.11, XP SP3
Originally posted by netmain:
This setting does only affect Opera's own scrolling (if you deactivate the custom functions of the extension, which you better don't do, because it's horrible! :lol:)Originally posted by anonymous:
That's the intended behavior…I'll probably implement a check if the background page should be scrollable at all, but no promises that it will be integrated in 1.5 since the normal user will stop scrolling anyway when he got to where he wanted to ;)Originally posted by anonymous:
True, it does exactly what mouse scrolling was like in beta 3, because I didn't implement the same hack for the arrow keys yet. I wanted you to tell me if the approach is working first (It looks like it does :)) and now I will copy it over and adjust it accordingly :up:Originally posted by anonymous:
That really is odd. But not reproducible over here (Opera 12.12 Win8)
Originally posted by christoph142:
I'm talking about opera's smooth scrolling not the one of your extension ' custom functions ".
Me too! 😆
Originally posted by christoph142:
Yes it does feel better! :cheers:
great improvement indeed, I was in my way to report this particular problem lol.but, as I reported earlier, there is some slowness particularly by the extra-bars ( super bar and up and down bars) if they were hidden (disabled), the extension works great, by if they're shown ( enabled ) the slowness is definitely there for me at least :)thanks for your hard work 😉
Originally posted by netmain:
Wow, that's the fastest I ever fixed a bug then: before you were able to report it :up: :lol:Originally posted by netmain:
Oh ok. Now I see what you mean. You're not talking about the bars, but the up and down buttons.I have to tell you that there's nothing I can do about it. The choppiness is – once again – a bug in Opera (Thanks for reminding me, I wanted to and now added it to the "bugs bugs bugs"-post).Use the "special ends"-setting in the options instead of the buttons. The ends of the scroll bars will then act like the buttons do without the slowdowns :up:
Originally posted by christoph142:
I'm slow when it comes to reporting problems and bugs, I have to be sure it's really a bug and not my browser or my OS. so I try cleaning up things and compare with old and new installs .. that may take time.Originally posted by christoph142:
that's what I'm using, thanks for making it possible though 🙂
Originally posted by netmain:
Yeah, great, make me stop being happy about it by telling me how much time I had… 😮 No, just kidding :DI appreciate it, since your extra work possibly saves me wasted investigation time, which I can use in turn to improve the extension :up:
Originally posted by christoph142:
LOL, sorry I forgot to put some smilies in my first paragraph, for sure you did great work there, and I didn't expect a new " snapshot " in such a short notice. :yes: Originally posted by christoph142:
sure thing, it's the least that what we can do to get HQ products 😀
Sally K. writes:"Then we could set up, say, non-hovering, 15px transparent bars with 2px non-transparent right/bottom borders. Easy to manipulate, but visibly discreet." |||| Or with 2px non-transparent left/top borders, so the very thin visible bar also indicates the extent of the 'active' area, in case there is confusion about invisible areas stopping interaction with the underlying page. In any event, I think separate left/right border settings, plus a transparent 'colour' would be a really interesting addition.
I see "ms_page_cover" and "ms_superbar" is inserted into document even if super bar is disabled! :left: :confused:
Sally K. writes:Looking good :). |||| Modal frames work at Put.io as you describe. |||| The excess mouse clicking / CPU issue in Prefs is fixed. |||| Minor UI things: at the top of the Prefs page, you capitalise "Modern Scroll", while everywhere else you use lower case "modern scroll". Personally I don't love the lower case, and it's not in keeping with your other extensions, but it should always be one or the other. At the bottom of Prefs, you might link "contact me" to this blog (as you do with "Christoph D." at the top). |||| Now that you're using JS as a workaround for DSK-375403, is it definitely not feasible to also use it to control the hover trigger timeout (without Opera's bug leaving them permanently open)? I suppose I'm just hoping for a fresh flash of genius, because that setting would be so cool. |||| Alternatively, maybe think again about a setting to allow interaction with the scrollbars wider than the visible area (e.g. they look 3px wide, but can be dragged, etc, from 15px wide). Thus allowing users to choose to bypass the hover expansion issues. Ahh, or if you added settings for separate left and right borders (maybe a good idea anyway?), and added a fully transparent 'colour' to the colour pickers. Then we could set up, say, non-hovering, 15px transparent bars with 2px non-transparent right/bottom borders. Easy to manipulate, but visibly discreet.
Sally K. writes:"The excess mouse clicking / CPU issue in Prefs is fixed." Oops, no, it's back :(. It only happens with ModernScroll, not with any other extension. It's easy to workaround, but I suppose I can't be the only one seeing it.
Originally posted by netmain:
Well, some guys seem to think that moaning and complaining is… (I'm not talking about you guys, you're the best :love:, but those who just rate extensions with 1 star etc. (again, I'm not even (exclusively) talking about my own extensions) :angel: Originally posted by mubaidr:
Yes, because the page cover is there to prevent interaction with the page whenever you drag a bar. And the superbar is injected because otherwise I would have to insert tons of extra if-statements. It's not doing any harm, does it?!Originally posted by Sally:
No, I don't. It's a lower "m" in a bigger font size. And I did write it in lowercase on purpose, because in all modern forms of communication (SMS, Whatsapp,… ) people tend to use lowercase because of laziness. Long story short: I wanted its name to express a modern way in itself :chef: Originally posted by Sally:
The extension is written in JS so is it? :p The workaround is a completely different set of instructions than that extra feature would be. And I simply refuse to clutter my extension with hacks all over and loose track of how things come together simply because Opera has some bugs… :ko: Originally posted by Sally:
That does make sense. I'll do that :up:Concerning the invisible area: No way! This would lead to tons of complaints from other users ("I was trying to click an element and it did nothing. Fix it!"). I already do have that "invisble part": It's the gap to the border of the window. But it's completely unintuitive to have it reaching into the page.Originally posted by Sally:
As I said: I can't reproduce it…Please do the following:Press Ctrl+Shift+O to open the error console, switch to "Javascript", press "Clear", reproduce the issue in Opera and copy the error out of the console in a comment :sherlock:
Anonymous writes:"Concerning the invisible area: No way! This would lead to tons of complaints from other users ("I was trying to click an element and it did nothing. Fix it!"). I already do have that "invisble part": It's the gap to the border of the window. But it's completely unintuitive to have it reaching into the page." |||| But setting Opacity to 1% already makes the whole thing effectively invisible, including reaching into the page. Also having the option for a non-invisible inner border would be less unintuitive. Viva user empowerment! 😉
Sally K. writes:It doesn't happen on other extension Prefs pages; nor have I seen it happen anywhere else; and these (I googled to find some) work fine, for example: http://www.html5tutorial.info/html5-number.php |||| I don't *recall* it happening with earlier (than I reported) M.Scroll versions, but I didn't keep any. If you want to post an archive of older versions, I'll step through until I find where it starts? |||| But I can certainly live with it, if you want to wait for more reports (if any).
That's super strange. If there's no JS error, it's nothing I can fix.Try to find a website which also uses range-inputs. Does it happen there as well?
Sally K. writes:All I get is: "[12/12/12 12:05:25] JavaScript – widget://wuid-4d661490-6b6f-0bc3-0663-5e3b6b757a7f/index.htmlEvent thread: focusUncaught exception: DOMException: INVALID_STATE_ERRError thrown at line 35, column 2 in tabEvent() in widget://wuid-4d661490-6b6f-0bc3-0663-5e3b6b757a7f/background.js: tab.postMessage({needsConfirm: true});" |||| But that wuid refers to Persistent Text https://addons.opera.com/en-gb/extensions/details/persistent-text/ which it turns out throws errors for everything (maybe that's by design?). Disabling that extension makes no difference to the issue, but then there are no JS errors shown at all. More controlled testing shows that a single mouse click on any such control, results in 4 individual increments to the setting (each accompanied by a visible change in the scrollbar, hence all the CPU use).
Originally posted by christoph142:
ok then. :happy: Originally posted by christoph142:
I thought disabling SuperBar should not insert the content (a single IF statement?) :whistle: anyway if this is intended then OK 😉 and yes it does not cause any issue. :cheers:
Originally posted by Sally:
I don't want to, but I guess I have no choice. I can't fix anything which isn't traceable to me…:monkey:
Originally posted by mubaidr:
If it was that easy I wouldn't have written that answer but inserted that line into the code.In the meanwhile, there are about 750 lines of code describing the scrollbars and functions alone. I implemented exactly 33 variables that can be set in the options page (some of them values, but even if they were only settable to 1 or 0, that would make an astonishing amount of 2 to the power of 33 = 8,589,934,592 possible combinations of settings. And functions and elements need to be removed or added according to those.That's why I don't bother removing elements which are not needed, cause some function in some place may calculate and assign a value for the superbar and if it's not present, it'll throw an error and fail completely!Makes sense? :wizard: (I actually regret that I said this. IMHO that number show-off would make kind of a good blog post :P)
Originally posted by christoph142:
Holy moly… Large number! :eyes: Originally posted by christoph142:
Yes, it do! :up: Originally posted by christoph142:
No you should not, this post anwsers lot of questions in including mine! :yes: Originally posted by christoph142:
😆 Thanks for clearing up my mind, and keep up the good work.And don't forget about (touch scroll or call it drag scroll) you promised me! 😀
Ok, no problem! :yes:
I don't, but it's not on my to-do-list for 1.5. It's a really huge project already. I want this to be really stable and fast. I'll continue to add further new nifty features afterwards :up:
Hey there. These blog comments have really taken off! 😆 Any news on adding top/bottom margins to the scrollbar strip, or will it still affect performance?Also I thought I'd share another nice auto-hide scrollbar example, this time from KhanAcademy.org (scroll up/down the list of topics on the left-side pane). I added another set of custom settings to my Photo section based on it.http://www.khanacademy.org/math/arithmetic/addition-subtraction/v/basic-addition
I disabled this extension instead of getting "improved scrolling performance" i got super slow scrolling performanceI enabled "Custom scrolling functions and Animate scrolling" and "Velocity of scrolling by mouse wheel,Velocity of scrolling via the arrow keys" are on default. i did change those max to the left and still slow and max it to the right still slow and disabled "smooth scrolling" in preferences and dont get me started on HWA(it is disabled and dont want to turn it on)I dont know what the heck did i do wrong but i guess you can help me out what appropriate number should i use in these: Velocity of scrolling by mouse wheel,Velocity of scrolling via the arrow keysstill lot more improvements but im waiting for final.
Is it moving too slowly or is it choppy? (Changing the velocity will only set the amount of scroll to be done per unit of time. It'll not affect the performace at all…)Two things that you can do to improve scrolling performance:do not use the scroll buttons (Opera's bug; you can use the ends of the bars instead if you want to)turn off the animation of the scrollbars during scrolling via the mousewheel / keyboardAs I already mentioned multiple times: I'm using a weak laptop myself so there's definitely no need for HWA to make things work. But I don't have the possibility to test modern scroll on a lot of different machines (I don't use any other platform than Windows for example). So there may be some issues (there shouldn't, but you know Opera…)
Originally posted by christoph142:
I hope u have the time to improve more the scrolling performance
BTW, there is this extension you uploaded in opera addon site but why is it 1.3.1 version?
update?
Originally posted by christoph142:
I found the culprit!!!!!
after disabling this option: ""Animate the scroll bars during scrolling with the mouse wheel / keyboard,Animate scrolling" i found it fast enough than operas default(disabled smooth scrolling)
i am now using it but another question
will it work in 11.64?
Originally posted by christoph142:
I think it's quite the opposite lol, you had to allow the animation of the bar !! or we will have the same problem with the " fixed bars" that's what I do and the performance is just great 🙂
Well, it's not supposed to be "as fast as standard" but better… :lol:And definitely no, it does not and will never work below 12.10!
When viewing the Google Reader website, the standard Opera scroll bars remain visible (even though 'show scroll bar' is unchecked) and modern scroll doesn't even show up.Is this a known issue or unique to me!?
Originally posted by supertrol:
Because it's the latest stable release. This version is beta, as the thread title might imply…:rolleyes: Originally posted by ahpatel:
known, yes. Issue, no. These bars (just like MyOpera Mail) belong to a container element on the page and not to the main frame. That's why a) the modern scroll bars don't show up and b) there are standard bars although you disabled them 💡
Originally posted by Sally:
Who would have guessed: another bug in Opera…