tag_redraw() stops working in 2.8 after context change but works in 2.7? Problem of event_timer_add()? #61822

New Issue

Brent Lio · 2019-02-21T21:39:08+01:00

Brent Lio commented

2019-02-21 21:39:08 +01:00

https://developer.blender.org/T61764
As the above report mentioned,

I suspected that in 2.8, the redraw stopped because of the loss of context, where the context.area returns None.

But after second thoughts, that doesn't make any sense. They both used window_manager.event_timer_add() and seems to use it to trigger the tag_redraw().

If window change would return None since 2013, then screencasekey addon shouldn't be able to sustain its redraw over time in blender 2.79, but it does sustain it.

There are no differences that I can perceive and understand between screencasekey for 2.79 and shortcut Vur for 2.8 on how they achieved the repeated redraw over time, and yet they behave differently in two blender versions.

There must be something different between blender 2.79 & 2.8 that caused this discrepancy.

I'm not sure what type of problem this is or what is wrong, but I hope blender 2.8 can behave in the same way as 2.79 in this specific case.

Exact Description of this issue

System Information
Win 10 Pro,
AMD 1700x w 32GB & 1080

Blender Version
Broken:
2.8 positive symptom with Shortcut VUR addon and with my own script.

Worked: (optional)
2.79 with screencast key addon

Short description of error
Note: I don't think this is a problem on the Addon part since screencastkeys on 2.79 used the exact same method to achieve timely redraw for the on-screen messages.

Without window layout change, both addons worked correctly, the on-screen input message disappears after a short time.

After window layout change, context.area within MODAL method returns None, and on-screen input messages would not refresh until triggered by another input.

Returning to previous window layout won't fix the issue.

The event 'TIMER' is still triggered consistently, the screen though, would not redraw when the 'TIMER' event hits.

Exact steps for others to reproduce the error
1, Enable said addons in their corresponding version of Blender,
2, Start the modal operator with the button in the Side panel
3, Observe as the input messages disappear
4, Maximize the window, or change to a different layout
5, Notice the messages do not disappear unless new input such as MouseWheelScroll happens, and it would timely redraw for a second or two, and stop again.

According to the report here, context loss is a designed behavior of modal operator.
https://developer.blender.org/T36711

The fact it worked in 2.7 across different windows seems to be a glitch. But in the case of casting inputs from modal operator, it did work better.

2.8 version of the screencastkeys had defined a method to find the active window/area for the script to work when maximizing a window, but upon workspace change, the display will disappear completely.

https://developer.blender.org/T61764 As the above report mentioned, I suspected that in 2.8, the redraw stopped because of the loss of context, where the context.area returns None. But after second thoughts, that doesn't make any sense. They both used window_manager.event_timer_add() and seems to use it to trigger the tag_redraw(). If window change would return None since 2013, then screencasekey addon shouldn't be able to sustain its redraw over time in blender 2.79, but it does sustain it. There are no differences that I can perceive and understand between screencasekey for 2.79 and shortcut Vur for 2.8 on how they achieved the repeated redraw over time, and yet they behave differently in two blender versions. There must be something different between blender 2.79 & 2.8 that caused this discrepancy. I'm not sure what type of problem this is or what is wrong, but I hope blender 2.8 can behave in the same way as 2.79 in this specific case. **Exact Description of this issue** **System Information** Win 10 Pro, AMD 1700x w 32GB & 1080 **Blender Version** Broken: 2.8 positive symptom with Shortcut VUR addon and with my own script. Worked: (optional) 2.79 with screencast key addon **Short description of error** Note: I don't think this is a problem on the Addon part since screencastkeys on 2.79 used the exact same method to achieve timely redraw for the on-screen messages. Without window layout change, both addons worked correctly, the on-screen input message disappears after a short time. After window layout change, context.area within MODAL method returns None, and on-screen input messages would not refresh until triggered by another input. Returning to previous window layout won't fix the issue. The event 'TIMER' is still triggered consistently, the screen though, would not redraw when the 'TIMER' event hits. **Exact steps for others to reproduce the error** 1, Enable said addons in their corresponding version of Blender, 2, Start the modal operator with the button in the Side panel 3, Observe as the input messages disappear 4, Maximize the window, or change to a different layout 5, Notice the messages do not disappear unless new input such as MouseWheelScroll happens, and it would timely redraw for a second or two, and stop again. According to the report here, context loss is a designed behavior of modal operator. https://developer.blender.org/T36711 The fact it worked in 2.7 across different windows seems to be a glitch. But in the case of casting inputs from modal operator, it did work better. 2.8 version of the screencastkeys had defined a method to find the active window/area for the script to work when maximizing a window, but upon workspace change, the display will disappear completely.

Brent Lio commented

2019-02-21 21:39:08 +01:00

Added subscriber: @remotecrab131

Brent Lio changed title from ~~tag_redraw() stops working in 2.8 after context change but works in 2.7?~~ to tag_redraw() stops working in 2.8 after context change but works in 2.7? Problem of event_timer_add()?

2019-02-21 21:43:43 +01:00

Jacques Lucke commented

2019-02-22 13:02:05 +01:00

Added subscriber: @JacquesLucke

Jacques Lucke commented

2019-02-22 13:02:05 +01:00

Could you provide some instructions that allow us to reproduce the issue easily?

Try to be more precise about what the problem actually is.

Furthermore, please mention what exact version of Blender you are using.

Could you provide some instructions that allow us to reproduce the issue easily? Try to be more precise about what the problem actually is. Furthermore, please mention what exact version of Blender you are using.

Brent Lio commented

2019-02-23 00:01:24 +01:00

In #61822#625857, @JacquesLucke wrote:
Furthermore, please mention what exact version of Blender you are using.

sorry, I left the details to the previous report I made, which is here:
https://developer.blender.org/T61764

> In #61822#625857, @JacquesLucke wrote: > Furthermore, please mention what exact version of Blender you are using. sorry, I left the details to the previous report I made, which is here: https://developer.blender.org/T61764

Jacques Lucke commented

2019-02-27 15:27:23 +01:00

Why did you make two reports in the first place when they are talking about the same thing?

Could you please provide all the necessary information in one place?
You can update the original description of this report.

Make sure that you provide very clear and easy to follow steps to reproduce the issue.

Thanks you :)

Why did you make two reports in the first place when they are talking about the same thing? Could you please provide all the necessary information in one place? You can update the original description of this report. Make sure that you provide very clear and easy to follow steps to reproduce the issue. Thanks you :)

Brent Lio commented

2019-02-28 15:48:50 +01:00

In #61822#628798, @JacquesLucke wrote:
Why did you make two reports in the first place when they are talking about the same thing?

I could've just edited the title, I didn't. I guess it was my mistake thinking it's okay to post a new one. I apologize.

At the time I was thinking too much about why it behaved differently and thought I was describing 2 different issues since the first report I posted was about context.area == None causing the problem, but I felt it wasn't really the issue here.

> In #61822#628798, @JacquesLucke wrote: > Why did you make two reports in the first place when they are talking about the same thing? I could've just edited the title, I didn't. I guess it was my mistake thinking it's okay to post a new one. I apologize. At the time I was thinking too much about why it behaved differently and thought I was describing 2 different issues since the first report I posted was about context.area == None causing the problem, but I felt it wasn't really the issue here.

Jacques Lucke commented

2019-02-28 15:51:43 +01:00

Which screencast keys addon are you using? Where can I get it?

Brent Lio commented

2019-03-01 23:54:01 +01:00

Using this with Blender 2.7x allows the redraw to be triggered based on the window event timer after switching windows. No matter what layout changed, this consistently redraws based on the window event timer.
Old Screencast_key addon for 2.7x
https://github.com/sftd/blender-addons/blob/master/space_view3d_screencast_keys.py

Using this in 2.8 will cause the window event timer to trigger, but viewport will stop refreshing after a few seconds.
ShortcutVUr for 2.8
https://github.com/jayanam/shortcut_VUr

This is a supplemental example, it attaches the event timer on multiple window/area in order to solve the problem described above. However, it only works when maximizing/restoring the active window. This does not display anything in workspaces that the addon operator didn't start in.
New Screencast_key addon for 2.8
https://github.com/nutti/Screencast-Keys

**Using this with Blender 2.7x allows the redraw to be triggered based on the window event timer after switching windows. No matter what layout changed, this consistently redraws based on the window event timer.** Old Screencast_key addon for 2.7x https://github.com/sftd/blender-addons/blob/master/space_view3d_screencast_keys.py **Using this in 2.8 will cause the window event timer to trigger, but viewport will stop refreshing after a few seconds.** ShortcutVUr for 2.8 https://github.com/jayanam/shortcut_VUr **This is a supplemental example, it attaches the event timer on multiple window/area in order to solve the problem described above. However, it only works when maximizing/restoring the active window. This does not display anything in workspaces that the addon operator didn't start in.** New Screencast_key addon for 2.8 https://github.com/nutti/Screencast-Keys

Sebastian Parborg commented

2019-06-11 11:16:30 +02:00

Added subscriber: @ZedDB

Sebastian Parborg commented

2019-06-11 11:16:30 +02:00

Changed status from 'Open' to: 'Resolved'

Sebastian Parborg closed this issue

2019-06-11 11:16:30 +02:00

Sebastian Parborg self-assigned this 2019-06-11 11:16:30 +02:00

Sebastian Parborg commented

2019-06-11 11:16:30 +02:00

I can't seem to reproduce this issue with shortcut_VUr. The viewport seems to update fine.

If this is still an issue for you, let me know and we'll reopen this,

I can't seem to reproduce this issue with `shortcut_VUr`. The viewport seems to update fine. If this is still an issue for you, let me know and we'll reopen this,

Sign in to join this conversation.

No Label

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

tag_redraw() stops working in 2.8 after context change but works in 2.7? Problem of event_timer_add()? #61822