-
Notifications
You must be signed in to change notification settings - Fork 696
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
Application is always redrawing and update cursor even when not needed. #3813
Comments
…even when not needed.
This bug report is too vague. I agree for Cursor the current code is sub-optimal. That will be addressed in However, for drawing, the current code is quite frugal.
LayoutAndDraw ();
if (PositionCursor ())
{
Driver!.UpdateCursor ();
}
public static void LayoutAndDraw (bool forceDraw = false)
{
bool neededLayout = View.Layout (TopLevels.Reverse (), Screen.Size);
if (forceDraw)
{
Driver?.ClearContents ();
}
View.SetClipToScreen ();
View.Draw (TopLevels, neededLayout || forceDraw);
View.SetClipToScreen ();
Driver?.Refresh ();
} From this point, only views that have Any call to You can see this visually by turning on So, what specifically are you referring to when you say "Application is always redrawing"? |
The better scenario to test that I'm right with this is the Editor scenario. It's always redrawing because |
For testing this issue don't use scenario that use timers, because of course they will be drawing. Test only with scenarios that does not change anything. |
Do you remember that before existed two methods, one that clear the needs display and the other that clear the needs layout? Currently only exist for clear needs draw but not for clear needs layout. I really think that it's needed only one method for both. |
I think you didn't understanding the reason for this issue. The issue is only related when you are only moving the mouse without click or anything. In the |
Please study the fact that I have very carefully decoupled drawing from layout. It is important for correctness that they are decoupled. I am not happy with the fact that |
I really don't understand the problem with my simple and logic fix. Can you please explain to me where I'm wrong? |
I agree that when |
I didn't said to write something nor for select text 😃 |
I don't see a bug that needs fixing. I set this breakpoint and it only breaks when I actually click in Editor: Your fix (that I don't think we need) is adding complexity to a system that I worked really hard to make as simple as possible. This couples layout and draw: protected void ClearNeedsDrawAndNeedsLayout ()
{
_needsDrawRect = Rectangle.Empty;
SubViewNeedsDraw = false;
NeedsLayout = false; |
I also didn't said to add a |
Do you're using |
That why I changed the method name to |
Another detail, see in the unit tests that I changed where you commented on justifications for doubts, like I'm not really sure if I'm right. |
Having one function that does both Draw and Layout is an example of coupling. If there is a bug here (I'm open to that), the right fix would have two functions. |
But who couple it wasn't me, but I don't think it isn't a good solution having them coupled. Avoids duplicates code doing similar things for different properties. |
Let's step back and make sure there's really a bug. Can you author a simple, focused, unit test that demonstrates the bug? |
The changes I made in the unit tests already justify them. But please answer one question that you didn't before. Does this behavior happens or nor by using |
I think we should have a global 'frame rate' enforced for iteration. At the moment a lot of issues stem from iteration running too fast e.g. see #3812 To me a MainLoop should look something like (pseudocode) do
{
var dt = DateTime.Now();
RunIteration();
var took = DateTime.Now() - dt
var sleepFor = TimeSpan.FromMilliseconds(200) - took;
if(sleepFor > 0)
Task.Delay(sleepFor).Wait();
}
while(true) This solves several problems including the kinda sketchy way that 'has events' somehow has to take responsibility for blocking until there are events - except when there are timers (that being a problem in itself) etc. The iteration, drawing, event queue inspection etc should all happen as fast as possible. Then we just sleep for however long we want to enforce our frame/loop rate. Thoughts? See for example this thread:
|
@tig it's really affecting all drivers with the Editor scenario. Do you know if there is some view that need to always be draw in this scenario? and you'll see this: So, as you can see the |
I think you meant |
See the changed existed ones here 7761bb0 |
Yes. WIndows 11/WindowsDriver. |
Great idea. But, to be clear, this is a last-defense. We need to ensure correctness as much as possible first. |
Why are you so opposed to writing primitive unit tests that show a specific bug? The code you pointed to is a test for many several things and is just confusing. I am not seeing the behavior you are seeing (or I'm not configuring things right). It should be easy for you to write a ~10 line unit test that shows this bug. |
Thanks for the information. The behavior as I tell before happens with all drivers in the Editor scenario. So, some view is setting |
Damn, I will but I think this isn't difficult to understand. |
No, I didn't but I think there is some view that there is calling |
Hide StatusBar. Likely culprit as Have you tried adding a border to _textView and turning on the Draw Indicator? Can you share a video of that on your machine? |
Found it! I had forgotten I commented out all the ScrollBar code in Editor in my branch. I just switched to v2_develop and I see this: THIS is precisely why I have spent the last 3 days rewriting the abomination we call Closing this bug as WON'T FIX as the bug is actually in |
Yes it's really the |
Anyway if you want this unit test that pass in the v2_develop. [Fact]
[AutoInitShutdown]
public void Draw_Sets_NeedsDraw_And_NeedsLayout_False_When_Finished ()
{
var top = new Toplevel ();
var view = new View { Width = Dim.Fill (), Height = Dim.Fill (), CanFocus = true };
top.Add (view);
Assert.True (top.NeedsLayout);
Assert.True (top.NeedsDraw);
Assert.True (view.NeedsLayout);
Assert.True (view.NeedsDraw);
var rs = Application.Begin (top);
Application.RunIteration (ref rs);
Assert.False (top.NeedsLayout);
Assert.False (top.NeedsDraw);
Assert.False (view.NeedsLayout);
Assert.False (view.NeedsDraw);
view.SetNeedsLayout ();
Assert.True (top.NeedsLayout);
Assert.True (top.NeedsDraw);
Assert.True (view.NeedsLayout);
Assert.True (view.NeedsDraw);
Application.RunIteration (ref rs);
Assert.False (top.NeedsLayout);
Assert.False (top.NeedsDraw);
Assert.False (view.NeedsLayout);
Assert.False (view.NeedsDraw);
Application.End (rs);
top.Dispose ();
} |
Only by only moving the mouse without affect any view to be needs to redraw, the
Application
is always redrawing and updating the cursor without no need, wasting CPU resources. I found this behavior with theEditor
scenario which happens with all drivers.The text was updated successfully, but these errors were encountered: