Panel rounded blur

[a-parhom]

I've managed to fix the problem with additional empty pixels in blur, so I've tried to implement the rounded blur for panel as well.

I hope this will help you with your further work on implementing the rounded blur across all other components.

[a-parhom]

It has a bug, with updating actors, probably.

Edit: Maybe, not with the actors. The problem is the static effect is a bit transparent when the session is loaded or the blur type is switched. But as soon as any blur parameters are changed it starts to behave normal. I've tried queuing repaints, tinkering with parameters passed to the effect, but have not found the cause of the problem yet.

[a-parhom]

Also, color and noise effects should come after blurring, but before rounding. So we either need to merge all effects in one, or decouple rounding from blur (like it was in the beginning).

[aunetx]

Thank you very much for your work! I remember some kind of bug like you explained it, and I think invalidating the actor's paint volume was working (but I really am not sure if it is the same bug here).

I will test it very soon, thanks for your dedication! I think splitting the blur effect and the rounding should be better you're right, I'm sorry that you had to change it before because of me. When I find some time I will split it, and make the blur work nicely with the noise and colour effects (which I plan to refine at some point).

[aunetx]

I tested this and found it was very slow for me (the animations to open and close the overview are at 10 fps)... I don't know what makes it so slow, because the blur should not be redrawn at every frame of the animation, but I think this does not apply to the dash because the blurred part is way smaller.

I think I will need to thinker a little with it, and I will try to use the same downscaling method gnome uses, and also to pin down when exactly to update the blur, because currently blur-my-shell updates the overview and panel blur way more than it should.

So for the moment I guess I will not merge this PR (because that could make the extension too slow for a lot of people), but at least when I fix one of the two issues it will be perfect! Thanks a lot :)

[a-parhom]

I'm sorry for the bugs, I'm not that experienced in GNOME APIs. I've tried several times to implement the downscaling, but still no luck with that.

At least, I hope this PR will help you a bit in doing this the right way.

[aunetx]

No worry, honestly I think you're better than me with using gnome API at this point! Everything I do is testing and kind of pulling what I can do into this extension, so your work is more than valuable here!

Yes of course it will help, I think I will at least merge the method with additional pixels (as it should be used for the dock too, I guess), and maybe provide the option to the user to use the non-native blurring method for the panel? Although at this point I think this would only confuse them, so maybe this will wait a bit

[aunetx]

I committed the part with the empty pixels, thank you very much! I now noticed the static blur is also quite laggy for dash-to-dock when using a big sigma value (I use 200px with 2×dpi, so that's noticeable!). However, when using not-too-obscene values, it is not noticeable at all! So I think after all I will add a notice under the 'static blur' for the dash-to-dock to tell users not to use too big sigma values, and I will do the same for this component when I merge it :)

[a-parhom]

One more thing I'd like to mention: I have a concern about hardcoded offsets for "black pixels in texture" workaround. I have a 200% scaling on my VM, but I assume the offsets can differ for other configurations. Maybe, it would be better to compare the size of the texture (which is bigger, than the size of the actor) to the size of the framebuffer or the actor itself (which are the same, at least for me), and set the offsets dynamicaly.

[a-parhom]

Also, I don't know if that's meant to be like that by design, or it's kind of a bug in GNOME and can change in future. So doing some checks may be useful anyway.

[a-parhom]

It looks like Cogl API in Gnome 46 supports now the new_with_size method of Texture2D (which was not the case in Gnome 45). This method is needed to implement the downscaling for the blur the way it is done in the native blur (at least, as far as I understand it).

[aunetx]

@a-parhom that's really cool, thanks a lot! If you want to try implementing it, be my guest but else I will give it a try soon!

I'm currently working on a quite big pull request, #559, that would permit the user to manage the way each component is blurred by creating interactive pipelines and assigning the component to one of them. That entirely changes the way the extension works, which is why it's taking some time, but in the end this would allow us to be much more flexible with the effects (because adding / changing an effect would not mean changing the way the components work, as the widgets behaviour would be entirely decoupled from the effects behaviour).

So in this branch, I already decoupled the corner effect and the gaussian blur effect, and if the downscaling works that would mean having much faster effects overall so that would be very great!

By the way, it looks like the effects are repainted each time the mouse is over the attached actor, which is why it is quite laggy even if the effect and actor themselves are static... Do you know what could be the cause?

[aunetx]

(by the way, if you want to work on it -- which I understand if that's not the case --, it is maybe better not to base yourself on the #559 PR as it is unstable and will change quite a lot, the master branch maybe is in better shape right now!)

[aunetx]

This is now superseded and implemented in #559, as a side-effect of these changes!! I am quite happy with the state of things in this PR to be honest :))))