[9fans] 9vx.OSX bug: resize on second display causes window to go wrong

[9fans] 9vx.OSX bug: resize on second display causes window to go wrong

[Anthony Sorace]

I have a 10.5 MacBook with an external display attached. When I start
9vx, things look normal. I can resize the window on the main display.
If I move it to the second display and resize, the window goes from
"good" to "bad":

http://strand1.com/who/anthony/bug/good.png
http://strand1.com/who/anthony/bug/bad.png

Resizing the window back to the original geometry makes the window "good" again.

Note that this is "just" a display issue. Things within 9vx continue
to run just fine, and can update the display (although that becomes
unreliable, especially in the portion of rio windows to the left of
where they should be). Dragging my mouse over where the rio window
border should be causes the cursor to turn into the "resize" cursor,
and resizing works fine, dragging the still-slanted window around.

This happens independent of what's running within 9vx: I see the same
thing even with no rio.
Anthony

Re: [9fans] 9vx.OSX bug: resize on second display causes window to go wrong

[andrey mirtchovski]

I think the problem comes from 9vx picking up the main display's
dimensions as the preallocation for "full screen". Drawterm has a fix
for that which loops through all the currently attached displays and
picks up the one with the largest size to decide what the "maximum
dimensions" should be.

here's the relevant code from drawterm:

/* figure out which display is the largest and return its bounds so we can
 * preallocate drawterm's screen to that
 */
Point
get_largest_screen()
{
	CGDirectDisplayID 	*displaylist;
	CGDisplayCount 		displaycount;
	OSErr 				err;
	int i;
	Point max = Pt(0, 0);
	Point curr;
	err = CGGetActiveDisplayList(0, NULL, &displaycount);
	if(err != noErr)
		sysfatal("can not enumerate active displays");

	displaylist = (CGDirectDisplayID *)malloc(displaycount *
sizeof(CGDirectDisplayID));
	if(displaylist == NULL)
		sysfatal("can not allocate memory for display list");

	err = CGGetActiveDisplayList(displaycount, displaylist, &displaycount);
	if(err != noErr)
		sysfatal("can not obtain active display list");

	for(i = 0; i < displaycount; i++) {
		curr.x = CGDisplayPixelsWide(displaylist[i]);
		curr.y = CGDisplayPixelsHigh(displaylist[i]);

		if(max.x < curr.x)
			max.x = curr.x;
		if(max.y < curr.y)
			max.y = curr.y;
	}

	free(displaylist);

	return max;

}
you will need to modify _screeninit() in 9vx/osx/screen.c to something like:

Point max = get_largest_screen();
osx.fullscreenr = Rect(0, 0, max.size.width, max.size.height);

this is tentative. i have no second screen to test right now.

On Thu, Jul 3, 2008 at 8:38 AM, Anthony Sorace <anothy@gmail.com> wrote:
> I have a 10.5 MacBook with an external display attached. When I start
> 9vx, things look normal. I can resize the window on the main display.
> If I move it to the second display and resize, the window goes from
> "good" to "bad":
>
> http://strand1.com/who/anthony/bug/good.png
> http://strand1.com/who/anthony/bug/bad.png
>
> Resizing the window back to the original geometry makes the window "good" again.
>
> Note that this is "just" a display issue. Things within 9vx continue
> to run just fine, and can update the display (although that becomes
> unreliable, especially in the portion of rio windows to the left of
> where they should be). Dragging my mouse over where the rio window
> border should be causes the cursor to turn into the "resize" cursor,
> and resizing works fine, dragging the still-slanted window around.
>
> This happens independent of what's running within 9vx: I see the same
> thing even with no rio.
> Anthony
>
>

Re: [9fans] 9vx.OSX bug: resize on second display causes window to go wrong

[Uriel]

This seems to be (given my limited understanding) similar to what
acme-sac is doing.

Is there any way we could solve the current state of affairs with
slightly diverging gui/draw codebases for p9p, drawterm, 9vx, acme-sac
and inferno-os? Each seems to have a set of bugs that somewhat
overlaps with the other projects, and they have to be rediscovered,
and the fixes moved around again and again.

That also would mean that new ports, to for example win32, would
propagate much more easily (or at least as far as the gui code is
concerned).

Peace and best wishes

uriel

On Thu, Jul 3, 2008 at 4:57 PM, andrey mirtchovski
<mirtchovski@gmail.com> wrote:
> I think the problem comes from 9vx picking up the main display's
> dimensions as the preallocation for "full screen". Drawterm has a fix
> for that which loops through all the currently attached displays and
> picks up the one with the largest size to decide what the "maximum
> dimensions" should be.
>
> here's the relevant code from drawterm:
>
> /* figure out which display is the largest and return its bounds so we can
>  * preallocate drawterm's screen to that
>  */
> Point
> get_largest_screen()
> {
>        CGDirectDisplayID       *displaylist;
>        CGDisplayCount          displaycount;
>        OSErr                           err;
>        int i;
>        Point max = Pt(0, 0);
>        Point curr;
>        err = CGGetActiveDisplayList(0, NULL, &displaycount);
>        if(err != noErr)
>                sysfatal("can not enumerate active displays");
>
>        displaylist = (CGDirectDisplayID *)malloc(displaycount *
> sizeof(CGDirectDisplayID));
>        if(displaylist == NULL)
>                sysfatal("can not allocate memory for display list");
>
>        err = CGGetActiveDisplayList(displaycount, displaylist, &displaycount);
>        if(err != noErr)
>                sysfatal("can not obtain active display list");
>
>        for(i = 0; i < displaycount; i++) {
>                curr.x = CGDisplayPixelsWide(displaylist[i]);
>                curr.y = CGDisplayPixelsHigh(displaylist[i]);
>
>                if(max.x < curr.x)
>                        max.x = curr.x;
>                if(max.y < curr.y)
>                        max.y = curr.y;
>        }
>
>        free(displaylist);
>
>        return max;
>
> }
> you will need to modify _screeninit() in 9vx/osx/screen.c to something like:
>
> Point max = get_largest_screen();
> osx.fullscreenr = Rect(0, 0, max.size.width, max.size.height);
>
> this is tentative. i have no second screen to test right now.
>
> On Thu, Jul 3, 2008 at 8:38 AM, Anthony Sorace <anothy@gmail.com> wrote:
>> I have a 10.5 MacBook with an external display attached. When I start
>> 9vx, things look normal. I can resize the window on the main display.
>> If I move it to the second display and resize, the window goes from
>> "good" to "bad":
>>
>> http://strand1.com/who/anthony/bug/good.png
>> http://strand1.com/who/anthony/bug/bad.png
>>
>> Resizing the window back to the original geometry makes the window "good" again.
>>
>> Note that this is "just" a display issue. Things within 9vx continue
>> to run just fine, and can update the display (although that becomes
>> unreliable, especially in the portion of rio windows to the left of
>> where they should be). Dragging my mouse over where the rio window
>> border should be causes the cursor to turn into the "resize" cursor,
>> and resizing works fine, dragging the still-slanted window around.
>>
>> This happens independent of what's running within 9vx: I see the same
>> thing even with no rio.
>> Anthony
>>
>>
>
>

Re: [9fans] 9vx.OSX bug: resize on second display causes window to go wrong

[andrey mirtchovski]

> Is there any way we could solve the current state of affairs

if that's the royal "we" you're using then sure, there is a way\x10:
simply download the latest versions of all programs that you're
interested in unifying (p9p, drawterm, 9vx, acme-sac, inferno), merge
the osx drawing code (using the best solution available, which for
some things is 9vx, for others acme-sac, for thirds yet, p9p),
redistribute the new code to the respective maintainers and then track
each new release of the code (or periodically check) for changes to
redistribute.

the only reason you're not in the same mess with the X11 code is that
the base everyone cloned was mature.

Re: [9fans] 9vx.OSX bug: resize on second display causes window to go wrong

[Uriel]

X11 code is still broken in various places, for example in Inferno-os
(and even more so acme-sac, which is missing some of the updates that
made it into inferno-os).

So my comment applies as much to the osx code as to the x11 code, and
to hypothetical win32 code. That is the whole point, that every time
there is a new port, the same dance starts over again, and even when
code is 'mature' its maintenance in some systems (eg., p9p) is better
than others (eg., inferno-os). If there was a single codebase shared
across projects none of this would be an issue at all.

uriel

On Thu, Jul 3, 2008 at 5:30 PM, andrey mirtchovski
<mirtchovski@gmail.com> wrote:
>> Is there any way we could solve the current state of affairs
>
> if that's the royal "we" you're using then sure, there is a way :
> simply download the latest versions of all programs that you're
> interested in unifying (p9p, drawterm, 9vx, acme-sac, inferno), merge
> the osx drawing code (using the best solution available, which for
> some things is 9vx, for others acme-sac, for thirds yet, p9p),
> redistribute the new code to the respective maintainers and then track
> each new release of the code (or periodically check) for changes to
> redistribute.
>
> the only reason you're not in the same mess with the X11 code is that
> the base everyone cloned was mature.
>

Re: [9fans] 9vx.OSX bug: resize on second display causes window to go wrong

[ron minnich]

On Thu, Jul 3, 2008 at 8:55 AM, Uriel <uriel99@gmail.com> wrote:
> If there was a single codebase shared
> across projects none of this would be an issue at all.

you are right but it's a hard problem, we're all tight for time, so
the only fix is for somebody to step up and do it.

But your question, 'wouldn't it be better to have one thing to do all
this different stuff', is certainly answered "probably".

ron

Re: [9fans] 9vx.OSX bug: resize on second display causes window to

[erik quanstrom]

> But your question, 'wouldn't it be better to have one thing to do all
> this different stuff', is certainly answered "probably".

you mean like a fileserver?

- erik

Re: [9fans] 9vx.OSX bug: resize on second display causes window to go wrong

[underspecified]

Greetings,

Thanks for finding that snippet, andrey :-) I was about to search the
acme-sac code for it so I could post a patch.
After looking through the 9vx code, it looks like russ is handling
memory allocation for the screen a little differently
than acme-sac (and possibly drawterm).

In acme-sac, I:

* calculate the maximum possible screen size using the function andrey posted
* allocate a giant block of memory to handle this size once in screeninit()

In 9vx it looks like russ is:

* calculating the new window size on resize event
* dynamically reallocating the necessary memory for each resize

Perhaps this has something to do with andrey's problems?

--underspecified

P.S. 9vx will only go into fullscreen on the main display.
The follow fix should work, but I can't test it now, as I am without
an external monitor.

diff -r ca5b26cbe43a src/9vx/osx/screen.c
--- a/src/9vx/osx/screen.c      Tue Jul 01 17:27:41 2008 -0400
+++ b/src/9vx/osx/screen.c      Fri Jul 04 01:20:59 2008 +0900
@@ -513,7 +511,9 @@
       }else{
               HideWindow(osx.window);
               oldwindow = osx.window;
-               BeginFullScreen(&restore, 0, 0, 0, &osx.window, 0, 0);
+               GDHandle device;
+               GetWindowGreatestAreaDevice(&osx.window,
kWindowTitleBarRgn, &device, NULL);
+               BeginFullScreen(&fullScreenRestore, device, 0, 0,
&osx.window, 0, 0);
               osx.isfullscreen = 1;
               osx.fullscreentime = msec();


On Fri, Jul 4, 2008 at 1:05 AM, ron minnich <rminnich@gmail.com> wrote:
> On Thu, Jul 3, 2008 at 8:55 AM, Uriel <uriel99@gmail.com> wrote:
>> If there was a single codebase shared
>> across projects none of this would be an issue at all.
>
> you are right but it's a hard problem, we're all tight for time, so
> the only fix is for somebody to step up and do it.
>
> But your question, 'wouldn't it be better to have one thing to do all
> this different stuff', is certainly answered "probably".
>
> ron
>
>

Re: [9fans] 9vx.OSX bug: resize on second display causes window to go wrong

[andrey mirtchovski]

> -               BeginFullScreen(&restore, 0, 0, 0, &osx.window, 0, 0);
> +               GDHandle device;
> +               GetWindowGreatestAreaDevice(&osx.window,
> kWindowTitleBarRgn, &device, NULL);
> +               BeginFullScreen(&fullScreenRestore, device, 0, 0,
> &osx.window, 0, 0);

oops, my bad: i missed that code from the original patch it appeared
in because i had failed to properly document it in my mail to Russ.

thanks for the sharp eyes!

Re: [9fans] 9vx.OSX bug: resize on second display causes window to go wrong

[underspecified]

Sorry, I was a bit hasty with the patch. This one should compile properly:

diff -r ca5b26cbe43a src/9vx/osx/screen.c
--- a/src/9vx/osx/screen.c	Tue Jul 01 17:27:41 2008 -0400
+++ b/src/9vx/osx/screen.c	Fri Jul 04 01:31:37 2008 +0900
@@ -513,7 +511,9 @@
 	}else{
 		HideWindow(osx.window);
 		oldwindow = osx.window;
-		BeginFullScreen(&restore, 0, 0, 0, &osx.window, 0, 0);
+		GDHandle device;
+		GetWindowGreatestAreaDevice(osx.window, kWindowTitleBarRgn, &device, NULL);
+		BeginFullScreen(&restore, device, 0, 0, &osx.window, 0, 0);
 		osx.isfullscreen = 1;
 		osx.fullscreentime = msec();
 	}

--underspecified

On Fri, Jul 4, 2008 at 1:25 AM, underspecified <underspecified@gmail.com> wrote:
> Greetings,
>
> Thanks for finding that snippet, andrey :-) I was about to search the
> acme-sac code for it so I could post a patch.
> After looking through the 9vx code, it looks like russ is handling
> memory allocation for the screen a little differently
> than acme-sac (and possibly drawterm).
>
> In acme-sac, I:
>
> * calculate the maximum possible screen size using the function andrey posted
> * allocate a giant block of memory to handle this size once in screeninit()
>
> In 9vx it looks like russ is:
>
> * calculating the new window size on resize event
> * dynamically reallocating the necessary memory for each resize
>
> Perhaps this has something to do with andrey's problems?
>
> --underspecified
>
> P.S. 9vx will only go into fullscreen on the main display.
> The follow fix should work, but I can't test it now, as I am without
> an external monitor.
>
> diff -r ca5b26cbe43a src/9vx/osx/screen.c
> --- a/src/9vx/osx/screen.c      Tue Jul 01 17:27:41 2008 -0400
> +++ b/src/9vx/osx/screen.c      Fri Jul 04 01:20:59 2008 +0900
> @@ -513,7 +511,9 @@
>       }else{
>               HideWindow(osx.window);
>               oldwindow = osx.window;
> -               BeginFullScreen(&restore, 0, 0, 0, &osx.window, 0, 0);
> +               GDHandle device;
> +               GetWindowGreatestAreaDevice(&osx.window,
> kWindowTitleBarRgn, &device, NULL);
> +               BeginFullScreen(&fullScreenRestore, device, 0, 0,
> &osx.window, 0, 0);
>               osx.isfullscreen = 1;
>               osx.fullscreentime = msec();
>
>
> On Fri, Jul 4, 2008 at 1:05 AM, ron minnich <rminnich@gmail.com> wrote:
>> On Thu, Jul 3, 2008 at 8:55 AM, Uriel <uriel99@gmail.com> wrote:
>>> If there was a single codebase shared
>>> across projects none of this would be an issue at all.
>>
>> you are right but it's a hard problem, we're all tight for time, so
>> the only fix is for somebody to step up and do it.
>>
>> But your question, 'wouldn't it be better to have one thing to do all
>> this different stuff', is certainly answered "probably".
>>
>> ron
>>
>>
>

Re: [9fans] 9vx.OSX bug: resize on second display causes window to go wrong

[Russ Cox]

> Is there any way we could solve the current state of affairs with
> slightly diverging gui/draw codebases for p9p, drawterm, 9vx, acme-sac
> and inferno-os? Each seems to have a set of bugs that somewhat
> overlaps with the other projects, and they have to be rediscovered,
> and the fixes moved around again and again.
>
> That also would mean that new ports, to for example win32, would
> propagate much more easily (or at least as far as the gui code is
> concerned).

Every time I edit any of this code I think the same thing,
as I'm sure do the maintainers of the other copies,
but as the environments are all unpleasant and subtly different,
it always seems better to get in and get out quickly than to
linger pondering an interface that would satisfy all the
involved parties.

Are you just whining or actually stepping forward to do
something about it?

Russ