[Wesnoth-bugs] [bug #25186] [message] lag

Update of bug #25186 (project wesnoth): Open/Closed:Open => Closed ___ Follow-up Comment #24: Thanks. ___ Reply to this item at:

[Wesnoth-bugs] [bug #25186] [message] lag

Follow-up Comment #23, bug #25186 (project wesnoth): Wedge009: Yes. ___ Reply to this item at: ___ Message sent via/by Gna! http://gna.org/

[Wesnoth-bugs] [bug #25186] [message] lag

Follow-up Comment #22, bug #25186 (project wesnoth): Given bug #25356 is fixed, is this one also fixed? ___ Reply to this item at: ___ Message sent via/by Gna!

[Wesnoth-bugs] [bug #25186] [message] lag

Update of bug #25186 (project wesnoth): Status: Ready For Test => Duplicate ___ Follow-up Comment #21: This bug was apparently caused by draw event flooding. As gfgtdf speculated in comment 15, the

[Wesnoth-bugs] [bug #25186] [message] lag

Follow-up Comment #20, bug #25186 (project wesnoth): Ah, right, EQ is one of my macros for shortening typing out [variable]: #define EQ VAR VAL [variable] name={VAR} equals={VAL} [/variable] #enddef I am still able to reproduce the problem with your code. Wesnoth reports its resolution

[Wesnoth-bugs] [bug #25186] [message] lag

Follow-up Comment #19, bug #25186 (project wesnoth): Cut-and-paste of your example yields the following error: error config: Error loading game configuration files Macro/file 'EQ' is missing Replacing the offending line with [true][/true] In HttT S01, then, the full test I am

[Wesnoth-bugs] [bug #25186] [message] lag

Follow-up Comment #18, bug #25186 (project wesnoth): The issue still occurs. ___ Reply to this item at: ___ Message sent via/by Gna! http://gna.org/

[Wesnoth-bugs] [bug #25186] [message] lag

Update of bug #25186 (project wesnoth): Status: In Progress => Ready For Test ___ Follow-up Comment #17: @Pentarctagon: please test whether this fixed the issue.

[Wesnoth-bugs] [bug #25186] [message] lag

Update of bug #25186 (project wesnoth): Status:None => In Progress ___ Reply to this item at: ___ Message

[Wesnoth-bugs] [bug #25186] [message] lag

Follow-up Comment #16, bug #25186 (project wesnoth): PR 842 solves the specific complaint but does not solve the problem of [message] being generally slow and causing crashes during resize. ___ Reply to this item at:

[Wesnoth-bugs] [bug #25186] [message] lag

Follow-up Comment #15, bug #25186 (project wesnoth): Well, at least we have a workaround then: we could add an wesnoth.wml_actions.redraw {} at the end of the lua [message] implmementation. I think one possible reason why this lag appears is that here

[Wesnoth-bugs] [bug #25186] [message] lag

Follow-up Comment #14, bug #25186 (project wesnoth): It does. The cpu usage still goes up to 7-9%, but it drops back to 4% once I stop clicking, and the UI never lags or freezes. ___ Reply to this item at:

[Wesnoth-bugs] [bug #25186] [message] lag

Follow-up Comment #12, bug #25186 (project wesnoth): Desow the lag o away if you add a [redraw] after the [message]? ___ Reply to this item at: ___ Nachricht

[Wesnoth-bugs] [bug #25186] [message] lag

Follow-up Comment #13, bug #25186 (project wesnoth): go* ___ Reply to this item at: ___ Nachricht gesendet von/durch Gna! http://gna.org/

[Wesnoth-bugs] [bug #25186] [message] lag

Follow-up Comment #11, bug #25186 (project wesnoth): In the discussion here: https://www.wesnoth.org/irclogs/2016/10/%23wesnoth-dev.2016-10-24.log starting with 20161024 16:53:33< tad_carlucci> gfgtdf, HttT S01 I can cause issues with any [message] speaker= does not seem to be related. Speed

[Wesnoth-bugs] [bug #25186] [message] lag

Follow-up Comment #10, bug #25186 (project wesnoth): I used gdb and got a few stacktraces, and they're all identical to the below except for a few memory addresses changing: (gdb) bt #0 0x7fffe6abd51e in ?? () from /usr/lib/nvidia-370/libnvidia-glcore.so.370.28 #1 0x7fffe69b8b35 in ??

[Wesnoth-bugs] [bug #25186] [message] lag

Follow-up Comment #9, bug #25186 (project wesnoth): Alright, I'll try the debugger. I had actually tried using valgrind/callgrind with Wesnoth's debug build earlier today, but it froze on the main menu after taking ~10 minutes to start up.

[Wesnoth-bugs] [bug #25186] [message] lag

Follow-up Comment #8, bug #25186 (project wesnoth): > Ram usage not particularly, but the CPU does increase noticeably .. Thx for this information. Hm ok i think the easiest Way to figure out what's wrong would be to rprpdce this in a profiler and then just check what the cpu is doing all the

[Wesnoth-bugs] [bug #25186] [message] lag

Follow-up Comment #7, bug #25186 (project wesnoth): Ram usage not particularly, but the CPU does increase noticeably - Wesnoth is shown as taking 100% of a single logical CPU core. You can see in the video I linked starting at 0:42 Wesnoth is taking ~12% of the total CPU (4 physical/8 logical

[Wesnoth-bugs] [bug #25186] [message] lag

Follow-up Comment #6, bug #25186 (project wesnoth): When the lag appears does wesnoths ram or cpu useage increate noticably? ___ Reply to this item at: ___

[Wesnoth-bugs] [bug #25186] [message] lag

Follow-up Comment #5, bug #25186 (project wesnoth): No change. It is specifically related to the "narrator" value though; specifying the speaker as "unit" does not result in lag, for example. ___ Reply to this item at:

[Wesnoth-bugs] [bug #25186] [message] lag

Follow-up Comment #4, bug #25186 (project wesnoth): Cold you please test whether it still happens if you rmeove the wesnoth.deselect_hex() here: https://github.com/wesnoth/wesnoth/blob/1.13.5/data/lua/wml/message.lua#L347 ? ___ Reply to

[Wesnoth-bugs] [bug #25186] [message] lag

Follow-up Comment #3, bug #25186 (project wesnoth): I haven't tried putting the code in every single mainline scenario, but I tried placing it in Aethermaw's existing start event, and the lag occurred with no mods enabled. ___ Reply to

[Wesnoth-bugs] [bug #25186] [message] lag

Follow-up Comment #2, bug #25186 (project wesnoth): Just to be sure, putting this code in any mainline scenario reproduces this issue without any additional mods? ___ Reply to this item at:

[Wesnoth-bugs] [bug #25186] [message] lag

Follow-up Comment #1, bug #25186 (project wesnoth): After some more investigation, I discovered I can reproduce the issue with just this code: [while] {EQ var $null} [do] [message] speaker="narrator" [option] label="label" [/option]

[Wesnoth-bugs] [bug #25186] [message] lag

URL: Summary: [message] lag Project: Battle for Wesnoth Submitted by: pentarctag0n Submitted on: Sat 15 Oct 2016 08:38:52 PM UTC Category: Bug Severity: 3 - Normal