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

imlib2 pixel skewing #28

Open
biopsin opened this issue Feb 15, 2020 · 6 comments
Open

imlib2 pixel skewing #28

biopsin opened this issue Feb 15, 2020 · 6 comments
Labels
imlib2 bug appears to live in imlib2

Comments

@biopsin
Copy link

biopsin commented Feb 15, 2020

sorry for the title as I don't know what to name it at the moment :D
I have being running for a long time in a script
hsetroot -addd "$(rndcolor)" $(rndistance) -addd "$(rndcolor)" $(rndistance) -gradient $(rndangle)
on my 27 and 30 inch monitor, and when distance gets > 10 and angle > 30 the result gets like this. Now on my spunky new 4k; no matter less or more distance & angle it always looks skewed?

Edit : See next post..

@himdel
Copy link
Owner

himdel commented Feb 17, 2020

I'm sorry, I have no comparison here.

What is it you're expecting to happen?

The distance is ignored for the first add, it's always 1. Given you're using just 2 colors, sounds like you never need a distance > 10, which should work around the problem, right?

But, if I am to fix hsetroot to do the right thing, I need to know what you expect to happen.
I don't know where those 2 images come from (which parameters), nor how they should look if the issue was fixed.

@biopsin
Copy link
Author

biopsin commented Feb 17, 2020

Sorry for not being more clear.
Take the bottom image as an example, I expect the white gradient @ 30 angle to black. This works fine on my monitor with resolutions @2560x1600,
testing the same on the other monitor @3840x2160 the output is what I've attached.
I never understod the amount of distance to use, tank you for explaining.
What do you get testing?
hsetroot -add '#ffffff' -add '#000000' -gradient 30
I get this 4 rectagular output.
20-02-17--1581951974_scrot

@himdel
Copy link
Owner

himdel commented Feb 17, 2020

Ah, thanks, that helps! :)

With hsetroot -add '#ffffff' -add '#000000' -gradient 30 and 1920x1080...

foo

So, what I think it means is that the actual gradient works fine, but once the resolution is above some value, it tries to wrap the pixels somehow. And given the colors in the "weird" area are different from the rest but still using the gradient somehow, it must be the gradient painting code.

OK, that should help :)

Except that looking at the code, it seems like imlib2 is doing all the work :) I'll investigate more, thanks!:)

@biopsin
Copy link
Author

biopsin commented Feb 17, 2020

Yes! thanks for confirming 👍
I was looking for imlib2 bugs that would mention it, but have not found any yet..

@biopsin biopsin changed the title 4k skewing imlib2 pixel skewing Feb 17, 2020
@himdel
Copy link
Owner

himdel commented Aug 12, 2023

More info, imlib_image_fill_color_range_rectangle just doesn't do the right thing when any width/height is >4096 (#42)

(I suspect imlib_blend_image_onto_image or imlib_image_copy_rect to have a similar wrapping issue.)

(wondering if gdk-pixbuf may be the more maintained choice now)

@himdel himdel added the imlib2 bug appears to live in imlib2 label Aug 12, 2023
@biopsin
Copy link
Author

biopsin commented Aug 20, 2023

Not shure how helpfull but I switched to this little application some while ago as it does what I wanted to achieve in the first place and the gradient scales correctly over any monitor ive tested.

https://github.com/stevommmm/gbg/blob/master/gbg.c

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

No branches or pull requests

2 participants