Skip to content
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

Sluggish Scroll #118

Closed
robertpiosik opened this issue Jun 5, 2023 · 4 comments
Closed

Sluggish Scroll #118

robertpiosik opened this issue Jun 5, 2023 · 4 comments

Comments

@robertpiosik
Copy link

Hi, keeping things simple, to reproduce, click on a scrollbar and move up and down aggressively.

Looks to me like that some delays don't respect scroll direction change.

@leodevbro
Copy link
Owner

leodevbro commented Jun 5, 2023

Hello, this is basically an optimization I implemented into Blockman. Somehow VS Code block rendering engine is too slow, for 1000 line file, it would take probably 10 seconds to render blocks for the entire file. And let's also consider the fact that one block (rendered by Blockman) is not one div box, it is div boxes on each line and they touch each other so there is an illusion of one big box. So, yeah, line by line div boxes means there can be thousands of div boxes if the file is large.

So, for optimization, Blockman renders blocks only in the current viewport area, and it listens to the scroll events and dynamically adjusts the blocks.

Yeah, probably the dynamic changes should not be so noticeable and so sluggish in usual web browser, but it seems that VS Code does not have as optimized API (for block rendering) as web browsers do.

To feel less sluggish scroll, you can increase this number:
"blockman.n31RenderIncrementBeforeAndAfterVisibleRange": 20

Default is 20, but you can set it to, like, 30, 40, 50. But more than 100 probably will slow down your environment so much. Just play with some numbers and you will find the most optimal number for you.
In my env, I have set it to 30.

@robertpiosik
Copy link
Author

Hmm, I don't think I stated what I meant clearly. I do understand rendering blocks do require work but as this work is not triggered during smooth scroll drag, it is when doing fast bidirectional drags.

Have you considered adding debouncing to your algorithm?

I'm using vim extension and scrolling few lines at a time. It would be great to debounce it as well.

Currently only smooth drag scrolls do not trigger block creation.

@leodevbro
Copy link
Owner

leodevbro commented Jun 5, 2023

Well, Blockman uses a lot of debouncing, during text change events and also during scroll events.

Please see this video (Blockman scroll test):
(You can download it, if the online player plays it with low quality)
https://drive.google.com/file/d/1bwdz-HFohNzUT06YzDZG_esLAsI-m8R1/view

Sorry, I think I still don't understand what you see during scroll. In my env (in the video) I think the scroll behavior seems ok. Could you please record your video or something? So, I will be able to see the actual behavior.

You mentioned the vim extension. As I remember (If my memory is correct), I have heard some people had such kind of issues with Blockman when they had installed vim extension. Unfortunately I don't know what could be the cause of it.

@robertpiosik
Copy link
Author

robertpiosik commented Jun 5, 2023

Interestingly, I reinstalled blockman and it seems to be great now! Thanks for your responsiveness, have a good day :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants