Scroller + FixedColumns scrolling inconsistency

Scroller + FixedColumns scrolling inconsistency

jhaitasjhaitas Posts: 32Questions: 0Answers: 0
edited April 2012 in Bug reports
When using the Scroller plugin in conjuction with the FixedColumns plugin - there is an inconsistency with the appearance the datatable when scrolling.

The FixedColumns stop scrolling at the end of the visible data subset. The scrolling part of the datatables will scroll into whitespace until the data is loaded.

I have a fix for when the datatable is loaded. I am working on integrating it back into the FixedColumns plugin so that it will work out of the box.

Replies

  • jhaitasjhaitas Posts: 32Questions: 0Answers: 0
    Hi Allan,

    I have a fix for this that goes in FixedColumns.js ... Do you think we could get this merged into the official code? Perhaps you would see a better place/way to do this.

    Thanks,
    John
  • allanallan Posts: 63,381Questions: 1Answers: 10,449 Site admin
    Sounds very interesting yes please if you could let me know what your fix is, I'll look at integrating it into the plug-ins. A Github pull request would be great ( https://github.com/DataTables ), or a simple diff here if you prefer:

    Regards,
    Allan
  • jhaitasjhaitas Posts: 32Questions: 0Answers: 0
    There could well be a better location/way to do this ... First if is testing for bAll so that it happens only once ... second if is testing if Scroller plugin exists ... then just clone Scroller's div that is the full height of the table


    diff --git a/media/js/FixedColumns.js b/media/js/FixedColumns.js
    index a75e68a..14a9788 100644
    --- a/media/js/FixedColumns.js
    +++ b/media/js/FixedColumns.js
    @@ -882,6 +882,15 @@ FixedColumns.prototype = {
    }

    oClone.body.style.width = "100%";
    +
    + if ( bAll )
    + {
    + if ( typeof this.s.dt.oScroller !== undefined )
    + {
    + oGrid.body.appendChild( this.s.dt.oScroller.dom.force.cloneNode(true) );
    + }
    + }
    +
    oGrid.body.appendChild( oClone.body );

    this._fnEqualiseHeights( 'tbody', that.dom.body, oClone.body );
  • jhaitasjhaitas Posts: 32Questions: 0Answers: 0
    edited April 2012
    ok ... so i've got a update the original patch ... a coding error that made the plugin fail when not used with Scroller plugin :/

    see https://github.com/johnhaitas/FixedColumns
  • jhaitasjhaitas Posts: 32Questions: 0Answers: 0
    Hi allan,

    Just wanted to give you a nudge on this. I am happy to help testing different use cases.

    Hopefully it makes it into FixedColumns 2.0.4 - would make things easier to not patch every time. :)

    Cheers,
    John
  • jhaitasjhaitas Posts: 32Questions: 0Answers: 0
    Hi Allan,

    Any chance this can make it into 2.0.4 when you do the 1.9.2 release?
  • jhrabowsjhrabows Posts: 5Questions: 0Answers: 0
    This is probably the same as what I noticed. You can see an example in

    http://jsfiddle.net/jhrabows/UFGdS/11/

    The is a scroller with 2 columns (1 fixed) and 100 rows generated on the client. When you scroll down past 75th column the fixed-column stops scrolling. The issue is in the 1.9.2 release although the fiddle uses 1.9.1 release from CDN.
  • allanallan Posts: 63,381Questions: 1Answers: 10,449 Site admin
    The patch is in the very latest FixedColumns code on Github ( https://github.com/DataTables/FixedColumns ), but that isn't quite ready to make it to the DataTables download page yet - there are still a couple of issues that I want to work out, but any feedback on the latest development is very welcome.

    Allan
  • jhrabowsjhrabows Posts: 5Questions: 0Answers: 0
    Hi John, Allan:

    I updated the fiddle to point to the latest Github code for FixedColumns (which is exactly what John posted on April 20.

    http://jsfiddle.net/jhrabows/UFGdS/17/

    I have tested on Firefox and Chrome and the original issue is no longer there but I noticed some side-effects:

    1) On Firefox only I noticed a drastic change in the response to scrolling with mouse-wheel. Normally, a turn of the wheel moves the display by couple of rows, but now the display moves just few pixels.

    2) On both Firefox and Chrome when the total number of rows is large (thousands) then sliding the scroll-bar with the mouse becomes erratic. In some cases the slider does not move at all, in others the move happens but only after a considerable delay.

    3) On both Firefox and Chrome the horizontal scroll bar extends over the entire table and when the horizontal slider is under the 'fixed' column then the sliding is suppressed. You can however change the location of the slider by clicking.
  • allanallan Posts: 63,381Questions: 1Answers: 10,449 Site admin
    In Chrome it is horribly slow as well. In fairness the two plug-ins weren't really designed to work together, and FixedColumns, out of necessity (due to all the cloning etc that it does) is always quite slow. Using CSS row height for the FixedColumns would speed things up a good bit I think, but really the two plug-ins probably both need a bit more work to play nicely together. Its on the to-do list... :-)

    Allan
  • jhrabowsjhrabows Posts: 5Questions: 0Answers: 0
    Actually, Chrome performance is better than FF. If you hold the mouse button down on the scroll-slider and move it slowly you can see Chrome trying to catch up. Attempting the same in FF freezes the display and then you see a sudden jump (if you are lucky). I think the problem is that DOM updates happen too often. Perhaps some parameter which controls the update rate would help.
  • jhaitasjhaitas Posts: 32Questions: 0Answers: 0
    edited July 2012
    sorry about the delayed response - i've noticed scrolling problems with the new version - particularly lagging and sometimes not updating
  • jhaitasjhaitas Posts: 32Questions: 0Answers: 0
    I am noticing that the fixed columns don't keep up with the scrollable columns when scrolling - specifically in safari

    can anyone else confirm?
  • allanallan Posts: 63,381Questions: 1Answers: 10,449 Site admin
    Yes, the integration between the two doesn't appear to be particularly ideal at the moment. I hope to get a chance to look at it some time soon.

    Allan
  • jhaitasjhaitas Posts: 32Questions: 0Answers: 0
    Hi Allan,

    I submitted a pull request that significantly improves scroll performance for me - particularly with inertial scrolling in Safari.

    I hope they work for you.

    Thanks,
    John
  • jhaitasjhaitas Posts: 32Questions: 0Answers: 0
    I also have a fix for FF scrolling - but it appears it will require conditional binding of the events depending on which browser is in use...

    Best we figure out if my existing pull request is good enough for the codebase before moving on to that.
  • allanallan Posts: 63,381Questions: 1Answers: 10,449 Site admin
    Hi - it is certainly good enough - but I'm curious to know why it is so much better - I thought $().scroll() was basically a short cut for what you've got.

    What is the FireFox fix?

    Doing a conditional event binding with just object detection (since we can't use $.browser now...) might be interesting! Possibly just need to use user agent matching anyway.

    Allan
  • jhaitasjhaitas Posts: 32Questions: 0Answers: 0
    Hi Allan

    Using $().on() allowed me to bind both 'scroll' and 'mousewheel' to the same anonymous function.

    Yes, there is a shorthand $().scroll() function. But there is no shorthand $().mousewheel() function.

    As of jQuery 1.7 $().on() is preferred over $().bind() per http://api.jquery.com/on/

    ...

    The Firefox fix is only for Windows - have you noticed how poor the performance is for Firefox on Windows? User agent detection is necessary because we would need to detect the OS.

    ...

    I'd prefer to wait on the Firefox fix until we verify my existing pull request is good to go. :)

    Thanks,
    John
  • jhaitasjhaitas Posts: 32Questions: 0Answers: 0
    I am moving this discussion to http://datatables.net/forums/discussion/10928/fixedcolumns-2.5-scrolling-performance since it has evolved into a different discussion unrelated to this original discussion.
This discussion has been closed.