-
-
Notifications
You must be signed in to change notification settings - Fork 956
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
[WIP] Implement smooth and precise scrolling #1454
base: master
Are you sure you want to change the base?
Conversation
Dont worry about the awkwardness of your OpenGL code -- OpenGL is a pain to use. I will help you clean up your code after you have something working. As for your question: If you want to convert a pixel scroll offset into an OpenGL offset, you basically divide the pixel scroll offset by the viewport height (os_window->viewport_height). Then divide that by 2 because the opengl co-ord system goes from -1 to 1 which means the full screen has length 2. Some general comments. This will as far as I can see render blank at the bottom line when scrolling. If that is all you want to do, you could simply offset the rendering of the main shader and then draw a blank rectangle at the bottom. No need to use framebuffers at all. |
I didn't ask about converting the offset from pixels to OpenGL but thank you anyways because I'll need that info later. But first I need to actually copy that offset from the C code to the shader and I don't know how to do that. As for the blank sections, my first proof of concept will have those, yes. But it won't be the same as drawing a blank rectangle at the bottom or the top because the content will be shifted by a specific number of pixels. I also plan to render more than what is currently visible on screen and then keep what was rendered as a sort of cache. This will allow me to pre-render parts that are not yet visible. It should also save a little bit of GPU time and power because I don't have to render the whole screen on every frame. This will become more important than it currently is because kitty currently only needs to render one frame per line scrolled and the user doesn't scroll 60 lines per second (or whatever FPS their monitor has) most of the time while 60 pixels per second is going to be a lot more likely, at least with high resolution input devices. |
Oh, I missed that. But my other reason for doing it like this, still applies. |
Use a uniform to pass values from C to the shader. See glUniform |
Your tip was very helpful. |
Doing it now 😁🎉 |
Nice contribution, I've been following this PR 😝 The demo on the video is awesome! I don't have high hopes as I assume it won't work on X (since it doesn't even have precise scrolling), but I just tried anyway — when kitty opens from your branch, all I see is black screen. I'm launching via
Does it give you any clue? In the meantime, I'll quickly install sway and try it out there 😉 UPDATE: having the same behavior on sway, and this command opens kitty fine on |
@maximbaz the black background was probably caused by the hardcoded size. It's still not very good, resizing the window or opening a tab so that the tab bar is shown doesn't adjust the size of the texture but that will have to wait a bit... |
At least the black background issue is fixed now, kitty launches fine on X11 😉 👍 I also wanted to try on sway, but for unknown to me reasons kitty doesn't work there, even on master branch, kitty's window opens but remains empty. If I provide Anyway, good job once again, I'll go back now to crying about the absence of smooth scrolling for X11 in glfw 😢 |
@kovidgoyal what do |
prepare_to_render() updates all the window global state and checks if the |
d6ee9d2
to
294ba21
Compare
294ba21
to
6427384
Compare
Where is |
Just to give you some input, this is really nice work @Luflosi! I'm testing on sway, and although there are some grey artifacts, in general the code works, and smooth scrolling is very pleasant! 🙂 Do let me know when you want a more thorough testing / feedback! |
Thanks for the nice words @maximbaz. The grey artefacts are there because I didn't manage to make the rendered region bigger than the window yet. It needs to be at least one line taller to fill the grey regions. Basically everything else is still broken, like resizing, OS windows, tabs, kitty windows, background images, selections, ... This will need a lot more work and while I haven't done much for the past year, I now want to work on it again. |
On Thu, Apr 09, 2020 at 03:41:14AM -0700, Luflosi wrote:
Where is `screen_resize()` from `kitty/screen.c` called? If I search for it, that's the only occurrence in the entire source tree.
It becomes the resize() methos of the screen object
|
644357a
to
65c7ecb
Compare
Pity that this features seems to have been abandoned. It would be really nice for Vim. |
@jclsn I think this wouldn't work for vim as it takes over the terminal and performs its own scrolling simulation AFAIK, but I'm not 100% sure. |
@serhez Yeah, probably not |
@serhez there is vim-smoothie that adds smooth scrolling to navigation via ctrl-f and ctrl-d |
There are many such plugins but they do not implement pixel-wise scrolling, the do smooth scrolling in the sense that they use a non-constant (mostly non-linear too) function to calculate the delay between each line being scrolled, I think. But it's still line-wise scrolling. |
f5a18f5
to
2bb42e6
Compare
@Luflosi Is this 100% abbandoned? it would be one of the biggest features for quality of life, especially with trackpads |
@jclsn Per your comment: neovim/neovim#27583 |
@NeilGirdhar I am one of these guys who refuses to use Neovim 😉 It's also been five years. I reckon @Luflosi has two kids and other priorities by now! |
I started to implement smooth and precise scrolling, see #1123. My plan is to render to some kind of buffer (I'm currently using a texture) and then copy the right part of that buffer to the normal framebuffer to allow pixel-precise scrolling. This is still very much a WIP, my code currently doesn't even do anything with scrolling. The code is also very hacky with some of it copied straight from learnopengl.com, that I don't even know exactly what it does. A lot of the new code for example in
init_cell_program()
should probably be somewhere else. I also hardcoded the size of the texture. This also literally the first time I've done anything with OpenGL, so this will be difficult for me and probably take a while to finish implementing.My current problem is getting the information that tells the shader by how much to shift the content up and down from
after_render()
into the shader. I'm currently just using0.1
as a constant. I think you're doing something like that increate_cell_vao()
with theA1
define but I don't know how that works. Could you help me with that please?Any other feedback is also welcome.