* [9fans] 9vx.OSX bug: resize on second display causes window to go wrong @ 2008-07-03 14:38 Anthony Sorace 2008-07-03 14:57 ` andrey mirtchovski 0 siblings, 1 reply; 11+ messages in thread From: Anthony Sorace @ 2008-07-03 14:38 UTC (permalink / raw) To: 9fans 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [9fans] 9vx.OSX bug: resize on second display causes window to go wrong 2008-07-03 14:38 [9fans] 9vx.OSX bug: resize on second display causes window to go wrong Anthony Sorace @ 2008-07-03 14:57 ` andrey mirtchovski 2008-07-03 15:13 ` Uriel 0 siblings, 1 reply; 11+ messages in thread From: andrey mirtchovski @ 2008-07-03 14:57 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 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 > > ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [9fans] 9vx.OSX bug: resize on second display causes window to go wrong 2008-07-03 14:57 ` andrey mirtchovski @ 2008-07-03 15:13 ` Uriel 2008-07-03 15:30 ` andrey mirtchovski 2008-07-03 17:28 ` Russ Cox 0 siblings, 2 replies; 11+ messages in thread From: Uriel @ 2008-07-03 15:13 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 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 >> >> > > ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [9fans] 9vx.OSX bug: resize on second display causes window to go wrong 2008-07-03 15:13 ` Uriel @ 2008-07-03 15:30 ` andrey mirtchovski 2008-07-03 15:55 ` Uriel 2008-07-03 17:28 ` Russ Cox 1 sibling, 1 reply; 11+ messages in thread From: andrey mirtchovski @ 2008-07-03 15:30 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs > 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. ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [9fans] 9vx.OSX bug: resize on second display causes window to go wrong 2008-07-03 15:30 ` andrey mirtchovski @ 2008-07-03 15:55 ` Uriel 2008-07-03 16:05 ` ron minnich 0 siblings, 1 reply; 11+ messages in thread From: Uriel @ 2008-07-03 15:55 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 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. > ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [9fans] 9vx.OSX bug: resize on second display causes window to go wrong 2008-07-03 15:55 ` Uriel @ 2008-07-03 16:05 ` ron minnich 2008-07-03 16:10 ` [9fans] 9vx.OSX bug: resize on second display causes window to erik quanstrom 2008-07-03 16:25 ` [9fans] 9vx.OSX bug: resize on second display causes window to go wrong underspecified 0 siblings, 2 replies; 11+ messages in thread From: ron minnich @ 2008-07-03 16:05 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [9fans] 9vx.OSX bug: resize on second display causes window to 2008-07-03 16:05 ` ron minnich @ 2008-07-03 16:10 ` erik quanstrom 2008-07-03 16:25 ` [9fans] 9vx.OSX bug: resize on second display causes window to go wrong underspecified 1 sibling, 0 replies; 11+ messages in thread From: erik quanstrom @ 2008-07-03 16:10 UTC (permalink / raw) To: 9fans > 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [9fans] 9vx.OSX bug: resize on second display causes window to go wrong 2008-07-03 16:05 ` ron minnich 2008-07-03 16:10 ` [9fans] 9vx.OSX bug: resize on second display causes window to erik quanstrom @ 2008-07-03 16:25 ` underspecified 2008-07-03 16:32 ` andrey mirtchovski 2008-07-03 16:33 ` underspecified 1 sibling, 2 replies; 11+ messages in thread From: underspecified @ 2008-07-03 16:25 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 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 > > ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [9fans] 9vx.OSX bug: resize on second display causes window to go wrong 2008-07-03 16:25 ` [9fans] 9vx.OSX bug: resize on second display causes window to go wrong underspecified @ 2008-07-03 16:32 ` andrey mirtchovski 2008-07-03 16:33 ` underspecified 1 sibling, 0 replies; 11+ messages in thread From: andrey mirtchovski @ 2008-07-03 16:32 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs > - 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! ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [9fans] 9vx.OSX bug: resize on second display causes window to go wrong 2008-07-03 16:25 ` [9fans] 9vx.OSX bug: resize on second display causes window to go wrong underspecified 2008-07-03 16:32 ` andrey mirtchovski @ 2008-07-03 16:33 ` underspecified 1 sibling, 0 replies; 11+ messages in thread From: underspecified @ 2008-07-03 16:33 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 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 >> >> > ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [9fans] 9vx.OSX bug: resize on second display causes window to go wrong 2008-07-03 15:13 ` Uriel 2008-07-03 15:30 ` andrey mirtchovski @ 2008-07-03 17:28 ` Russ Cox 1 sibling, 0 replies; 11+ messages in thread From: Russ Cox @ 2008-07-03 17:28 UTC (permalink / raw) To: 9fans > 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2008-07-03 17:28 UTC | newest] Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2008-07-03 14:38 [9fans] 9vx.OSX bug: resize on second display causes window to go wrong Anthony Sorace 2008-07-03 14:57 ` andrey mirtchovski 2008-07-03 15:13 ` Uriel 2008-07-03 15:30 ` andrey mirtchovski 2008-07-03 15:55 ` Uriel 2008-07-03 16:05 ` ron minnich 2008-07-03 16:10 ` [9fans] 9vx.OSX bug: resize on second display causes window to erik quanstrom 2008-07-03 16:25 ` [9fans] 9vx.OSX bug: resize on second display causes window to go wrong underspecified 2008-07-03 16:32 ` andrey mirtchovski 2008-07-03 16:33 ` underspecified 2008-07-03 17:28 ` Russ Cox
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).