[9fans] drawterm osx-x11 on x86_64

[9fans] drawterm osx-x11 on x86_64

[Mark van Atten]

For the record---to compile drawterm
(http://code.google.com/p/drawterm/) with CONF=osx-x11 on x86_64 (in
my case running 10.8.5), just add the required substitution to the
makefile:

Make.osx-x11

20 - arch=`uname -m|sed 's/i.86/386/;s/Power Macintosh/power/'`; \
20 + arch=`uname -m|sed 's/i.86/386/;s/Power
Macintosh/power/;s/x86_64/amd64/'`; \

For the moment, I prefer this to drawterm-cocoa because there is no
flicker, and window borders remain intact when reshaping with B1 or
B2.

Mark.

Re: [9fans] drawterm osx-x11 on x86_64

[Jeff Sickel]

On Nov 21, 2013, at 4:40 AM, Mark van Atten <vanattenmark@gmail.com> wrote:

> For the moment, I prefer this to drawterm-cocoa because there is no
> flicker, and window borders remain intact when reshaping with B1 or
> B2.

Ah, but with drawterm-cocoa you get proper rio resizing, which I find
very useful when using multiple displays.

There are updates coming shortly to address some of the other cocoa
issues.

-jas

Re: [9fans] drawterm osx-x11 on x86_64

[erik quanstrom]

On Thu Nov 21 09:59:42 EST 2013, jas@corpus-callosum.com wrote:
>
> On Nov 21, 2013, at 4:40 AM, Mark van Atten <vanattenmark@gmail.com> wrote:
>
> > For the moment, I prefer this to drawterm-cocoa because there is no
> > flicker, and window borders remain intact when reshaping with B1 or
> > B2.
>
> Ah, but with drawterm-cocoa you get proper rio resizing, which I find
> very useful when using multiple displays.

i agree with that, but i think there are some cases where all
the windows are redrawn for no reason.  such as, when 9term
is brought from behind another window, it sometimes triggers
a screen resize.  i imagine this is an off-by-borderwidth sort
of issue.

- erik

Re: [9fans] drawterm osx-x11 on x86_64

[Steven Stallion]

On Thu, Nov 21, 2013 at 4:40 AM, Mark van Atten <vanattenmark@gmail.com> wrote:
> For the moment, I prefer this to drawterm-cocoa because there is no
> flicker, and window borders remain intact when reshaping with B1 or
> B2.

Ah! That drives me nuts too, though it is nice to get proper
fullscreen support. I've submitted a patch to rio that disables the
resizing on sources. Take a look at patch/rio-noresize. After that,
just start rio with -R. It's a hack, but it serves my sanity quite
well!

Steve

Re: [9fans] drawterm osx-x11 on x86_64

[Jeff Sickel]

Just don’t upgrade to 10.9 yet:

http://support.apple.com/kb/HT5293?viewlocale=en_US&locale=en_US
http://xquartz.macosforge.org/landing/

You can install XQuartz and keep going, but the upgrade from
earlier releases does delete X11 rather ruthlessly.

-jas



On Nov 21, 2013, at 9:03 AM, Steven Stallion <sstallion@gmail.com> wrote:

> On Thu, Nov 21, 2013 at 4:40 AM, Mark van Atten <vanattenmark@gmail.com> wrote:
>> For the moment, I prefer this to drawterm-cocoa because there is no
>> flicker, and window borders remain intact when reshaping with B1 or
>> B2.
> 
> Ah! That drives me nuts too, though it is nice to get proper
> fullscreen support. I've submitted a patch to rio that disables the
> resizing on sources. Take a look at patch/rio-noresize. After that,
> just start rio with -R. It's a hack, but it serves my sanity quite
> well!
> 
> Steve
> 

Re: [9fans] drawterm osx-x11 on x86_64

[Jeff Sickel]

On Nov 21, 2013, at 9:03 AM, Steven Stallion <sstallion@gmail.com> wrote:

> On Thu, Nov 21, 2013 at 4:40 AM, Mark van Atten <vanattenmark@gmail.com> wrote:
>> For the moment, I prefer this to drawterm-cocoa because there is no
>> flicker, and window borders remain intact when reshaping with B1 or
>> B2.
> 
> Ah! That drives me nuts too, though it is nice to get proper
> fullscreen support. I've submitted a patch to rio that disables the
> resizing on sources. Take a look at patch/rio-noresize. After that,
> just start rio with -R. It's a hack, but it serves my sanity quite
> well!

Will one of you describe the flicker you speak of?  I see flicker on
Linux’s drawterm X11 when resizing rio windows and other operations,
given the round trip time, though the flicker is less on fast local
networks.


- jas

Re: [9fans] drawterm osx-x11 on x86_64

[Mark van Atten]

On Fri, Nov 22, 2013 at 1:02 AM, Jeff Sickel <jas@corpus-callosum.com> wrote:

> Will one of you describe the flicker you speak of?  I see flicker on
> Linux’s drawterm X11 when resizing rio windows and other operations,
> given the round trip time, though the flicker is less on fast local
> networks.

You are right, of course, that the presence of flicker may depend on
various things, and my original message was too elliptic.

I drawterm only to a virtual machine on the same computer.

My setup: Mac Mini Late 2012 with 10.8.5. Virtual machine:  Virtualbox
4.3.0, Bell Labs iso, 1024MB system memory, VT-x/AMD-V and Nested
Paging on, 32 MB video memory, Intel PRO/1000 MT Desktop bridged
adapter en1 Wi-Fi (AirPort). Mountain Lion's DHCP server enabled.

Drawterm for osx-x11 built from the current sources at
http://code.google.com/p/drawterm/
Drawterm for osx-cocoa built from the current sources at
https://bitbucket.org/jas/drawterm-cocoa

In the cocoa version, when sweeping a rio window all borders will
flicker continuously.  On resizing with B1 or B2, in addition to the
flicker,  border lines will fail to meet or meet but not at the
corner. All this independently of window size and sweep speed. When
creating a new window in sam, three or all corners always break open a
little.

In the x11 version, when sweeping normally, there will be no flicker
at any size, and, when sweeping quickly, flicker on one side only (the
side where the mouse pointer is). I haven't seen border lines fail to
meet or meet at the wrong place, whether in rio or in sam.

Mark.

Re: [9fans] drawterm osx-x11 on x86_64

[Mark van Atten]

Well, I wrote `the current sources', but that was wrong: I just
checked bitbucket again and saw your commits of the last few hours. So
I pulled the updates and rebuilt. To my surprise, the phenomena remain
exactly the same. This time I got a message though:

objc[3785]: Object 0x7fb261297930 of class NSConcreteMapTable
autoreleased with no pool in place - just leaking - break on
objc_autoreleaseNoPool() to debug

Mark.


On Fri, Nov 22, 2013 at 10:05 AM, Mark van Atten <vanattenmark@gmail.com> wrote:
> On Fri, Nov 22, 2013 at 1:02 AM, Jeff Sickel <jas@corpus-callosum.com> wrote:
>
>> Will one of you describe the flicker you speak of?  I see flicker on
>> Linux’s drawterm X11 when resizing rio windows and other operations,
>> given the round trip time, though the flicker is less on fast local
>> networks.
>
> You are right, of course, that the presence of flicker may depend on
> various things, and my original message was too elliptic.
>
> I drawterm only to a virtual machine on the same computer.
>
> My setup: Mac Mini Late 2012 with 10.8.5. Virtual machine:  Virtualbox
> 4.3.0, Bell Labs iso, 1024MB system memory, VT-x/AMD-V and Nested
> Paging on, 32 MB video memory, Intel PRO/1000 MT Desktop bridged
> adapter en1 Wi-Fi (AirPort). Mountain Lion's DHCP server enabled.
>
> Drawterm for osx-x11 built from the current sources at
> http://code.google.com/p/drawterm/
> Drawterm for osx-cocoa built from the current sources at
> https://bitbucket.org/jas/drawterm-cocoa
>
> In the cocoa version, when sweeping a rio window all borders will
> flicker continuously.  On resizing with B1 or B2, in addition to the
> flicker,  border lines will fail to meet or meet but not at the
> corner. All this independently of window size and sweep speed. When
> creating a new window in sam, three or all corners always break open a
> little.
>
> In the x11 version, when sweeping normally, there will be no flicker
> at any size, and, when sweeping quickly, flicker on one side only (the
> side where the mouse pointer is). I haven't seen border lines fail to
> meet or meet at the wrong place, whether in rio or in sam.
>
> Mark.

Re: [9fans] drawterm osx-x11 on x86_64

[Jeff Sickel]

On Nov 22, 2013, at 3:18 AM, Mark van Atten <vanattenmark@gmail.com> wrote:

> Well, I wrote `the current sources', but that was wrong: I just
> checked bitbucket again and saw your commits of the last few hours. So
> I pulled the updates and rebuilt. To my surprise, the phenomena remain
> exactly the same. This time I got a message though:

rio flickers natively, you just have to be on a really slow machine
to see it.  Or in this case a slow cpu server (virtualbox) or a slow
network connection to the cpu server (wifi to a remote site in my case).

The recent drawterm-cocoa changes clean up full screen changes.

> objc[3785]: Object 0x7fb261297930 of class NSConcreteMapTable
> autoreleased with no pool in place - just leaking - break on
> objc_autoreleaseNoPool() to debug

This morning’s push you get rid of that autoreleasepool warning.

Re: [9fans] drawterm osx-x11 on x86_64

[Mark van Atten]

[-- Attachment #1: Type: text/plain, Size: 522 bytes --]

Simply pinging the virtualbox cpu server gives, over a number of tests, avg
rtt around 150 µs  from both osx-x11 and osx-cocoa drawterms. (Indeed, the
latest push of osx-cocoa no longer gives the warning.)

I hope at some point it will become clear what is the matter---perhaps, as
you suggest, in my setup; although so far I don't see why the different
results I get should be due to that. Let me know if I haven't given enough
data.

And certainly the fullscreen integration of your version is nice!

Mark.

[-- Attachment #2: Type: text/html, Size: 730 bytes --]

Re: [9fans] drawterm osx-x11 on x86_64

[Mark van Atten]

[-- Attachment #1: Type: text/plain, Size: 821 bytes --]

Same difference under qemu 1.6.1 instead of virtualbox 4.3.0.

Does anyone have experiences to share? If not, then perhaps whatever the
issue is on my setup is too local.

Mark.



On Mon, Nov 25, 2013 at 6:44 PM, Mark van Atten <vanattenmark@gmail.com>wrote:

> Simply pinging the virtualbox cpu server gives, over a number of tests,
> avg rtt around 150 µs  from both osx-x11 and osx-cocoa drawterms.
> (Indeed, the latest push of osx-cocoa no longer gives the warning.)
>
> I hope at some point it will become clear what is the matter---perhaps, as
> you suggest, in my setup; although so far I don't see why the different
> results I get should be due to that. Let me know if I haven't given enough
> data.
>
> And certainly the fullscreen integration of your version is nice!
>
> Mark.
>
>

[-- Attachment #2: Type: text/html, Size: 1402 bytes --]