Inconsistent Cropping Behavior

[3rd]

Inconsistent Cropping Behavior

[benlubas]

I found some code in renderer that assumes width and height are equal values when dealing with cell width and height.

Easy mistake to make, took me literally staring it in the face to notice. I'd say I'll have a PR up shortly, but I feel like I'm looking at more than one bug here, so we'll see

[jmbuhr]

@3rd PS: This plugin is super exciting, you are a wizard! I can't stop smiling about the penguins with transparent background right in my quarto document!

[jmbuhr]

In a more isolated setting, only rendering the image at the cursor, what I see is that when I first jump to a line, e.g. using a search or a mark, it crops and shows the top left corner (behaviour 1):

but after moving from and back to the line once (jk) it shows the scaled image:

then, after scrolling with the mouse wheel and clicking back to the line I get and even smaller version:

[benlubas]

I'm here to add that opening a large enough floating window allows the image to render without being cropped, but it's scaled to half the size that it should be. I see this behavior in Molten as well

[benlubas]

Now to deal with this: Images getting both scaled and cropped

heh that one was my fault.

I'm going to look into that shrinking issue now b/c that also happens to me all the time. I have an idea of what's causing it too

Oh god I'm just jumping all over the place, there's an issue with the native cropping method. I'm not sure what it is, but I'm looking into it

When it uses a backend cropping method like kitty's then it doesn't set the image to the scaled version which causes something like this to happen:

[benlubas]

@jmbuhr I think #46 also fixes the issue you described. I don't seem to be having it anymore

[benlubas]

Okay, there's actually still one inconsistency here. Scrolling an image down in a floating window (or probably any window that isn't at the bottom of the screen) will resize the image, while an image at the bottom of the screen gets cropped.

@3rd I'm curious what you think the behavior should be here. I'm heavily in favor of cropping in floating windows for a few reasons:

1. Cropping is lighter on resources for kitty users, it's probably faster than a resize and it takes up much less space b/c we don't have to cache the cropped images
2. If someone using the api wants to resize they can already do that by passing geometry to render, there is currently no way to crop manually
3. cropping at the bottom of all windows instead of just at the bottom of the screen is more consistent

screen_cap.mp4

[3rd]

We can add a image.auto_resize bool to turn off resizing per-image, would that work?

[benlubas]

My issue is more with when it resizes and when it doesn't, it's currently not consistent between images that have a window and images that don't have a window. So if we add auto-resize could we make it off by default?

Also, is there any reason that kitty isn't cropping images on the right or left side of a window?

[3rd]

Not sure if left/right crop is implemented with Kitty, will check.
If an image is not mounted on a window & buffer it shouldn't be resized/cropped at all, the API user should have full control.
For images that are attached to a window and buffer it should behave the same and crop images at the window bounds, images should not be resized depending on scroll position.
I'll look into it!

[benlubas]

I have a branch that makes things so they work the way you just described and adds left/right crop

@3rd

[benlubas]

screen_cap.mp4

[3rd]

I have a branch that makes things so they work the way you just described and adds left/right crop

@3rd

Awesome, looks great!