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

Wf-panel sometimes have a large delay unhiding and unhide without focus #276

Open
mark-herbert42 opened this issue Oct 10, 2024 · 10 comments

Comments

@mark-herbert42
Copy link

The behavior is somehow strange. Sometimes when I move mouse to top edge (panel is on top) panel immediately pops out. And when I over mouse over clock it can be clicked to show calendar. But - sometimes when I move mouse on top - almos nothing happens. In fact very thin line appears on top 1-2 pixels, and then nothong/ Nothing happens for a while - and I can take mouse away from the edge - but then panel unhides fully. but it appears frozen - hoovering over the clock does nothing, so clicking on some widgets. But if I am patient enough and continue clicking and hovering - it returns to life.

So it is not crashing, but the delays and lags makes the experience pretty bad with autohide function enable.

@mark-herbert42
Copy link
Author

Looks like it is a duplicate of #189. But one thing to mention - I,ve tried new xfce4-panel which finally has autohide feature fixing, and it works like a charm with wayfire 0.9. So maybe this lag issue can be handled within the panel itself

@mark-herbert42
Copy link
Author

Really it looks like issue with transactions. So to repeat this - I let the panel hide. if I immediately try to unide - perfect. But I go to firefox, thunderbird, switch between tabs. Then - try to go to panel mouse to top. I see 1pixel line, and even if I wait enough for panel t fully show up - it is just a dead picture that does not respond to clicking or hovering.

But here is part 2 - I have expose triggered by top corners. So - I move mouse up, see 1 pixel line and move mouse to the corner. Expose activates - and I see the full panel on preview. Expose seemst to flush all those transactions and when I return from expose panel is responsible and working.

So the question - can we do the kind of running all the pending transactions when we unhide the panel?maybe it is not a running flushing or something else I am not an expert in this , but the wy it behaves shows that panel unhides but somewhere in the different reality. So all we need to do is to sync those realities forcefully, itherwise the panel will hide itself again before the picture of a panel is shown on the screen.

@ammen99
Copy link
Member

ammen99 commented Oct 10, 2024

Transactions have nothing to do with hiding or unhiding the panel. Transactions concern only toplevel views, not panels.

@mark-herbert42
Copy link
Author

so bad guess... stil a question why it get stuck and not finishing unhiding. One-pixel line shows up - so panel catches the mouse on top position and started unhiding. But 1 pixel line - and freeze.

@ammen99
Copy link
Member

ammen99 commented Oct 10, 2024

My guess would be that somehow the panel is not getting wl_surface.frame_done events so that it does not update its position but it is hard to say for sure.

@mark-herbert42
Copy link
Author

To loose those events I need to swicth between several windows from moment after the panel is hidden and before I try to get it back. Tried again - panel hides. If I continue working in the window that was active before window id hidden - -it is Ok. Panel opens again no issue. If I click on ivactive window and activate it - it does not activate again,

But then - if i move mouse on top - see nothing but 1 pixel line and quickly change focus to any other window - panel show up again and activates. So somehow panel can not retrieve the focus from other window. It is doing it ok only for the window that was focused at the moment when it was hiding. But if i have switched the focus - it can not do it anymore.

@NamorNiradnug
Copy link
Collaborator

I currently use a patched version of wf-panel which leaves panel 1 pixel above the screen edge, i.e. it doesn't hide entirely, and it works absolutely fine. So I think the problem is somehow related with wayfire not rendering hidden views.

@mark-herbert42
Copy link
Author

Can you share the patch please.

@NamorNiradnug
Copy link
Collaborator

Can you share the patch please.

Sure

diff --git a/src/util/wf-autohide-window.cpp b/src/util/wf-autohide-window.cpp
index 6e785ee..caff06d 100644
--- a/src/util/wf-autohide-window.cpp
    b/src/util/wf-autohide-window.cpp
@@ -323,7  323,7 @@ bool WayfireAutohidingWindow::should_autohide() const
 
 bool WayfireAutohidingWindow::m_do_hide()
 {
-    y_position.animate(-get_allocated_height());
     y_position.animate(-get_allocated_height()   1.0);
     update_margin();
     return false; // disconnect
 }

@mark-herbert42
Copy link
Author

thank you, that works.

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

No branches or pull requests

3 participants