Re: Future of Cocoa

[Saagar Jha via Cocoa-dev]

Now that I think about it, you can probably do this without support from the 
runtime by interposing the handful of runtime functions that invalidate the 
method cache…

Saagar Jha

> On Dec 16, 2019, at 00:23, Jean-Daniel  wrote:
> 
> My bad, I just see that when rereading the description. Of course, it will 
> requires an updated runtime.
> 
>> Le 16 déc. 2019 à 09:21, Saagar Jha > > a écrit :
>> 
>> There’s also a check for method swizzling and other invalidation, assuming 
>> that there is cooperation from the runtime. Unless I’m misunderstanding what 
>> you mean by the selector changing?
>> 
>> Saagar Jha
>> 
>>> On Dec 16, 2019, at 00:16, Jean-Daniel >> > wrote:
>>> 
>>> 
 Le 16 déc. 2019 à 06:05, Saagar Jha >>> > a écrit :
 
 It’s been a while, but I just thought you both might be interested in some 
 follow-up I did for this idea. I implemented it for fun in clang 
  and it turns out that it’s a 
 pretty decent performance win 
  over 
 objc_msgSend, both because it dispatches faster and because the compiler 
 can do a full inline through it.
>>> 
>>> Yes, but you don't preserve the objc_msgSend semantic.
>>> 
>>> If I understand you code correctly, all you do is checking if it is the 
>>> same ISA, which does not guarantee in anyway that the selector did not 
>>> change since the previous call.  
>>> 
>>> As classes are fully dynamic and methods can be swizzle, you must perform a 
>>> full IMP lookup for every calls, which complexly defeat the purpose of 
>>> inline caching.
>>> 
>> 
> 

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Catalina scroll view issues

[Gary L. Wade via Cocoa-dev]

If you’re not involving a higher level class like NSTextView or a medium level 
one like CoreText, it sounds like you might be going all the way down to 
CoreGraphics? If so, you might find your disparity between your system and your 
users in things like retina choice for a particular display and changes with 
respect to layers, especially things like the copiesOnScroll. If these don’t 
lead you to a solution where you say, “Oh, I really should’ve done this rather 
than that,” (20/20 hindsight) then write up a feedback report and add its URL 
here.
--
Gary L. Wade
http://www.garywade.com/

> On Dec 16, 2019, at 1:03 AM, Redler Eyal via Cocoa-dev 
>  wrote:
> 
> Thanks!
> I don't use CoreText or NSTextView. I pretty much ruled out RTL vs LTR issues 
> since this is showing up in documents containing either and both. I'm also 
> unable to imagine how some text drawing code could produce such artifacts as 
> splitting a subview in the middle.
> (http://eyalredler.com/stuff/catalina_glitch.png)
> 
> Eyal
> 
> 
> 
> 
>> On 14 Dec 2019, at 21:20, Gary L. Wade  wrote:
>> 
>> I see from your personal web site you know Hebrew. Is it possible the 
>> affected/non-drawing pages contain some RTL text while those that don’t only 
>> contain LTR? I have seen some bugs with RTL text within NSTextView where the 
>> text was/wasn’t drawing in a similar manner. Do you operate at a CoreText 
>> level?
>> --
>> Gary L. Wade
>> http://www.garywade.com/
>> 
 On Dec 14, 2019, at 6:17 AM, Redler Eyal via Cocoa-dev 
  wrote:
>>> 
>>> Hi All,
>>> 
>>> I'm getting reports from users complaining about a strange display issue on 
>>> Catalina with my app.
>>> My app is a word-processor (not based on the cocoa text system) whose main 
>>> display shows the pages of the document. Every page is a separate view and 
>>> all the pages are subviews of one big view which resides inside a scroll 
>>> view.
>>> 
>>> The problem is that when with some documents, sometimes, when the user 
>>> scrolls down the document, some pages are not drawn or even partially 
>>> drawn. When the user clicks the place where the page is supposed to appear, 
>>> it shows up.
>>> Another interesting bit is seems that while the scroll view background is 
>>> drawn, the document views (the view containing the page views) drawRect is 
>>> not called or at least not taking effect, I can tell because the pages on 
>>> this view cast a shadow which is drawn by drawing blank squares on the 
>>> document view with a transparency layer.
>>> Last bit of info, copiesOnScroll set to NO for this view and I see that 
>>> this property is deprecated on Catalina.
>>> 
>>> So far I'm struggling with this for a couple of weeks, I wasn't able to 
>>> reproduce this at all on my machine.
>>> I'm really desperate for an answer and while I'm not expecting anyone here 
>>> to provide me with one (wouldn't object, of course :-)) I would love if 
>>> people reading this might try to speculate to the causes of this or perhaps 
>>> if you have any direction as to what to test on my users machines in order 
>>> to be able to reproduce this.
>>> 
>>> Thanks
>>> 
>>> Eyal Redler
>>> 
>>> "If Uri Geller bends spoons with divine powers, then he's doing it the hard 
>>> way."
>>> --James Randi
>>> www.eyalredler.com
>> 

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Catalina scroll view issues

[Redler Eyal via Cocoa-dev]

Thanks Rob, Makes sense although the issue is not consistent on Catalina (I 
think this is something only a minority of my app users on Catalina are 
experiencing - and I wasn't able to reproduce it). I saw this deprecation but 
could not be sure if it means that it is always on or always off. I guess 
always on makes more sense. I tried turning copiesOnScroll to on and sent a 
build to my users so we'll see if it is related - I really dislike solving 
issues I cannot confirm fixed myself.

Eyal


> On 14 Dec 2019, at 22:08, Rob Petrovec  wrote:
> 
> From 
> https://developer.apple.com/documentation/appkit/nsclipview/1532142-copiesonscroll?language=objc
> copiesOnScroll
> A Boolean value that indicates if the clip view copies rendered images while 
> scrolling.
> Discussion
> When the value of this property is YES, the clip view copies its existing 
> rendered image while scrolling (only drawing exposed portions of its document 
> view); when it is NO, the view forces its contents to be redrawn each time.
> 
> From NSClipView.h:
>   @property BOOL copiesOnScroll API_DEPRECATED("NSClipView will always 
> minimize the area of the document view that is invalidated.  To force 
> invalidation of the document view, use -[NSView setNeedsDisplayInRect:].", 
> macos(10.0, API_TO_BE_DEPRECATED));
> 
> The way I read that is that the clip view now always behaves as if 
> copyOnScroll is YES.  So even though you have it set to NO, the scroll/clip 
> view will behave as if it was true.  That may be your problem here and 
> explain the difference in behavior for you between Mojave and Cataline.  Good 
> luck.
> 
> —Rob
> 
> 
> 
>> On Dec 14, 2019, at 12:20 PM, Gary L. Wade via Cocoa-dev 
>>  wrote:
>> 
>> I see from your personal web site you know Hebrew. Is it possible the 
>> affected/non-drawing pages contain some RTL text while those that don’t only 
>> contain LTR? I have seen some bugs with RTL text within NSTextView where the 
>> text was/wasn’t drawing in a similar manner. Do you operate at a CoreText 
>> level?
>> --
>> Gary L. Wade
>> http://www.garywade.com/
>> 
>>> On Dec 14, 2019, at 6:17 AM, Redler Eyal via Cocoa-dev 
>>>  wrote:
>>> 
>>> Hi All,
>>> 
>>> I'm getting reports from users complaining about a strange display issue on 
>>> Catalina with my app.
>>> My app is a word-processor (not based on the cocoa text system) whose main 
>>> display shows the pages of the document. Every page is a separate view and 
>>> all the pages are subviews of one big view which resides inside a scroll 
>>> view.
>>> 
>>> The problem is that when with some documents, sometimes, when the user 
>>> scrolls down the document, some pages are not drawn or even partially 
>>> drawn. When the user clicks the place where the page is supposed to appear, 
>>> it shows up.
>>> Another interesting bit is seems that while the scroll view background is 
>>> drawn, the document views (the view containing the page views) drawRect is 
>>> not called or at least not taking effect, I can tell because the pages on 
>>> this view cast a shadow which is drawn by drawing blank squares on the 
>>> document view with a transparency layer.
>>> Last bit of info, copiesOnScroll set to NO for this view and I see that 
>>> this property is deprecated on Catalina.
>>> 
>>> So far I'm struggling with this for a couple of weeks, I wasn't able to 
>>> reproduce this at all on my machine.
>>> I'm really desperate for an answer and while I'm not expecting anyone here 
>>> to provide me with one (wouldn't object, of course :-)) I would love if 
>>> people reading this might try to speculate to the causes of this or perhaps 
>>> if you have any direction as to what to test on my users machines in order 
>>> to be able to reproduce this.
>>> 
>>> Thanks
>>> 
>>> Eyal Redler
>>> 
>>> "If Uri Geller bends spoons with divine powers, then he's doing it the hard 
>>> way."
>>> --James Randi
>>> www.eyalredler.com
>> 
>> ___
>> 
>> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
>> 
>> Please do not post admin requests or moderator comments to the list.
>> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
>> 
>> Help/Unsubscribe/Update your Subscription:
>> https://lists.apple.com/mailman/options/cocoa-dev/petrock%40mac.com
>> 
>> This email sent to petr...@mac.com
> 

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Catalina scroll view issues

[Redler Eyal via Cocoa-dev]

Thanks!
I don't use CoreText or NSTextView. I pretty much ruled out RTL vs LTR issues 
since this is showing up in documents containing either and both. I'm also 
unable to imagine how some text drawing code could produce such artifacts as 
splitting a subview in the middle.
(http://eyalredler.com/stuff/catalina_glitch.png)

Eyal




> On 14 Dec 2019, at 21:20, Gary L. Wade  wrote:
> 
> I see from your personal web site you know Hebrew. Is it possible the 
> affected/non-drawing pages contain some RTL text while those that don’t only 
> contain LTR? I have seen some bugs with RTL text within NSTextView where the 
> text was/wasn’t drawing in a similar manner. Do you operate at a CoreText 
> level?
> --
> Gary L. Wade
> http://www.garywade.com/
> 
>> On Dec 14, 2019, at 6:17 AM, Redler Eyal via Cocoa-dev 
>>  wrote:
>> 
>> Hi All,
>> 
>> I'm getting reports from users complaining about a strange display issue on 
>> Catalina with my app.
>> My app is a word-processor (not based on the cocoa text system) whose main 
>> display shows the pages of the document. Every page is a separate view and 
>> all the pages are subviews of one big view which resides inside a scroll 
>> view.
>> 
>> The problem is that when with some documents, sometimes, when the user 
>> scrolls down the document, some pages are not drawn or even partially drawn. 
>> When the user clicks the place where the page is supposed to appear, it 
>> shows up.
>> Another interesting bit is seems that while the scroll view background is 
>> drawn, the document views (the view containing the page views) drawRect is 
>> not called or at least not taking effect, I can tell because the pages on 
>> this view cast a shadow which is drawn by drawing blank squares on the 
>> document view with a transparency layer.
>> Last bit of info, copiesOnScroll set to NO for this view and I see that this 
>> property is deprecated on Catalina.
>> 
>> So far I'm struggling with this for a couple of weeks, I wasn't able to 
>> reproduce this at all on my machine.
>> I'm really desperate for an answer and while I'm not expecting anyone here 
>> to provide me with one (wouldn't object, of course :-)) I would love if 
>> people reading this might try to speculate to the causes of this or perhaps 
>> if you have any direction as to what to test on my users machines in order 
>> to be able to reproduce this.
>> 
>> Thanks
>> 
>> Eyal Redler
>> 
>> "If Uri Geller bends spoons with divine powers, then he's doing it the hard 
>> way."
>> --James Randi
>> www.eyalredler.com
> 

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Future of Cocoa

[Jean-Daniel via Cocoa-dev]

My bad, I just see that when rereading the description. Of course, it will 
requires an updated runtime.

> Le 16 déc. 2019 à 09:21, Saagar Jha  a écrit :
> 
> There’s also a check for method swizzling and other invalidation, assuming 
> that there is cooperation from the runtime. Unless I’m misunderstanding what 
> you mean by the selector changing?
> 
> Saagar Jha
> 
>> On Dec 16, 2019, at 00:16, Jean-Daniel > > wrote:
>> 
>> 
>>> Le 16 déc. 2019 à 06:05, Saagar Jha >> > a écrit :
>>> 
>>> It’s been a while, but I just thought you both might be interested in some 
>>> follow-up I did for this idea. I implemented it for fun in clang 
>>>  and it turns out that it’s a 
>>> pretty decent performance win 
>>>  over 
>>> objc_msgSend, both because it dispatches faster and because the compiler 
>>> can do a full inline through it.
>> 
>> Yes, but you don't preserve the objc_msgSend semantic.
>> 
>> If I understand you code correctly, all you do is checking if it is the same 
>> ISA, which does not guarantee in anyway that the selector did not change 
>> since the previous call.   
>> 
>> As classes are fully dynamic and methods can be swizzle, you must perform a 
>> full IMP lookup for every calls, which complexly defeat the purpose of 
>> inline caching.
>> 
> 

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Future of Cocoa

[Saagar Jha via Cocoa-dev]

There’s also a check for method swizzling and other invalidation, assuming that 
there is cooperation from the runtime. Unless I’m misunderstanding what you 
mean by the selector changing?

Saagar Jha

> On Dec 16, 2019, at 00:16, Jean-Daniel  wrote:
> 
> 
>> Le 16 déc. 2019 à 06:05, Saagar Jha > > a écrit :
>> 
>> It’s been a while, but I just thought you both might be interested in some 
>> follow-up I did for this idea. I implemented it for fun in clang 
>>  and it turns out that it’s a 
>> pretty decent performance win 
>>  over 
>> objc_msgSend, both because it dispatches faster and because the compiler can 
>> do a full inline through it.
> 
> Yes, but you don't preserve the objc_msgSend semantic.
> 
> If I understand you code correctly, all you do is checking if it is the same 
> ISA, which does not guarantee in anyway that the selector did not change 
> since the previous call.
> 
> As classes are fully dynamic and methods can be swizzle, you must perform a 
> full IMP lookup for every calls, which complexly defeat the purpose of inline 
> caching.
> 

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Future of Cocoa

[Jean-Daniel via Cocoa-dev]

> Le 16 déc. 2019 à 06:05, Saagar Jha  a écrit :
> 
> It’s been a while, but I just thought you both might be interested in some 
> follow-up I did for this idea. I implemented it for fun in clang 
>  and it turns out that it’s a 
> pretty decent performance win 
>  over 
> objc_msgSend, both because it dispatches faster and because the compiler can 
> do a full inline through it.

Yes, but you don't preserve the objc_msgSend semantic.

If I understand you code correctly, all you do is checking if it is the same 
ISA, which does not guarantee in anyway that the selector did not change since 
the previous call.  

As classes are fully dynamic and methods can be swizzle, you must perform a 
full IMP lookup for every calls, which complexly defeat the purpose of inline 
caching.

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com