[trunk@23678] Atlas Editor: The map / simulation displayed at 1/4 bottom left corner of its canvas (OSX)

[wik]

The problem

 

Looks like something related to retina display, because if I move Editor window to 2nd monitor (not retina) and resize a bit, it shows okay:

and when I move it back to retina, it changes back as per first screenshot.

 

[wraitii]

I think this is a know bug on all platforms. @Stan`?

[Stan`]

@Nescio had it on linux but I never experienced it on Windows.

[Nescio]

1 hour ago, Stan` said:

@Nescio had it on linux but I never experienced it on Windows.

Yes, this is something I have too, for years now, both when I open up atlas from inside the game and when I run it from the command line with:

binaries/system/pyrogenesis -editor

It probably has something to do with the fact I have a high resolution (3840×2160) and Atlas treats system settings differently than 0 A.D. @vladislavbelov taught me to use:

GDK_SCALE=1 binaries/system/pyrogenesis -editor

instead, and then Atlas does use the full space indeed.

[wik]

I've discovered the same problem in OpenGL samples from wxWidgets wxWidgets-3.0.5/samples/opengl/

And then I found solution here: https://github.com/wxWidgets/wxWidgets/pull/1470/files
Multipluing size by scaling factor solves the problem:

const wxSize ClientSize = GetClientSize() * GetContentScaleFactor();

[wik]

Looks like it also helps with altas editor, if I multiply client size by scale factor GetContentScaleFactor():

void Canvas::OnResize(wxSizeEvent&)
{
	// Be careful not to send 'resize' messages to the game before we've
	// told it that this canvas exists
    if (! m_SuppressResize) {
        const wxSize ClientSize = GetClientSize() * GetContentScaleFactor();
		POST_MESSAGE(ResizeScreen, (ClientSize.GetWidth(), ClientSize.GetHeight()));
		// TODO: fix flashing
    }
}

void Canvas::InitSize()
{
	m_SuppressResize = false;
    const wxSize ClientSize = GetClientSize() * GetContentScaleFactor();
	SetSize(ClientSize);
}

[wraitii]

6 hours ago, wik said:

Looks like it also helps with altas editor, if I multiply client size by scale factor GetContentScaleFactor

Seems to me you've been sent from above to fix WxWidgets bugs, wik  .

If you want to, you can make a patch on Phabricator, see SubmittingPatches and Phabricator .

[wik]

On 5/28/2020 at 6:57 AM, wraitii said:

Seems to me you've been sent from above to fix WxWidgets bugs, wik  .

If you want to, you can make a patch on Phabricator, see SubmittingPatches and Phabricator .

Thanks, I'll try

With those changes applied the map fills whole canvas, but I just noticed that it still have offset between mouse pointer and place where it triggers action for some reason. On non-retina display it only happens with my changes applied, so, I probably missing something.

UPDATE: it only happens on retina display, if I move window to non-retina display it back to normal after resize (I keep forgetting to resize)

Edited May 29, 2020 by wik

[Stan`]

Maybe the bug at https://trac.wildfiregames.com/ticket/2851?

[wik]

 

12 hours ago, wik said:

still have offset between mouse pointer and place where it triggers action for some reason

This is because scale factor need to applied to wxMouseEvent::GetPosition(), I found some clarification in wxWidgets documentation https://docs.wxwidgets.org/trunk/classwx_g_l_canvas.html

Quote

Please note that wxGLContext always uses physical pixels, even on the platforms where wxWindow uses logical pixels, affected by the coordinate scaling, on high DPI displays. Thus, if you want to set the OpenGL view port to the size of entire window, you must multiply the result returned by wxWindow::GetClientSize() by wxWindow::GetContentScaleFactor() before passing it to glViewport(). Same considerations apply to other OpenGL functions and other coordinates, notably those retrieved from wxMouseEvent in the event handlers.

As an experiment I've tried to apply scale factor of 2.0 (retina) in AlterElevation tool

POST_MESSAGE(BrushPreview, (true, Position(evt.GetPosition() * 2.0))); // multiplied by 2.0 (retina)

Here is illustration, the mouse pointer, in both cases, in the middle (approx) of square 

Before:

After:

It feels like "Position::Position(const wxPoint& pt)" definition from ScenarioEditor.cpp might be a good place to implement this uniformly.

I also need to figure out how to get scale factor from wxPoint.

[wik]

I've done some more experiments with opengl examples from wxWidgets and it turns out that if we skip glViewport the system will sort it out automagically,

i.e. scale factor will be applied and even mouse position will be adjusted transparently, wxWidgets will behave as it would run on any other screen

// Renderer.cpp
void CRenderer::SetViewport(const SViewPort &vp)
{
	m_Viewport = vp;
	//glViewport((GLint)vp.m_X,(GLint)vp.m_Y,(GLsizei)vp.m_Width,(GLsizei)vp.m_Height);
}

I've tried to debug GL_VIEWPORT state with the following snippets

int viewport[4];
glGetIntegerv(GL_VIEWPORT, viewport);
std::printf("m_Viewport %d x %d\n", m_Viewport.m_Width, m_Viewport.m_Height);
std::printf("GL_VIEWPORT %d x %d\n", viewport[2], viewport[3]);

Here is results:

Editor: 
m_Viewport 734 x 718
GL_VIEWPORT 1468 x 1436

Game:
m_Viewport 1440 x 900 (also noticed that every 4th call to SetViewport has strange vp 2048 x 2048, i.e. something in 0ad game code tries to set this)
GL_VIEWPORT 1440 x 900 (remains stable, I believe not scaled, probably because some magic in SDL update)

Unfortunatelly I didn't find documentation about default behavior for glViewport and when it should or shouldn't be used explicitly.

 

[wik]

Note, I'm using SDL2-2.0.12 and the following commit could probably explain why game, unlike editor, running in 1:1 mode: https://hg.libsdl.org/SDL/rev/46b094f7d20e

i.e. SDL overrides default behavior and the application treated as non hidpi compatible and running in 1:1 mode by default.

I should probably give it a go with SDL2-2.0.5

[Stan`]

Thanks for a the investigation Mac Users definety wi thank you

keep up the great work.

[wraitii]

That seems logical, the doc indicates that content scaling is not applied automatically when running a GL viewport:

Quote

Please note that wxGLContext always uses physical pixels, even on the platforms where wxWindow uses logical pixels, affected by the coordinate scaling, on high DPI displays. Thus, if you want to set the OpenGL view port to the size of entire window, you must multiply the result returned by wxWindow::GetClientSize() by wxWindow::GetContentScaleFactor() before passing it to glViewport(). Same considerations apply to other OpenGL functions and other coordinates, notably those retrieved from wxMouseEvent in the event handlers.

 

[wik]

14 hours ago, wik said:

Note, I'm using SDL2-2.0.12 and the following commit could probably explain why game, unlike editor, running in 1:1 mode: https://hg.libsdl.org/SDL/rev/46b094f7d20e

i.e. SDL overrides default behavior and the application treated as non hidpi compatible and running in 1:1 mode by default.

I should probably give it a go with SDL2-2.0.5

I've tried it with SDL2-2.0.5 (the version we currently have in trunk) https://github.com/0ad/0ad/blob/master/libraries/osx/build-osx-libs.sh#L27

And it turns out that removing explicit call to glViewport allows game to scale automatically (2880 x 1800), below some examples with and without glViewport

void CRenderer::SetViewport(const SViewPort &vp)
{
	m_Viewport = vp;
	//glViewport((GLint)vp.m_X,(GLint)vp.m_Y,(GLsizei)vp.m_Width,(GLsizei)vp.m_Height);
}

With glViewport (m_Viewport m_Width X m_Height => 1440 x 900)

Without glViewport (after commenting out the line, also glGetIntegerv(GL_VIEWPORT) reports 2880 x 1800)

But I've noticed that some text disappeared in "auto-scaled" version, perhaps something to do with fonts.

[wik]

 

On 5/27/2020 at 9:16 AM, Nescio said:

It probably has something to do with the fact I have a high resolution (3840×2160) and Atlas treats system settings differently than 0 A.D. @vladislavbelov taught me to use:

GDK_SCALE=1 binaries/system/pyrogenesis -editor

I haven't tried, but there seems to be similar solution for OSX, i.e. disable high dpi capability on per application basis:

https://github.com/ioquake/ioq3/issues/422#issuecomment-541193050

/Contents/Info.plist, right above the "" line:

<key>NSHighResolutionCapable</key>
<false/>

Could be an intermediate option before transitioning to hdpi support.

[wik]

I also tried SDL2-2.0.12 + flags |= SDL_WINDOW_ALLOW_HIGHDPI

It enables auto-scaling to 2880 x 1800, but has the same missing text issue as in SDL2-2.0.5

m_Viewport 1440 x 900
GL_VIEWPORT 2880 x 1800

[Stan`]

Maybe https://code.wildfiregames.com/D1925 ?

[Nescio]

23 minutes ago, Stan` said:

Maybe https://code.wildfiregames.com/D1925 ?

Thanks for pointing that one out, but no, I just tried it out and it does not solve the reported Atlas issue, at least not for me (Fedora 32, gcc 10.1.1).

[Stan`]

It likely needs *all* the other patches

[Nescio]

2 minutes ago, Stan` said:

It likely needs *all* the other patches

D1925 probably needs to be rebased and updated. Also, from the summary:

Probable TODO: fix screenshots, fix atlas, fix the cinematic. g_GuiScale should probably be added back. Also names are probably not perfect.

[wik]

On 6/9/2020 at 6:09 PM, Stan` said:

Maybe https://code.wildfiregames.com/D1925 ?

Thanks for pointing that out, I'll need to study it

Meanwhile I've done some more experiments and noticed that if we only multiply glViewport components by scale factor, then mouse coordinates not affected.
Previously I've tried to multiple ClientSize in OnResize and InitSize, but those broke mouse coordinates.

 

void CRenderer::SetViewport(const SViewPort &vp)
{
	m_Viewport = vp;
	const float scaleFactor = 2.f;
	glViewport((GLint)vp.m_X * scaleFactor,(GLint)vp.m_Y * scaleFactor,(GLsizei)vp.m_Width * scaleFactor,(GLsizei)vp.m_Height * scaleFactor);
}

Looks a bit more promising IMHO, but still need to figure out how to get content scale factor in there.

[Stan`]

Thanks for all the work so far Do not hesitate to drop by IRC sometime.

[Nescio]

This issue is solved with 25111 (at least on my end).