[BUG] Rofi displays as black box #2068
Comments
|
I not sure what change would impact xrdp or this part of the drawing? on arch normally it works fine. Any more info on your Xrdp setup? |
|
I agree - it was the only main difference that stood out between the working and non working setups so I thought I'd mention it. But to answer your question: It's a headless virtual machine with no GPU (virtual or otherwise). I use xrdp (and xrdpxorg) to access it. |
|
If I find time, I'll try to reproduce. Its a weird one, beside some font stuff no drawing code had sign. change. |
|
This might be a variant/symptom of my issue: #2069 |
|
I don't really have a config and running If you could point me to using a a custom theme I can try to recreate your solution. |
|
Yeah, they are not related. |
|
I have the same issue on Archlinux without using XRDP. |
|
@tamwile can you give more info about your setup? I am on arch and everything is working fine here. |
|
I already downgraded to 1.7.5 just after writing my previous message and it's working fine. If you still want my config it's quite similar to sshaikh i think.
GPU is an old Nvidia EDIT: i did try |
|
What is your Desktop environment? For information, I am on AMD. |
|
stumpwm |
|
never heard of it. lets try it |
|
Can anybody hitting this can try to make a screenshot from within rofi (alt+shift+s) and see if the screenshot shows up fine or is also black? that might give a hint. |
|
Where is saved the screenshot after alt+shift+s by default ? |
|
in the XDG picture folder.. normally ~/Pictures/ its also printed out where its stored if launched from terminal. |
|
Ok, the png image is not a black screen for me. |
|
Interesting, so its the mapping of the cairo surface to the screen. |
|
hmm a lot of that code has not been touched in 4 years. . .Wish I could reproduce so I could find the commit that broke it. |
|
Some code path was not hit in the past but now it is ? Is that what you think ? |
|
Not thinking anything atm. As I am pretty confused.. (why is it failing for some and not all, and something so 'basic' ) |
|
Can you try |
|
stumpwm is a tiling window manager so the normal window is taking all the screen space. |
|
Thanks. Creating a vm now, so I can do some testing.. hopefully I can reproduce. |
|
Works fine in WM.. fun. |
|
xorgrdp also works fine for me.. |
|
A saved screenshot also displays correctly for me. And I'm guessing @tamwile and I have some config or software installed in common. FWIW I don't seem to have XDG setup correctly if at all and had to use My theme also looks different to yours (even though my config is empty). |
|
yeah, I used the default theme of the distro I installed to test another bug :D. The fact screenshot works, suggests it is in the cairo_xcb surface something goes wrong, but this code has not be changed a lot (in > 4 years).. Or it has to do that I only paint the window in idle time and no idle time get scheduled, but I never seen this be an issue before... |
|
Can you run: G_MESSAGES_DEBUG=View rofi -show runon a terminal, and check if you see 'redraw, expose event and Redraw view' messages? |
I don't know if when you said 'redraw, expose event and Redraw view' it is supposed to be in that order exactly but in my case this is more like 'Redraw view, Redraw, expose event'. |
|
order does not matter.. Thanks, so the idle call is not the issue. |
|
Somebody did a bisect and found 45688b0 to be the issue. Can somebody with this issue test this patch? diff --git a/source/widgets/widget.c b/source/widgets/widget.c
index 54f8c955..35c574b8 100644
--- a/source/widgets/widget.c
+++ b/source/widgets/widget.c
@@ -252,7 +252,8 @@ void widget_draw(widget *wid, cairo_t *d) {
if (left != 0 || top != 0 || right != 0 || bottom != 0) {
// NOTE: Cairo group push/pop has same effect as cairo_save/cairo_restore,
// thus no need for these.
- cairo_push_group(d);
+ // cairo_push_group(d);
+ cairo_save(d);
cairo_set_operator(d, CAIRO_OPERATOR_ADD);
cairo_translate(d, wid->x, wid->y);
cairo_new_path(d);
@@ -409,8 +410,9 @@ void widget_draw(widget *wid, cairo_t *d) {
cairo_fill(d);
}
- cairo_pop_group_to_source(d);
- cairo_paint(d);
+ // cairo_pop_group_to_source(d);
+ // cairo_paint(d);
+ cairo_restore(d);
}
}
} |
|
bisect thanks to Zluglu |
Seems to happen on nvidia systems, rendering to PNG surface is fine, problem is with rendering to screen. Hopefully this patch fixes it. Issue: #2068
|
Should be fixed in git.. please let me know if it does not work. |
|
I confirm this is working. |
|
Fixed for me also. Many thanks to everyone! |
Rofi version (rofi -v)
1.7.6
Configuration
https://gist.github.com/sshaikh/b283cf77b7264e6672ad6709973488cc
Theme
https://gist.github.com/sshaikh/08c0431ac1e4fda665d25e2f3adf05b8
Timing report
https://gist.github.com/sshaikh/d90cb9a61fb5b42e4861d89946eff142
Launch command
rofi -show run
Step to reproduce
Just launch
Expected behavior
To see the rofi menu
Actual behavior
A black box the exact size of the rofi menu. This still functions (via keyboard or mouse), just that nothing can be seen.
Additional information
Rolling back to 1.7.5 fixes the issue. Running on Arch via XRDP - seems to work okay on a local box.
Using wayland display server protocol
I've checked if the issue exists in the latest stable release
The text was updated successfully, but these errors were encountered: