-
-
Notifications
You must be signed in to change notification settings - Fork 990
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
Make high resolution scrolling more responsive and configurable #1129
Conversation
The default for |
Yes, by setting UPDATE: I misunderstood what you are suggesting, sorry, you are proposing to change default value to |
At least on macOS a value of 1 makes kitty scroll as fast as all other apps. |
Just to confirm, are you testing with 82f9aec reverted? Because both that commit and this PR increase the speed on macOS. In any case, I don't really care about the default value, I'm totally fine changing it in my local config as long as it's configurable 😉 |
That commit doesn't make a difference for me since |
Maybe it wasn't a good idea then to re-use |
I think the semantics of that option make perfect sense for low and high precision scrolling and we should not create a new option. |
If the option will have different values based on whether the device is "high" or "low" precision, users would need to have a way to override both these values, and this will be impossible I think... In other words, I would like to override |
That is not the right place for this patch. It belongs in glfw/wl_window.c just like the fix for macOS that I committed recently.basically the backend should be responsible for providing the correct number of scrolled pixels as reported by the OS. kitty should not be messing with that value. As for adding a configurable multiplier, I agree it should be a separate option, after all the current one is named "wheel_scroll_multiplier" so the new one could be named "touch_scroll_multiplier" or similar, and it should default to 1. |
It would be interesting to see what VTE does on wayland. Why is it scrolling faster than kitty? Does it multiply the pixels by something and if so where does the value of that something come from? @egmontkob you know the answer? |
GTK+ gives us a smooth scrolling delta which hides from us the X11 vs. Wayland differences, and is probably already scaled by some global GTK+ or GNOME setting (I'm not sure about it). I'm not aware of these details. Then in VTE it's scaled according to ceil(height / 10.0) here, which may not be a good approach as per 748012. See also 769696. |
@egmontkob thanks for the pointers |
Alright, I don't think I should modify Let's start with implementing |
Hello, I am wondering, in the current master branch, when the last line is updated (or a new line is added to the bottom), does kitty redraw the whole window? like if there is an "A" in the second line from the bottom, then the first line from the bottom changed, does kitty go through the process of rasterizing the letter "A" again? I assume if it does not need to (by holding a buffer of some previously rasterized parts of the terminal window), both high-prec scrolling would be easy and less computation would be needed? |
So far as I know, a terminal program either is only able to change some lines from the bottom (normal terminal program, and tab completion) or takes control of the whole (virtual) terminal (like vim, tmux, or clear), it does not change lines from the top or in the middle. In the latter case you don't have scrolling anyway. So we can always assume a terminal program changes a certain number of lines from the bottom. Is it correct? |
kitty only ever rasterizes a character once, that's part of the magic |
Thanks. Then where shall I start looking into the scrolling/rendering stuff? In particular, which variables in the source refer to the previously rasterized content? |
there is no previously rasterized content. rendering happens on the GPU. |
So by "rasterizes a character once" you meant there are caches like many images with the size of individual characters in the graphics memory? I guess by "does that for other reasons in shaders.c" you mean draw_cells_interleaved_premult(). |
Does the framebuffer to render into live in the graphics memory or the main memory? |
On Tue, Mar 10, 2020 at 08:07:16PM -0700, ducis. wrote:
So by "rasterizes a character once" you meant there are caches like many images with the size of individual characters in the graphics memory?
There is a sprite map stored on the GPU.
I guess by "does that for other reasons in shaders.c" you mean draw_cells_interleaved_premult().
Is this function triggered in, say, a fresh install of kitty without customized configuration file or passed commandline options? If not, how should I enable it so that I can test if it affects the latency first?
It will be used when you have a transparent window and images displayed
in the window.
|
On Tue, Mar 10, 2020 at 08:20:13PM -0700, ducis. wrote:
Does the framebuffer to render into live in the graphics memory or the main memory?
Usually for this kind of things it should live in the graphics memory and the application has pointer-like stuff with which the app can tell the GPU to do things like memcpy() purely in the graphics memory.
But I am not sure if you meant we have to fetch the rendered results into the main memory by "you have to render into a framebuffer", which would be much worse performance-wise.
framebuffers live in GPU memory
|
Hi, I just tested with typometer. |
Put a printf() in draw_cells_interleaved_premult() to check if it is going through that. IIRC without images it will not be used, see line 636 onwards of shaders.c for details. Either you need transparency + any image or non-transparent and negative z-index images. |
I put in the printf() and tested again. Yes, draw..premult() is only triggered by both background_opacity and icat. |
You should be able to trigger it with just kitty -o background_image=whatever.png and no transparency (assuming you are running from master) |
No, I am running from 0.16.0 which does not seem to have background_image, Maybe there should be an option to explicitly force rendering to a framebuffer I am even using Intel graphics, an additional copy would be even more forgiving on a real GPU. |
Additional copies may have negligible performance penalty, in terms of I dont really see why that would be needed anyway. You could just switch |
It is hard to say without actual implementation and benchmarking, but keeping a large buffer of results painted in the last frame might actually reduce computation at the expense of more VRAM. But whatever, what is the current situation of smooth scrolling in the master branch? |
there is no smooth scrolling #1454 |
@ducis We can work on this together, if you like. |
@Luflosi |
I was testing high resolution scrolling under Wayland and found that scrolling becomes acceptable if I multiply
yoffset
by10
and awesome if I multiply it by20
.Since
wheel_scroll_multiplier
is not used under high resolution scrolling at all, I thought we could put it to good use here, so that responsiveness becomes configurable.Under Wayland, my
viewport_y_ratio
is2
. I added it to this patch because it was suggested by @Luflosi in #1112, if you want to keep it, 82f9aec probably needs to be reverted.With this formula, scrolling is acceptable with default settings and I can further improve it if I change
wheel_scroll_multiplier
to10
.If we remove
viewport_y_ratio
from the formula, the default value ofwheel_scroll_multiplier
(5
) is too slow, and I would need to change it to at least10
, but better to20
.