8000 Make scrolling faster/more fluid · Issue #38 · larray-project/larray-editor · GitHub
[go: up one dir, main page]

Skip to content

Make scrolling faster/more fluid #38

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
gdementen opened this issue Aug 18, 2017 · 2 comments
Open

Make scrolling faster/more fluid #38

gdementen opened this issue Aug 18, 2017 · 2 comments

Comments

@gdementen
Copy link
Collaborator
gdementen commented Aug 18, 2017

With each feature the UI feels a bit slower when many cells are visible. I thought it was caused by the overhead of the default implementation which calls the model.data method many times (once per role * number of visible cells), but after experimenting a lot with this, progressively turning off features, it turns out that even with a custom delegate with a custom paint method (which can choose to only ask the model for the displayRole -- or even, for the sake of the experiment, not call it at all), it still does not feel as responsive as I would like. eg. adding this method to our ArrayDelegate:

    def paint(self, painter, option, index):
        painter.save()

        # set background color
        painter.setPen(QPen(Qt.NoPen))

        if option.state & QStyle.State_Selected:
            painter.setBrush(QBrush(Qt.blue))
        else:
            painter.setBrush(QBrush(Qt.white))
        painter.drawRect(option.rect)

        # set text color
        if index.isValid():
            painter.setPen(QPen(Qt.black))
            value = index.data(Qt.DisplayRole)
            painter.drawText(option.rect, Qt.AlignLeft, value)
        painter.restore()
        return

Here is an unordered mind dump of all I did for the last 1.5 days:

  • the stylesheet is the main culprit of the slow down

  • using another graphics engine does not really help (Qt4 supports native (default), raster and opengl).

    _app.setGraphicsSystem("native") # default
    _app.setGraphicsSystem("raster")
    _app.setGraphicsSystem("opengl")

This does not work on Qt5 (cannot be set) where I think opengl is the default anyway

  • running with Qt4 seems a bit faster than Qt5 but still sluggish.

  • running the program with the NVidia processor (I have a dual GPU on my laptop) instead of the integrated graphics chip (default) does not help.

  • QTableView is known to be slow for a large number of visible cells. rolling our own table might be an option: https://stackoverflow.com/questions/19691577/qtableview-slow-performance-with-1000s-of-visible-cells

  • alternatively, we could reimplement the paintEvent method of QTableView which I suppose would fix the problem but would make it easier to support edition.

  • some people suggest using QML instead, but I don't see how that would be faster.

  • Using an Opengl canvas (as in: https://doc.qt.io/archives/qq/qq26-openglcanvas.html) was also suggested by some to make things faster, but I doubt it would help given that I think qt5 does this by default.

  • We could implement "fixed" rows/columns using a single QTableView/model as long as we scroll one cell at a time. It would be a bit tedious to map positions of "visible" cells with real cells, but we will need similar tricks when we implement the "buffer" thing (a la ViTables) and I am starting to think it would be less painful than what we are currently doing.

  • the sluggish scrollbar seems to be almost independent of the keyboard scrolling speed. It might be caused by the synchronisation of the different TableView (though I didn't test this!). Isn't the scrollbar sending a change event which changes the second view scrollbar position, which in turn sends an event to the first scrollbar? This might be avoidable by using some kind of timer.

@gdementen
Copy link
Collaborator Author

In any case, to make it faster than what we currently have with the stylesheet problem fixed, we need a benchmark. For that, I think creating a test array that is larger than the screen then move by emulating continuous keypress events (down arrow) and time how long it takes to reach the end of the array seems like a good test. We could also make the same test using PageDown (but I guess that would give the same kind of information).

@alixdamman
Copy link
Contributor

See also #33

@alixdamman alixdamman added this to the nice_to_have milestone Mar 9, 2018
@gdementen gdementen removed this from the nice_to_have milestone Aug 1, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants
0