[Wesnoth-bugs] [bug #23318] Window Geometry not recognized

[Johannes Jordan]

Follow-up Comment #21, bug #23318 (project wesnoth):

As the reporter I agree it can be closed at this point. Thanks for dealing
with this bug!

___

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 #23318] Window Geometry not recognized

[Johannes Jordan]

Follow-up Comment #18, bug #23318 (project wesnoth):

With 1.13.4 the issue is much better and different.
In many cases, the window gets redrawn correctly.
In some cases, Wesnoth still operates in the old, smaller resolution, until I
click somewhere (but clicking helps! and it did not before).
I also could not find a case where the drawing area was not the same as the
clickable area.

When a dialog is played out (e.g. campaign start) and I resize the window
during that time, I can trigger the following error message:

20160309 15:45:51 error general: An error due to possibly invalid WML
occurred
The error message is :
Failed to show a dialog, which doesn't fit on the screen.

When reporting the bug please include the following error message :
src/gui/widgets/window.cpp:1074 in function 'layout' found the following
problem: Failed to size window; wanted size 3322,98 available size 1091,667
screen size 1273,697.



However I think it rarely occurs that someone resizes the window during a
dialog.

To conclude, it is not perfect but much better with 1.13.4.

___

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 #23318] Window Geometry not recognized

[Johannes Jordan]

Follow-up Comment #16, bug #23318 (project wesnoth):

The original bug report is not about a crash and the problem still persists.


___

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 #23318] Window Geometry not recognized

[Johannes Jordan]

Follow-up Comment #14, bug #23318 (project wesnoth):

I tested on HEAD of your branch, it includes your commit and the crash seems
to be solved. :-)

It is not pretty -- http://imgur.com/pKYRo1k
But this is another issue.

Cannot comment on the original issue as redrawing after any window size
changes in-game is broken.

___

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 #23318] Window Geometry not recognized

[Johannes Jordan]

Follow-up Comment #12, bug #23318 (project wesnoth):

I investigated further.

Wesnoth reports on the console:
Checking video mode: 1672x1041x24...
Setting mode to 1672x1041x24

Two ways to reproduce the segfault:

1. While the game is loading the main screen, resize the window. This should
be doable on any window manager with Alt+Right mouse

2. Open the game in tiling window manager herbstluftwm in tiling mode. The
window is resized by the wm according to the current layout (actual window
size will be different to 1672x1041).

Only happens on SDL2 branch.

___

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 #23318] Window Geometry not recognized

[Johannes Jordan]

Follow-up Comment #9, bug #23318 (project wesnoth):

On SDL2 branch the problem persists, I also get segfaults if the window is too
small during startup.

==22644== Invalid read of size 4
==22644==at 0x4EB8CDD: ??? (in /usr/lib/libSDL2-2.0.so.0.2.1)
==22644==by 0x4EAD769: ??? (in /usr/lib/libSDL2-2.0.so.0.2.1)
==22644==by 0x4ED97FF: ??? (in /usr/lib/libSDL2-2.0.so.0.2.1)
==22644==by 0x14EEF0E: sdl_blit(surface const&, SDL_Rect*, surface&,
SDL_Rect*) (utils.hpp:113)
==22644==by 0x1F7AE44: loadscreen::draw_screen(std::string const&)
(loadscreen.cpp:236)
==22644==by 0x1F7B761: loadscreen::start_stage(char const*)
(loadscreen.cpp:377)
==22644==by 0x13881D4: do_gameloop(std::vector > const&) (wesnoth.cpp:597)
==22644==by 0x138A1D6: main (wesnoth.cpp:989)
==22644==  Address 0x184e1664 is not stack'd, malloc'd or (recently) free'd
==22644==
==22644==
==22644== Process terminating with default action of signal 11 (SIGSEGV)

I'm giving up on this for 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 #23318] Window Geometry not recognized

[Johannes Jordan]

Follow-up Comment #7, bug #23318 (project wesnoth):

Sorry I think my last comment was misleading. With dialogs open you get 100%
reproducability.

But also *without* dialogs open you get about 50% reproducability.
Also you get two different effects as I described in my first report. Often
the area drawn is different from the area recognized for mouse input.

I understand this would be really hard to debug on Windows though.
I can offer to test your SDL2 branch on my setup though. If you don't tell me
otherwise, I will try with https://github.com/wesnoth/wesnoth/tree/sdl2

___

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 #23318] Window Geometry not recognized

[Johannes Jordan]

Follow-up Comment #4, bug #23318 (project wesnoth):

Thanks for looking into this. With geometry changes I mean sudden changes to
location and size of the Wesnoth window. While the location probably doesn't
matter it is the changes in size that confuse Wesnoth.

To reproduce the error you may try herbstluftwm: http://herbstluftwm.org/
Create a few tiles then run wesnoth and move the wesnoth window around. Or
toggle fullscreen back and forth (herbstluftwm fullscreen mode, not Wesnoth
fullscreen mode).

100% success rate you get when you open up a menu (e.g. right-click popup
menu) in wesnoth and then change the size (toggle fullscreen). Wesnoth will
not realize the change.

___

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 #23318] Window Geometry not recognized

[Johannes Jordan]

Follow-up Comment #2, bug #23318 (project wesnoth):

I understand nobody is really interested in fixing this right now, although it
is a really annoying issue indeed.

I would greatly appreciate if you could consolidate the code such as the mouse
coordinate system is in sync with the drawing coordinate system. I would
assume that you will be happy to have it this way already when you make a jump
to SDL2 or Qt.

Then while resizes are still problematic, at least I can instantly see it fail
due to a black area in the window and also in most cases the problem would be
gone. Because in most cases, the window is drawn out correctly, only the mouse
doesn't go as far as it should.

The cases where also the drawing gets the window size wrong are less
prominent, and these are the only cases where I see it might very well be
SDL's fault.

___

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 #23318] Window Geometry not recognized

[Johannes Jordan]

URL:
  

 Summary: Window Geometry not recognized
 Project: Battle for Wesnoth
Submitted by: ypnos
Submitted on: Mi 25 Feb 2015 17:54:09 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.12.1
Operating System: Arch Linux

___

Details:

I have two very reproducable (50% chance) problems with window geometry:

* The game does not recognize the new geometry. This leads to portions of the
GUI out of view or black areas in the window.
* The game draws correctly into the new window size but has a limited
coordinate system for mouse inputs. So any mouse movement outside a subregion
of the window is not recognized.

Basically, there seem to be two different systems that need notification of
new window geometry, one responsible for the graphics, the other for mouse
input handling.

I think it should be easy to solve the second problem by coupling mouse input
geometry to graphics geometry.

For the first problem I don't know what is going wrong exactly on Wesnoth's
side. This problem exists since a long time though.
I am using a tiling window manager. When in floating mode, the problem seems
not to occur.




___

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