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

2017-02-03 Thread Wedge009 
Update of bug #25186 (project wesnoth):

 Open/Closed:Open => Closed 

___

Follow-up Comment #24:

Thanks.

___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs

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

2017-02-03 Thread Jyrki Vesterinen 
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 mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs

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

2017-02-03 Thread Wedge009 
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!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs

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

2017-01-03 Thread Jyrki Vesterinen 
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 new message windows likely set up new draw timers and kept
increasing the rate of draw events (after only 5 messages it would already
have been up to 150 draw messages per second) to the point where the game
generated draw events faster than it could handle them.

To fix bug #25356, I made the event pump to drop superfluous draw events.
According to this post
, it caused the
[message] lag to disappear.

Marking this bug report as a duplicate of bug #25356.

___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs

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

2016-10-26 Thread Pentarctagon 
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 as 1920x1054 (maximized on a 1920x1080 monitor).

Though for some reason I am not able to reproduce this issue on Windows (same
resolution).

___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs

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

2016-10-25 Thread Gregory A Lundberg 
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 using reads:

[event]
name=test
first_time_only=no

[while]
[true][/true]
[do]
[message]
speaker="narrator"

[option]
label="label"
[/option]
[/message]
[/do]
[/while]
[/event]

And I cannot reproduce the problem either by:

- Clicking slowly on the OK button once it finishes repainting for a minute

- Clicking as quickly as I can on the OK button for a minute

- Clicking slowly on the "label" about once per second for a minute

- Clicking as quickly as I can on the "label" for a minute

In all cases, when I stop clicking on the message and click X to close the
program, the Are-you-sure dialog appears immediately.

This is using current master, to commit 1b4 as either debug or release
builds.

I will say, though, that the entire message handing, in all cases is abysmally
slow. When I'm using the OK button, it takes nearly a second to repaint fully.
When I add a message= and counter to see something change, it takes about 1/4
second per click, and queues a couple clicks if I get ahead. This is all at
full-screen of 1140x851.  It's a bit faster at 800x600 (smallest I can go) but
the OK button still seems a bit slow.

___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs

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

2016-10-25 Thread Pentarctagon 
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 mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs

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

2016-10-25 Thread Daniel 
Update of bug #25186 (project wesnoth):

  Status: In Progress => Ready For Test 

___

Follow-up Comment #17:

@Pentarctagon: please test whether this fixed the issue.

___

Reply to this item at:

  

___
  Nachricht gesendet von/durch Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs

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

2016-10-25 Thread Gregory A Lundberg 
Update of bug #25186 (project wesnoth):

  Status:None => In Progress


___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs

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

2016-10-25 Thread Gregory A Lundberg 
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:

  

___
  Message sent via/by Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs

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

2016-10-24 Thread Daniel 
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
https://github.com/wesnoth/wesnoth/blob/1.13.5/src/gui/widgets/window.cpp#L616
it might happen that if the new window is shown before before the draw timer
of the old window has stopped, the code will creatre another draw timer so
that the there will not twice as many draw events in the queue repating  this
process over and over coudl thne result in 3 or more as many draw events
beeing fired.


I also think the reason why this doesn't happen with speaker=unit is that we
here
https://github.com/wesnoth/wesnoth/blob/1.13.5/data/lua/wml/message.lua#L357
issue a [redraw] in case that a valid unit was chosen as speaker 

___

Reply to this item at:

  

___
  Nachricht gesendet von/durch Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs

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

2016-10-24 Thread Pentarctagon 
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:

  

___
  Message sent via/by Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs

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

2016-10-24 Thread Daniel 
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 gesendet von/durch Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs

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

2016-10-24 Thread Daniel 
Follow-up Comment #13, bug #25186 (project wesnoth):

go*

___

Reply to this item at:

  

___
  Nachricht gesendet von/durch Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs

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

2016-10-24 Thread Daniel 
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 of cliking is. Resizing
main window is.


tad said its unrelated to speaker. Not sure what to believe now.

___

Reply to this item at:

  

___
  Nachricht gesendet von/durch Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs

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

2016-10-23 Thread Pentarctagon 
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 ?? () from
/usr/lib/nvidia-370/libnvidia-glcore.so.370.28
#2  0x7fffe69b8eb3 in ?? () from
/usr/lib/nvidia-370/libnvidia-glcore.so.370.28
#3  0x7fffe69d1453 in ?? () from
/usr/lib/nvidia-370/libnvidia-glcore.so.370.28
#4  0x7fffe69d172c in ?? () from
/usr/lib/nvidia-370/libnvidia-glcore.so.370.28
#5  0x7fffe6a8cc12 in ?? () from
/usr/lib/nvidia-370/libnvidia-glcore.so.370.28
#6  0x7fffe670df62 in ?? () from
/usr/lib/nvidia-370/libnvidia-glcore.so.370.28
#7  0x7fffe670f397 in ?? () from
/usr/lib/nvidia-370/libnvidia-glcore.so.370.28
#8  0x7fffe672b4f4 in ?? () from
/usr/lib/nvidia-370/libnvidia-glcore.so.370.28
#9  0x76ddec54 in ?? () from
/usr/lib/x86_64-linux-gnu/libSDL2-2.0.so.0
#10 0x76dd8386 in ?? () from
/usr/lib/x86_64-linux-gnu/libSDL2-2.0.so.0
#11 0x76e31449 in ?? () from
/usr/lib/x86_64-linux-gnu/libSDL2-2.0.so.0
#12 0x76e329ca in ?? () from
/usr/lib/x86_64-linux-gnu/libSDL2-2.0.so.0
#13 0x011c4162 in sdl::twindow::render (this=0x1e060f0) at
src/sdl/window.cpp:110
#14 0x01169c73 in CVideo::flip (this=0x1ccdc50) at src/video.cpp:391
#15 0x004afa5a in gui2::event::thandler::draw (this=0x3cbab20,
force=false) at src/gui/core/event/handler.cpp:537
#16 0x004af1df in gui2::event::thandler::handle_event (this=0x3cbab20,
event=...) at src/gui/core/event/handler.cpp:357
#17 0x010a1c9f in events::pump () at src/events.cpp:593
#18 0x005cc0b7 in gui2::twindow::show (this=0xf545f00, restore=true,
auto_close_timeout=0) at src/gui/widgets/window.cpp:638
#19 0x004b50ca in gui2::tdialog::show (this=0xfb053b0, video=...,
auto_close_time=0) at src/gui/dialogs/dialog.cpp:68
#20 0x00b05fcb in gui2::show_wml_message (video=..., title="",
message="", left=0x82afb00, right=0x0, options=..., input=...) at
src/gui/dialogs/wml_message.cpp:187
#21 0x0064c68f in lua_gui2::show_message_dialog (L=0x7fffc45c3ac8,
video=...) at src/scripting/lua_gui2.cpp:357
#22 0x00653522 in lua_kernel_base::video_dispatch_impl
(this=0x7fffc0974a50, L=0x7fffc45c3ac8, callback=0x64b3c8
) at
src/scripting/lua_kernel_base.cpp:127
#23 0x00657401 in video_dispatch<_gui2::show_message_dialog>
(L=0x7fffc45c3ac8) at src/scripting/lua_kernel_base.cpp:121
#24 0x00f939f4 in luaD_precall (L=0x7fffc45c3ac8, func=0x7fffc2b432a0,
nresults=2) at src/lua/ldo.cpp:365
#25 0x00fa7c39 in luaV_execute (L=0x7fffc45c3ac8) at
src/lua/lvm.cpp:1134
#26 0x00f94040 in luaD_call (L=0x7fffc45c3ac8, func=0x7fffc2b43290,
nResults=1) at src/lua/ldo.cpp:496
#27 0x00f9409e in luaD_callnoyield (L=0x7fffc45c3ac8,
func=0x7fffc2b43290, nResults=1) at src/lua/ldo.cpp:506
#28 0x00f8fe47 in f_call (L=0x7fffc45c3ac8, ud=0x7fff1d10) at
src/lua/lapi.cpp:942
#29 0x00f92ede in luaD_rawrunprotected (L=0x7fffc45c3ac8, f=0xf8fe12
, ud=0x7fff1d10) at src/lua/ldo.cpp:142
#30 0x00f94870 in luaD_pcall (L=0x7fffc45c3ac8, func=0xf8fe12
, u=0x7fff1d10, old_top=880, ef=864) at
src/lua/ldo.cpp:727
#31 0x00f8ff25 in lua_pcallk (L=0x7fffc45c3ac8, nargs=1, nresults=1,
errfunc=-3, ctx=0, k=0x0) at src/lua/lapi.cpp:968
#32 0x0064636e in luaW_pcall_internal (L=0x7fffc45c3ac8, nArgs=1,
nRets=1) at src/scripting/lua_common.cpp:940
#33 0x006463f5 in luaW_pcall (L=0x7fffc45c3ac8, nArgs=1, nRets=1,
allow_wml_error=false) at src/scripting/lua_common.cpp:956
#34 0x0061a74e in (anonymous namespace)::lua_synchronize::query_lua
(this=0x7fff22f0, side=1, function_index=2, cfg=...) at
src/scripting/game_lua_kernel.cpp:2581
#35 0x0061a59b in (anonymous namespace)::lua_synchronize::query_user
(this=0x7fff22f0, side=1) at src/scripting/game_lua_kernel.cpp:2558
#36 0x00699c67 in user_choice_manager::ask_local_choice
(this=0x7fff1ff0) at src/synced_user_choice.cpp:343
#37 0x0069a4bf in user_choice_manager::get_user_choice_internal
(name="input", uch=..., sides=std::set with 1 elements = {...}) at
src/synced_user_choice.cpp:419
#38 0x006988eb in mp_sync::get_user_choice (name="input", uch=...,
side=1) at src/synced_user_choice.cpp:216
#39 0x0061a9c0 in intf_synchronize_choice (L=0x7fffc45c3ac8) at
src/scripting/game_lua_kernel.cpp:2625
#40 0x00f939f4 in luaD_precall (L=0x7fffc45c3ac8, func=0x7fffc2b43240,
nresults=1) at src/lua/ldo.cpp:365
#41 0x00fa7c39 in luaV_execute (L=0x7fffc45c3ac8) at
src/lua/lvm.cpp:1134
#42 0x00f94040 in luaD_call (L=0x7fffc45c3ac8, func=0x7fffc2b42f40,
nResults=0) at src/lua/ldo.cpp:496

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

2016-10-23 Thread Pentarctagon 
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.

___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs

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

2016-10-23 Thread Daniel 
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 time. If
you don't have a profiler and just a normal debugger, you can try to reproduce
this in a debugger and then at 5 random times while the game is freezing with
100% cpu usage press stop in the debugger and look at the stacktrace.

___

Reply to this item at:

  

___
  Nachricht gesendet von/durch Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs

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

2016-10-23 Thread Pentarctagon 
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 cores), and after that at 0:51 the graph shows one of the cores as
being constantly at 100% usage.

___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs

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

2016-10-23 Thread Daniel 
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:

  

___
  Nachricht gesendet von/durch Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs

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

2016-10-18 Thread Pentarctagon 
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:

  

___
  Message sent via/by Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs

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

2016-10-18 Thread Daniel 
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 this item at:

  

___
  Nachricht gesendet von/durch Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs

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

2016-10-18 Thread Pentarctagon 
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 this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs

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

2016-10-18 Thread Daniel 
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:

  

___
  Nachricht gesendet von/durch Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs

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

2016-10-18 Thread Pentarctagon 
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]
  [/message]
[/do]
  [/while]


For whatever reason, the issue seems to be specifying the speaker.  Removing
the speaker="narrator" line causes the lag to not appear.

___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs

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

2016-10-15 Thread Pentarctagon 
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
Priority: 5 - Normal
  Item Group: User Interface
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
 Release: 1.13.5+dev
Operating System: Linux Mint

___

Details:

The more options that get chosen, the more longer it takes for the [message]
loop to refresh, eventually to the point that the UI becomes difficult to use
and System Monitor shows Wesnoth as using 100% of one cpu core.  If I exit the
loop and then re-enter it, the UI lag is gone until I start choosing more
options.

A video showing what's happening: https://www.youtube.com/watch?v=tdjEQBMz-Ec

I'm not able to reproduce this outside of my add-on though; just setting up a
[message] in a loop with a single option and clicking it a bunch of times
never begins to lag, for example.




___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs