Some NS port changes

classic Classic list List threaded Threaded
20 messages Options
Reply | Threaded
Open this post in threaded view
|

Some NS port changes

Alan Third
I’ve had some time to work on fixing some stuff in the NS port this
weekend. I’ve uploaded the changes to scratch/ns/next. It’s based on
master.

I think the branch should have got rid of most (if not all) of the
flickering, although it has introduced a strange bug related to
non‐native fullscreen. Horizontal scrollbars are also not right under
GNUstep, but I don’t know where I’ve gone wrong.

I’ve not tried it myself, but it may be worth cherrypicking commit
7dcce0a574a6b614961fb61c2b0936f56472f4df into emacs-26.
--
Alan Third

Reply | Threaded
Open this post in threaded view
|

Re: Some NS port changes

Eli Zaretskii
> Date: Sun, 13 Jan 2019 23:19:50 +0000
> From: Alan Third <[hidden email]>
>
> I’ve not tried it myself, but it may be worth cherrypicking commit
> 7dcce0a574a6b614961fb61c2b0936f56472f4df into emacs-26.

If this helps, it's fine with me to cherrypick that commit.

Thanks.

Reply | Threaded
Open this post in threaded view
|

Re: Some NS port changes

Alan Third
On Mon, Jan 14, 2019 at 05:42:27PM +0200, Eli Zaretskii wrote:
> > Date: Sun, 13 Jan 2019 23:19:50 +0000
> > From: Alan Third <[hidden email]>
> >
> > I’ve not tried it myself, but it may be worth cherrypicking commit
> > 7dcce0a574a6b614961fb61c2b0936f56472f4df into emacs-26.
>
> If this helps, it's fine with me to cherrypick that commit.

Thanks I’ve done some testing and it looks good in emacs-26, so I’ve
pushed it up.

BTW, I’ve accidentally pushed a commit with an invalid email address
to scratch/ns/next. Now that I’ve published it I know I’m not supposed
to rewrite history, but do we care too much about that on scratch
branches?
--
Alan Third

Reply | Threaded
Open this post in threaded view
|

Re: Some NS port changes

Stefan Monnier
> BTW, I’ve accidentally pushed a commit with an invalid email address
> to scratch/ns/next.  Now that I’ve published it I know I’m not supposed
> to rewrite history, but do we care too much about that on scratch
> branches?

Branches under the `scratch/` prefix can be ... scratched!
So rewrite at will,


        Stefan


Reply | Threaded
Open this post in threaded view
|

Re: Some NS port changes

Alan Third
On Tue, Jan 15, 2019 at 11:33:19AM -0500, Stefan Monnier wrote:
> > BTW, I’ve accidentally pushed a commit with an invalid email address
> > to scratch/ns/next.  Now that I’ve published it I know I’m not supposed
> > to rewrite history, but do we care too much about that on scratch
> > branches?
>
> Branches under the `scratch/` prefix can be ... scratched!
> So rewrite at will,

Thanks!
--
Alan Third

Reply | Threaded
Open this post in threaded view
|

Re: Some NS port changes

Charles A. Roelli
In reply to this post by Alan Third
> Date: Sun, 13 Jan 2019 23:19:50 +0000
> From: Alan Third <[hidden email]>
>
> I’ve had some time to work on fixing some stuff in the NS port this
> weekend. I’ve uploaded the changes to scratch/ns/next. It’s based on
> master.

Thanks!  It builds and runs fine on 10.6.  In all cases where I could
reliably trigger a flicker with master, there is no more flickering
with this branch.

Reply | Threaded
Open this post in threaded view
|

Re: Some NS port changes

Alan Third
On Tue, Jan 15, 2019 at 09:35:49PM +0100, Charles A. Roelli wrote:

> > Date: Sun, 13 Jan 2019 23:19:50 +0000
> > From: Alan Third <[hidden email]>
> >
> > I’ve had some time to work on fixing some stuff in the NS port this
> > weekend. I’ve uploaded the changes to scratch/ns/next. It’s based on
> > master.
>
> Thanks!  It builds and runs fine on 10.6.  In all cases where I could
> reliably trigger a flicker with master, there is no more flickering
> with this branch.

That’s great news! Thanks for testing, Charles.
--
Alan Third

Reply | Threaded
Open this post in threaded view
|

Re: Some NS port changes

Zhang Haijun
In reply to this post by Alan Third
There are still too many flickers on macOS 10.13.6.

Steps to reproduce:
1. emacs -Q
2. (setq redisplay-dont-pause nil)
3. Select text across lines with touchpad

I can see blanks and then refreshing, sometimes just a blank retangle without refreshing.


macOS: 10.13.6
Xcode version: 9.2



Reply | Threaded
Open this post in threaded view
|

Re: Some NS port changes

Alan Third
On Sun, Jan 20, 2019 at 06:11:17AM +0000, Zhang Haijun wrote:
> There are still too many flickers on macOS 10.13.6.
>
> Steps to reproduce:
> 1. emacs -Q
> 2. (setq redisplay-dont-pause nil)
> 3. Select text across lines with touchpad
>
> I can see blanks and then refreshing, sometimes just a blank retangle without refreshing.

FWIW that’s exactly what I would expect to happen with that setting
set to nil. We can’t really stop the NS toolkit trying to update the
screen, but if you pause redisplay part‐way through then it’s not
going to be able to update the areas already marked as needing
redrawn.

Once it’s tried to redraw those areas, it marks them as drawn whether
it was succesful or not, so the next time round they will be ignored.
There’s not very much I can do about that.

What’s the use‐case for setting this variable?
--
Alan Third

Reply | Threaded
Open this post in threaded view
|

Re: Some NS port changes

Zhang Haijun


> 在 2019年1月20日,下午7:09,Alan Third <[hidden email]> 写道:
>
> FWIW that’s exactly what I would expect to happen with that setting
> set to nil. We can’t really stop the NS toolkit trying to update the
> screen, but if you pause redisplay part‐way through then it’s not
> going to be able to update the areas already marked as needing
> redrawn.
>
> Once it’s tried to redraw those areas, it marks them as drawn whether
> it was succesful or not, so the next time round they will be ignored.
> There’s not very much I can do about that.
>
> What’s the use‐case for setting this variable?
> --
> Alan Third

Because of a bug for CJK: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=+23412

Can the area be marked as drawn after it be redrawn?

Reply | Threaded
Open this post in threaded view
|

Re: Some NS port changes

Eli Zaretskii
In reply to this post by Zhang Haijun
On January 20, 2019 8:11:17 AM GMT+02:00, Zhang Haijun <[hidden email]> wrote:

> There are still too many flickers on macOS 10.13.6.
>
> Steps to reproduce:
> 1. emacs -Q
> 2. (setq redisplay-dont-pause nil)
> 3. Select text across lines with touchpad
>
> I can see blanks and then refreshing, sometimes just a blank retangle
> without refreshing.
>
>
> macOS: 10.13.6
> Xcode version: 9.2

The variable redisplay-dont-pause is deprecated.  Don't use it.

Reply | Threaded
Open this post in threaded view
|

Re: Some NS port changes

Eli Zaretskii
In reply to this post by Zhang Haijun
On January 20, 2019 1:20:13 PM GMT+02:00, Zhang Haijun <[hidden email]> wrote:

>
>
> > 在 2019年1月20日,下午7:09,Alan Third <[hidden email]> 写道:
> >
> > FWIW that’s exactly what I would expect to happen with that setting
> > set to nil. We can’t really stop the NS toolkit trying to update the
> > screen, but if you pause redisplay part‐way through then it’s not
> > going to be able to update the areas already marked as needing
> > redrawn.
> >
> > Once it’s tried to redraw those areas, it marks them as drawn
> whether
> > it was succesful or not, so the next time round they will be
> ignored.
> > There’s not very much I can do about that.
> >
> > What’s the use‐case for setting this variable?
> > --
> > Alan Third
>
> Because of a bug for CJK:
> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=+23412
>
> Can the area be marked as drawn after it be redrawn?

In that bug report you talk about "shaking".  Did you mean flickering?  Because I don't think I see any shaking in the clip.

In any case, this input method is not from Emacs, right?  So I couldn't try reproducing the problem on my machine.

Reply | Threaded
Open this post in threaded view
|

Re: Some NS port changes(recent 3)

zhanghj
I sent this mail 10 hours ago. But I didn’t see it on http://lists.gnu.org/archive/html/emacs-devel/2019-01/index.html.
So I resent it with another mail provider.

At 2019-01-20 20:26:08, "Eli Zaretskii" <[hidden email]> wrote:
>
>In that bug report you talk about "shaking".  Did you mean flickering?  Because I don't think I see any shaking in the clip.
>
>In any case, this input method is not from Emacs, right? So I couldn't try reproducing the problem on my machine.

Yes, it should be flickering. The same content is cleared(at the same time, the cursor goes to the beginning of the content area) 
and then redisplayed(and the cursor comes back) during inputing.

Yes, the input method is not from emacs. It is provided by the OS.

That bug only happens on macOS. And other apps(including macVim) on the OS don’t have same problem. So it must be a bug of emacs.



 

Reply | Threaded
Open this post in threaded view
|

Re: Some NS port changes

Alan Third
In reply to this post by Alan Third
The scratch/ns/next branch turned out to not be great. It didn’t work
at all with GNUstep.

I’ve pretty much given up on the ‘expose_frame’ method and have gone
back to the idea of drawing to an offscreen buffer. When I tried this
before there were severe performance problems, but I believe I’ve
worked round them this time.

This also doesn’t work in GNUstep, but the new technique is so close
to the old, deprecated, one that it’s possible to just continue with
that under GNUstep. The problem appears to be a GNUstep bug.

I think performance‐wise, this is on a par with the expose_frame
method we’re currently using, and it has proper scrolling, which is a
plus.

The attached file is an mbox you should be able to apply to emacs-26
with:

    git am offscreen-buffer.mbox

I hope. It probably won’t apply directly to master, but I haven’t
tried it.
--
Alan Third

offscreen-buffer.mbox (57K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Some NS port changes

Robert Pluim
Robert Pluim <[hidden email]> writes:

> Alan Third <[hidden email]> writes:
>
>> The scratch/ns/next branch turned out to not be great. It didn’t work
>> at all with GNUstep.
>>
>> I’ve pretty much given up on the ‘expose_frame’ method and have gone
>> back to the idea of drawing to an offscreen buffer. When I tried this
>> before there were severe performance problems, but I believe I’ve
>> worked round them this time.
>>
>> This also doesn’t work in GNUstep, but the new technique is so close
>> to the old, deprecated, one that it’s possible to just continue with
>> that under GNUstep. The problem appears to be a GNUstep bug.
>>
>> I think performance‐wise, this is on a par with the expose_frame
>> method we’re currently using, and it has proper scrolling, which is a
>> plus.
>>
>> The attached file is an mbox you should be able to apply to emacs-26
>> with:

Hi Alan,

I just tried this against emacs-26, and the resulting emacs is not
functional: the display doesnʼt update, the minibuffer doesnʼt
show. This is on Mojave (10.14.3)

Robert

Reply | Threaded
Open this post in threaded view
|

Re: Some NS port changes

Alan Third
On Mon, Feb 11, 2019 at 11:59:24AM +0100, Robert Pluim wrote:
>
> I just tried this against emacs-26, and the resulting emacs is not
> functional: the display doesnʼt update, the minibuffer doesnʼt
> show. This is on Mojave (10.14.3)

Thanks for trying it. I don’t know why I expect anything to work right
any more.

Please try the attached. I don’t think the performance is terribly
good. I was caching the graphics context as recreating it appears to
be an expensive operation, but it looks like Mojave doesn’t like that.

--
Alan Third

offscreen-buffer.mbox (58K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Some NS port changes

Robert Pluim
Alan Third <[hidden email]> writes:

> On Mon, Feb 11, 2019 at 11:59:24AM +0100, Robert Pluim wrote:
>>
>> I just tried this against emacs-26, and the resulting emacs is not
>> functional: the display doesnʼt update, the minibuffer doesnʼt
>> show. This is on Mojave (10.14.3)
>
> Thanks for trying it. I don’t know why I expect anything to work right
> any more.
>
> Please try the attached. I don’t think the performance is terribly
> good. I was caching the graphics context as recreating it appears to
> be an expensive operation, but it looks like Mojave doesn’t like that.

That works better. Iʼll keep running with it for a while.

Thanks

Robert

Reply | Threaded
Open this post in threaded view
|

Re: Some NS port changes

Robert Pluim
Robert Pluim <[hidden email]> writes:

> Alan Third <[hidden email]> writes:
>
>> On Mon, Feb 11, 2019 at 11:59:24AM +0100, Robert Pluim wrote:
>>>
>>> I just tried this against emacs-26, and the resulting emacs is not
>>> functional: the display doesnʼt update, the minibuffer doesnʼt
>>> show. This is on Mojave (10.14.3)
>>
>> Thanks for trying it. I don’t know why I expect anything to work right
>> any more.
>>
>> Please try the attached. I don’t think the performance is terribly
>> good. I was caching the graphics context as recreating it appears to
>> be an expensive operation, but it looks like Mojave doesn’t like that.
>
> That works better. Iʼll keep running with it for a while.

Youʼre right about the performance: moving point in a buffer is
glacial, as is auto-repeat.

Robert

Reply | Threaded
Open this post in threaded view
|

Re: Some NS port changes

Alan Third
On Thu, Feb 14, 2019 at 10:08:30AM +0100, Robert Pluim wrote:

> Robert Pluim <[hidden email]> writes:
>
> > Alan Third <[hidden email]> writes:
> >
> >> Please try the attached. I don’t think the performance is terribly
> >> good. I was caching the graphics context as recreating it appears to
> >> be an expensive operation, but it looks like Mojave doesn’t like that.
> >
> > That works better. Iʼll keep running with it for a while.
>
> Youʼre right about the performance: moving point in a buffer is
> glacial, as is auto-repeat.

I was talking more about scrolling a complex file in a fullscreen
window. Is it always slow or is it only in certain circumstances?
--
Alan Third

Reply | Threaded
Open this post in threaded view
|

Re: Some NS port changes

Robert Pluim
Alan Third <[hidden email]> writes:

> On Thu, Feb 14, 2019 at 10:08:30AM +0100, Robert Pluim wrote:
>> Robert Pluim <[hidden email]> writes:
>>
>> > Alan Third <[hidden email]> writes:
>> >
>> >> Please try the attached. I don’t think the performance is terribly
>> >> good. I was caching the graphics context as recreating it appears to
>> >> be an expensive operation, but it looks like Mojave doesn’t like that.
>> >
>> > That works better. Iʼll keep running with it for a while.
>>
>> Youʼre right about the performance: moving point in a buffer is
>> glacial, as is auto-repeat.
>
> I was talking more about scrolling a complex file in a fullscreen
> window. Is it always slow or is it only in certain circumstances?

Scrolling my main org file (which is displayed using a mix of
fixed-width and variable-width faces) with 'scroll-up-command' is
noticeably slower with your patch compared to stock emacs-26

Itʼs always slower, as far as I can tell, almost to the point of
unusability for me.

Robert