Re: Catalina scroll view issues

[Redler Eyal via Cocoa-dev]

Thanks for your comments.

> My first instinct when someone says "not reproducible for me with a scroll 
> view" on Mac is: Maybe it only occurs with overlay scrollers, or only with 
> separate scrollers? Have you tried toggling that setting?

If you mean the "show scroll bars" setting in System Preferences/General then 
yes, I did try all settings without success (in reproducing). I also know that 
this setting is not all set the same way for all of the complaining users.

> Also, are you calling setNeedsDisplay: or setNeedsDisplayInRect: anywhere? 
> That's usually how you cause redraws.

I'm calling it where appropriate (afaik) to redraw the display when the text 
changes or when the selection changes, among other things.

> 
> If this is only while scrolling, are you perhaps doing things in drawRect: 
> that you shouldn't? drawRect: should only draw when the OS calls it. Calling 
> drawRect: directly is not supported. Changing state inside drawRect: or 
> calling setNeedsDisplay: or moving or resizing views or windows is not 
> supported in drawRect:. These things often work by accident though, so I've 
> seem lots of code naïvely doing it.

I'm not doing that. Also, this code is years old and worked correctly for many 
many users on other systems. I'm supporting (and have users on) all versions of 
macOS down to 10.7 and I only get complaints from (some) users on Catalina. 
Of-course, this doesn't mean that the code doesn't have issues since I've 
already learned the hard way that some things that were forgiven in the past 
are no longer tolerated on Catalina (for example, adding more then 256 cursor 
rects to a view) so it could be that somewhere, somehow I am doing something 
illegitimate but it is showing only now on Catalina. So, to check this theory I 
made a special build of the app that allowed turning off drawing of the page 
views or of the page container view. Based on a user defaults setting the app 
would simply do nothing in drawRect for the page page view or for the container 
view. My users tried both of these settings and in both cases the problem 
persisted. So, even with drawRect doing nothing, the problem still shows up.

> Similarly, NSView etc. only work when used from the main thread, if you are 
> calling methods on views from a secondary thread (like a Dispatch Queue, or a 
> callback that isn't guaranteed to be on the main thread), it might work by 
> accident, but it is unsupported and unsafe.

I am aware of this. The only thing that could be even remotely related is that 
there's a timer that blinks the cursor (triggering an update view 
setNeedsDisplay, this code predates dispatch queue by many years and afaik, it 
is called on the main thread.
I'm doing most of the work on the main thread anyway but I will review my very 
little (unrelated to drawing as far as I can recall) code, maybe somehow...

> Finally, are you maybe forgetting to apply layout constraints to any of your 
> views, or forgot to set its translatesAutoresizingMaskIntoConstraints 
> properly somewhere? That could cause a view to have the wrong size and clip.

I'm not using auto-layout in this view (I supported 10.6 until recently so this 
wasn't available for me). I'm trying to think how this could be related - 
perhaps auto-layout is trying to work its magic ignoring the fact that is is 
not turned on officially for that view/window but I'm not really seeing it. 
Timing-wise, the artifacts are not related to the views being moved, the views 
can be moved when resizing the window or when changing the document zoom level 
and the container view size can change when adding/removing pages or changing 
the zoom level but the artifacts show up when scrolling and only then. 
Scrolling also is what usually fixes the artifact, when the user continues to 
scroll then subsequent pages will appear and then when he scrolls back to the 
trouble area the page will be there.
It does look related to clipping, the page view can be cut in the middle and 
the drawing of the shadow (done on the container view) is also cut at the same 
place.

Eyal

___

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

[Uli Kusterer via Cocoa-dev]

My first instinct when someone says "not reproducible for me with a scroll 
view" on Mac is: Maybe it only occurs with overlay scrollers, or only with 
separate scrollers? Have you tried toggling that setting?

Also, are you calling setNeedsDisplay: or setNeedsDisplayInRect: anywhere? 
That's usually how you cause redraws.

If this is only while scrolling, are you perhaps doing things in drawRect: that 
you shouldn't? drawRect: should only draw when the OS calls it. Calling 
drawRect: directly is not supported. Changing state inside drawRect: or calling 
setNeedsDisplay: or moving or resizing views or windows is not supported in 
drawRect:. These things often work by accident though, so I've seem lots of 
code naïvely doing it.

Similarly, NSView etc. only work when used from the main thread, if you are 
calling methods on views from a secondary thread (like a Dispatch Queue, or a 
callback that isn't guaranteed to be on the main thread), it might work by 
accident, but it is unsupported and unsafe.

Finally, are you maybe forgetting to apply layout constraints to any of your 
views, or forgot to set its translatesAutoresizingMaskIntoConstraints properly 
somewhere? That could cause a view to have the wrong size and clip.

Cheers,
-- Uli Kusterer
"The Witnesses of TeachText are everywhere..."
http://www.zathras.de

> On 14. Dec 2019, at 15:16, 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/witness.of.teachtext%40gmx.net
> 
> This email sent to witness.of.teacht...@gmx.net

___

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

[Allan Odgaard via Cocoa-dev]

On 1 Jan 2020, at 2:46, Rob Petrovec via Cocoa-dev wrote:

drawRect is not deprecated. Correct. However, it is technically old 
fashioned. It is much more efficient to use layers.  Layers can take 
better advantage of the video card especially during animations, and 
don’t require unnecessary redraws if (part of) your view is covered 
up and then uncovered (e.g. during scrolling or windows moving around 
etc).


In itself it is not “much more efficient to use layers”.

Only if you change layer properties for animation effects do you save on 
redraws, but it comes at the cost of extra memory consumption.


As for redrawing windows, these are already drawn into off-screen 
buffers and clip views maintain some overdraw rectangles to make 
scrolling smoother. So you normally don’t reduce redraws by using 
layers.


Also, the layer equivalent of a scroll view is CATiledLayer, this has 
different behavior in that it redraws tiles in a background thread and 
then uses transitions to make them appear. But it also uses transitions 
when you change properties which I found problematic, for example 
resizing the document view because of changed content would re-use 
existing tile and just scale it, before transitioning to the new tile 
(being drawn in a background thread).


For some types of applications, this behavior is fine, but probably not 
for a text editor like OP is writing, and at least I was unable to find 
a way to just do atomic updates without the transition stuff (I did try 
CATransaction).

___

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]

>> I, for one, wasn't able to reproduce it on the 5 machines I was able to put 
>> my hands on.
> 
> Although I have not seen a *reproducible* case either, I have seen that it is 
> much more likely to occur in text views with hundreds of lines or rows, so 
> you should try such in your tests.

My app is a word-processor so that is basically all it does. I tried it with 
documents of varying lengths from 2 pages to 700 pages and was never able to 
see the issue. Since at one point I thought the issue was specific to certain 
documents I asked my clients to send me these specific documents but I couldn't 
reproduce it with these documents either. On the other hand, a simple document 
I created on my machine and set to the users to test was also showing the 
issues on their machines so I could pretty much rule out that this is a 
document specific issue.

> Also, it is possible that I have not seen it at all since I replaced my 2013 
> MacBook Air with a new MacBook Air about a month ago.  Another possible 
> factor is that this Mac is enrolled in the Apple Beta Software program, so 
> maybe Apple gave us a Christmas present and silently fixed in 10.15.3 as one 
> of their unspecified bug fixes.

Perhaps it is fixed on 15.3, I'm unable to check it myself (since I never see 
the issue) and I dare not ask of my users to submit themselves to installing a 
beta. BTW, could you share a screenshot of the issue as you saw it?

Eyal


> ___
> 
> 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/eyal%40mellel.com
> 
> This email sent to e...@mellel.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]

> turning it on did not cause the issue to show up on Mohave
>> ...
>> I, for one, wasn't able to reproduce it on the 5 machines I was able to put 
>> my hands on.
>   Curious, how were you able to verify that turning on copyOnScroll in 
> your app and running it on Mojave did not reproduce the problem if you 
> couldn’t reproduce the problem on Catalina on the machines you had access to? 
>  Just curious.

I created a special build of the app with copyOnScroll turned back on and then 
tested it on my machine running Mohave (works just as well) and Catalina (again 
- no issues). I then sent it to a group of my clients who were experiencing the 
issue on Catalina, they reported back to me that the issue is still there.

I also did a similar test with turning responsive scrolling off, same results. 
I also tried a build where you can turn off drawing the document view 
background and/or drawing of the pages themselves and the issue was still there.

Eyal


> —Rob
> 
> 
>> On Dec 31, 2019, at 1:34 AM, Eyal Redler  wrote:
>> 
>>> 
>>> On 30 Dec 2019, at 2:09, Rob Petrovec via Cocoa-dev 
>>> mailto:cocoa-dev@lists.apple.com>> wrote:
>>> 
>>> I honestly think this is fall out from copiesOnScroll being deprecated and 
>>> the clip view always behaving as if it was set to true.  My guess is you 
>>> will see the same problems in your apps if you ran them on Mojave with 
>>> copiesOnScroll set to true.  In which case you need to update your app to 
>>> work with copiesOnScroll set to true.  E.g. use layers instead of drawRect.
>> 
>> I agree that this is probably connected to the changes that led to 
>> copiesOnScroll to be deprecated but turning it on did not cause the issue to 
>> show up on Mohave nor did it fix the issue on Catalina. AFAIK drawRect is 
>> not deprecated (yet?) and so my drawing the views, on a mac, using drawRect 
>> is compatible Apple's current guidelines. Nothing old fashioned or 
>> unorthodox in what I'm doing.
>> 
>> My understanding (and hopefully those in the know will correct me if I'm 
>> wrong), with responsive scrolling, copiesOnScroll is not relevant, drawRect 
>> is not called to paint the newly exposed area as you scroll but rather is 
>> called ahead of time for the visible area plus some extra content above and 
>> below. When the user scrolls, the system just copies the bits to the screen 
>> from some offscreen buffer. I believe that since responsive scrolling was 
>> introduced, copiesOnScroll was ignored anyway and was relevant only when 
>> responsive scrolling was turned off.
>> 
>> Last thing to point out, the problem is exclusive to Catalina but it doesn't 
>> effect all users, I don't have any statistics but gathering from the 
>> relatively few reports I've received, it seems to effect only a minority of 
>> users (thank God, this bug really makes me look really bad and I'm 
>> completely helpless against it). I, for one, wasn't able to reproduce it on 
>> the 5 machines I was able to put my hands on.
>> 
>> Eyal
>> 
>> 
>> 
>>> 
>>> —Rob
>>> 
>>> 
 On Dec 29, 2019, at 4:08 PM, Jerome Krinock via Cocoa-dev 
  wrote:
 
 Since installing macOS 10.15, I see blocks of empty text view lines or 
 table view rows often when scrolling through many apps, including file 
 browser windows in Path Finder (cocoatech.com) and, for heaven’s sake, 
 even in BBEdit.
 
 Conclusion: This is not “our” faults.  Thank you, Eyal for submitting this 
 issue to Apple as FB7509033.  Maybe someday… [rant omitted].
 ___
 
 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/eyal%40mellel.com 
>>> 
>>> 
>>> This email sent to e...@mellel.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/eyal%40mellel.com
> 
> This email sent to e...@mellel.com

___

Cocoa-dev mailing list 

Re: Catalina scroll view issues

[Jerome Krinock via Cocoa-dev]

On 2019 Dec 31, at 00:34, Eyal Redler  wrote:

> I, for one, wasn't able to reproduce it on the 5 machines I was able to put 
> my hands on.

Although I have not seen a *reproducible* case either, I have seen that it is 
much more likely to occur in text views with hundreds of lines or rows, so you 
should try such in your tests.

Also, it is possible that I have not seen it at all since I replaced my 2013 
MacBook Air with a new MacBook Air about a month ago.  Another possible factor 
is that this Mac is enrolled in the Apple Beta Software program, so maybe Apple 
gave us a Christmas present and silently fixed in 10.15.3 as one of their 
unspecified bug fixes.
___

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

[Rob Petrovec via Cocoa-dev]

> On Dec 31, 2019, at 1:34 AM, Eyal Redler  wrote:

> Nothing old fashioned or unorthodox in what I'm doing.
drawRect is not deprecated. Correct. However, it is technically old 
fashioned. It is much more efficient to use layers.  Layers can take better 
advantage of the video card especially during animations, and don’t require 
unnecessary redraws if (part of) your view is covered up and then uncovered 
(e.g. during scrolling or windows moving around etc).


> turning it on did not cause the issue to show up on Mohave
> ...
>  I, for one, wasn't able to reproduce it on the 5 machines I was able to put 
> my hands on.
Curious, how were you able to verify that turning on copyOnScroll in 
your app and running it on Mojave did not reproduce the problem if you couldn’t 
reproduce the problem on Catalina on the machines you had access to?  Just 
curious.

—Rob


> On Dec 31, 2019, at 1:34 AM, Eyal Redler  wrote:
> 
>> 
>> On 30 Dec 2019, at 2:09, Rob Petrovec via Cocoa-dev 
>> mailto:cocoa-dev@lists.apple.com>> wrote:
>> 
>> I honestly think this is fall out from copiesOnScroll being deprecated and 
>> the clip view always behaving as if it was set to true.  My guess is you 
>> will see the same problems in your apps if you ran them on Mojave with 
>> copiesOnScroll set to true.  In which case you need to update your app to 
>> work with copiesOnScroll set to true.  E.g. use layers instead of drawRect.
> 
> I agree that this is probably connected to the changes that led to 
> copiesOnScroll to be deprecated but turning it on did not cause the issue to 
> show up on Mohave nor did it fix the issue on Catalina. AFAIK drawRect is not 
> deprecated (yet?) and so my drawing the views, on a mac, using drawRect is 
> compatible Apple's current guidelines. Nothing old fashioned or unorthodox in 
> what I'm doing.
> 
> My understanding (and hopefully those in the know will correct me if I'm 
> wrong), with responsive scrolling, copiesOnScroll is not relevant, drawRect 
> is not called to paint the newly exposed area as you scroll but rather is 
> called ahead of time for the visible area plus some extra content above and 
> below. When the user scrolls, the system just copies the bits to the screen 
> from some offscreen buffer. I believe that since responsive scrolling was 
> introduced, copiesOnScroll was ignored anyway and was relevant only when 
> responsive scrolling was turned off.
> 
> Last thing to point out, the problem is exclusive to Catalina but it doesn't 
> effect all users, I don't have any statistics but gathering from the 
> relatively few reports I've received, it seems to effect only a minority of 
> users (thank God, this bug really makes me look really bad and I'm completely 
> helpless against it). I, for one, wasn't able to reproduce it on the 5 
> machines I was able to put my hands on.
> 
> Eyal
> 
> 
> 
>> 
>> —Rob
>> 
>> 
>>> On Dec 29, 2019, at 4:08 PM, Jerome Krinock via Cocoa-dev 
>>>  wrote:
>>> 
>>> Since installing macOS 10.15, I see blocks of empty text view lines or 
>>> table view rows often when scrolling through many apps, including file 
>>> browser windows in Path Finder (cocoatech.com) and, for heaven’s sake, even 
>>> in BBEdit.
>>> 
>>> Conclusion: This is not “our” faults.  Thank you, Eyal for submitting this 
>>> issue to Apple as FB7509033.  Maybe someday… [rant omitted].
>>> ___
>>> 
>>> 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/eyal%40mellel.com 
>> 
>> 
>> This email sent to e...@mellel.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

[Rob Petrovec via Cocoa-dev]

I honestly think this is fall out from copiesOnScroll being deprecated and the 
clip view always behaving as if it was set to true.  My guess is you will see 
the same problems in your apps if you ran them on Mojave with copiesOnScroll 
set to true.  In which case you need to update your app to work with 
copiesOnScroll set to true.  E.g. use layers instead of drawRect.

—Rob


> On Dec 29, 2019, at 4:08 PM, Jerome Krinock via Cocoa-dev 
>  wrote:
> 
> Since installing macOS 10.15, I see blocks of empty text view lines or table 
> view rows often when scrolling through many apps, including file browser 
> windows in Path Finder (cocoatech.com) and, for heaven’s sake, even in BBEdit.
> 
> Conclusion: This is not “our” faults.  Thank you, Eyal for submitting this 
> issue to Apple as FB7509033.  Maybe someday… [rant omitted].
> ___
> 
> 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

[Jerome Krinock via Cocoa-dev]

Since installing macOS 10.15, I see blocks of empty text view lines or table 
view rows often when scrolling through many apps, including file browser 
windows in Path Finder (cocoatech.com) and, for heaven’s sake, even in BBEdit.

Conclusion: This is not “our” faults.  Thank you, Eyal for submitting this 
issue to Apple as FB7509033.  Maybe someday… [rant omitted].
___

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

[Allan Odgaard via Cocoa-dev]

On 27 Dec 2019, at 13:03, Allan Odgaard via Cocoa-dev wrote:

> I do change copiesOnScroll.

Sorry, I meant that I do *not* change copiesOnScroll.
___

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

[Allan Odgaard via Cocoa-dev]

On 16 Dec 2019, at 16:35, Eyal Redler wrote:

It does look very similar (except for the fact that in your example 
the text is also cut on the right. Do you have copiesOnScroll turned 
off as well?


I do change copiesOnScroll.

Apart from opting out of responsive scrolling, it’s should be a very 
standard NSClipView/NSScrollView setup.


Interesting to note that both scroll views (main text and line 
numbers) are cut-off at the same point.


To me it looks to be about “window compositing” rather than the 
affected view.


In the screen capture I received, the text that did get drawn is exactly 
640 pixels wide but spans two views. Possibly that is the texture size 
Apple uses when doing window compositing?


But difficult to speculate about what is causing this given window/view 
compositing is a black box.


My view doesn't opt out of responsive scrolling so in my case that is 
ruled out. Did you find out anything about this issue in your case? 
How prevalent was that?


Heard it from numerous users, and some users apparently see it a lot.

But one user mentioned having seen something similar in Outlook.

So my money are on this being a macOS 10.15 bug.

I actually thought of opting out of responsive scrolling as a way to 
try and fix this. Did you try removing the opt out (just for testing 
purposes) to see if it is indeed related?


I did not, but I have a user defaults for this, so I will propose 
affected users test with responsive scroll enabled.


FYI I haven’t seen the issue myself as I have refrained from upgrading 
to macOS 10.15.

___

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]

I submitted the issue via feedback reporter. Case number: FB7509033

Eyal


> On 19 Dec 2019, at 17:10, Gary L. Wade  wrote:
> 
> Interesting.  This could be a layering issue then, and it could be due to a 
> configuration unique to your customer’s setup.  Since you’re doing things on 
> a lower level than expected, there may be some nuance you need to add or 
> something Apple needs to fix that may work fine using higher level 
> frameworks.  Since there’s lots of little things going on, it definitely 
> warrants a feedback report.  Please add its number to your reply when you 
> submit it.
> 
> FYI, Apple has been putting a lot of effort to support RTL better; in one of 
> this year’s early general presentations at WWDC, you might have seen an 
> engineer talking about RTL support within the App Store on all devices (well, 
> maybe not the HomePod, of course), and the labs definitely had staff there to 
> help.  Where you may find your implementation better than what you see in the 
> frameworks, please write as many feedback reports as needed so all developers 
> can benefit from the desired changes.
> --
> Gary L. Wade
> http://www.garywade.com/
> 
>> On Dec 19, 2019, at 6:09 AM, Redler Eyal  wrote:
>> 
 
 OK, I'll try to get the sysdiagnose from my users before submitting. I 
 must say I'm really skeptic regarding the relation with my use of CG. It 
 is not that CG is not used by CT and everything else is also using CG.
>>> 
>>> CG may not be the issue… and I cannot offer a better suggestion, but when I 
>>> rule out a possibility without proof, it usually turns out that I over look 
>>> the solution to the problem.  Good luck!
>> 
>> You're right, and I wasn't ruling it out. I actually sent my user a special 
>> build with an defaults option to turn off page drawing (so the page views 
>> are not doing any drawing CG or otherwise), the issue persists.
>> 
>> I also tried to see this issue while doing remote access using anyDesk, for 
>> some reason, the issue never showed up, when I disconnected, it showed up 
>> again.
>> 
>> Eyal
>> 
>> 
>> 
>>> Sandor
>>> 
 The way it looks it seems very much related to the scrolling mechanism, 
 the pre-rendered portion is not rendered but for some reason the scrolling 
 mechanism thinks that it is. I really don't see how a core-graphic issue, 
 and certainly not a misuse on my part could cause a view to be partially 
 rendered.
 BTW, do you think this type of issue is appropriate for a DTS incident?
 
> Here’s the developer release notes for Catalina:
> https://developer.apple.com/documentation/macos_release_notes/macos_catalina_10_15_release_notes
 
 Thanks. I saw that but I recall that in the past you used to have app-kit 
 specific release notes which were usually more detailed. 
 
> As an aside, it would be helpful to know why you chose CG for text 
> rendering. CT has gotten better with RTL and bidi text, but if you saw 
> particular issues there, reports about those can help everyone.
 
 When I started developing this app (2002), there was no choice other then 
 CG since core text didn't exist and the other technologies didn't support 
 Hebrew and RTL well, if at all. So I wrote my own text engine and this was 
 very good for me commercially as my app was the the first and only 
 word-processor to support Hebrew (and later Arabic) properly on Max OS X. 
 I had a similar experience with OpenType which was not initially supported 
 and that also gave me an edge. As time passed Apple did improve the RTL 
 support and was offering more APIs so theoretically I could have rewritten 
 my code to use the new APIs but in reality I actually did the opposite and 
 relied less on Apple's APIs (for example, parsing 'cmap' tables) because 
 there were always bugs and even regressions which could render my app 
 unusable upon an OS upgrade. Beyond the bugs, I think my RTL is better, or 
 at least as far as I'm concerned as a native Hebrew speaker and having 
 such low-level control over something that is core to my app is essential 
 IMO.
 
 Eyal Redler
 
 "If Uri Geller bends spoons with divine powers, then he's doing it the 
 hard way."
 --James Randi
 www.eyalredler.com
 
 
 
 
 
 
> Gary L. Wade
> http://www.garywade.com/
> 
>>> On Dec 17, 2019, at 2:12 AM, Redler Eyal  wrote:
>> 
>> I am drawing using core graphics. I tried turning copiesOnScroll and 
>> this didn't seem to help.
>> 
>> I'll gladly write a feedback report but I'm not able to reproduce this 
>> so I can't give an xcode project that will reproduce this... Isn't that 
>> a requirement?
>> 
>> BTW, perhaps you know: Are there no release notes for app kit with 

Re: Catalina scroll view issues

[Georg Seifert via Cocoa-dev]

I read most of the discussion but maybe missed some parts so it might repeat 
something or miss the point altogether. 

How big is your view. I had a lot problems with a big view and layer backing. 
It will use tiled layers as a layer can only be a few thousand pixels tall. 
And when you do any checking for the dirty rect you will miss drawing in some 
of the tiles...

Georg


> Am 19.12.2019 um 16:10 schrieb Gary L. Wade via Cocoa-dev 
> :
> 
> Interesting.  This could be a layering issue then, and it could be due to a 
> configuration unique to your customer’s setup.  Since you’re doing things on 
> a lower level than expected, there may be some nuance you need to add or 
> something Apple needs to fix that may work fine using higher level 
> frameworks.  Since there’s lots of little things going on, it definitely 
> warrants a feedback report.  Please add its number to your reply when you 
> submit it.
> 
> FYI, Apple has been putting a lot of effort to support RTL better; in one of 
> this year’s early general presentations at WWDC, you might have seen an 
> engineer talking about RTL support within the App Store on all devices (well, 
> maybe not the HomePod, of course), and the labs definitely had staff there to 
> help.  Where you may find your implementation better than what you see in the 
> frameworks, please write as many feedback reports as needed so all developers 
> can benefit from the desired changes.
> --
> Gary L. Wade
> http://www.garywade.com/ 
> 
>> On Dec 19, 2019, at 6:09 AM, Redler Eyal  wrote:
>> 
 
 OK, I'll try to get the sysdiagnose from my users before submitting. I 
 must say I'm really skeptic regarding the relation with my use of CG. It 
 is not that CG is not used by CT and everything else is also using CG.
>>> 
>>> CG may not be the issue… and I cannot offer a better suggestion, but when I 
>>> rule out a possibility without proof, it usually turns out that I over look 
>>> the solution to the problem.  Good luck!
>> 
>> You're right, and I wasn't ruling it out. I actually sent my user a special 
>> build with an defaults option to turn off page drawing (so the page views 
>> are not doing any drawing CG or otherwise), the issue persists.
>> 
>> I also tried to see this issue while doing remote access using anyDesk, for 
>> some reason, the issue never showed up, when I disconnected, it showed up 
>> again.
>> 
>> Eyal
>> 
>> 
>> 
>>> Sandor
>>> 
 The way it looks it seems very much related to the scrolling mechanism, 
 the pre-rendered portion is not rendered but for some reason the scrolling 
 mechanism thinks that it is. I really don't see how a core-graphic issue, 
 and certainly not a misuse on my part could cause a view to be partially 
 rendered.
 BTW, do you think this type of issue is appropriate for a DTS incident?
 
> Here’s the developer release notes for Catalina:
> https://developer.apple.com/documentation/macos_release_notes/macos_catalina_10_15_release_notes
 
 Thanks. I saw that but I recall that in the past you used to have app-kit 
 specific release notes which were usually more detailed. 
 
> As an aside, it would be helpful to know why you chose CG for text 
> rendering. CT has gotten better with RTL and bidi text, but if you saw 
> particular issues there, reports about those can help everyone.
 
 When I started developing this app (2002), there was no choice other then 
 CG since core text didn't exist and the other technologies didn't support 
 Hebrew and RTL well, if at all. So I wrote my own text engine and this was 
 very good for me commercially as my app was the the first and only 
 word-processor to support Hebrew (and later Arabic) properly on Max OS X. 
 I had a similar experience with OpenType which was not initially supported 
 and that also gave me an edge. As time passed Apple did improve the RTL 
 support and was offering more APIs so theoretically I could have rewritten 
 my code to use the new APIs but in reality I actually did the opposite and 
 relied less on Apple's APIs (for example, parsing 'cmap' tables) because 
 there were always bugs and even regressions which could render my app 
 unusable upon an OS upgrade. Beyond the bugs, I think my RTL is better, or 
 at least as far as I'm concerned as a native Hebrew speaker and having 
 such low-level control over something that is core to my app is essential 
 IMO.
 
 Eyal Redler
 
 "If Uri Geller bends spoons with divine powers, then he's doing it the 
 hard way."
 --James Randi
 www.eyalredler.com
 
 
 
 
 
 
> Gary L. Wade
> http://www.garywade.com/
> 
>>> On Dec 17, 2019, at 2:12 AM, Redler Eyal  wrote:
>> 
>> I am drawing using core 

Re: Catalina scroll view issues

[Gary L. Wade via Cocoa-dev]

Interesting.  This could be a layering issue then, and it could be due to a 
configuration unique to your customer’s setup.  Since you’re doing things on a 
lower level than expected, there may be some nuance you need to add or 
something Apple needs to fix that may work fine using higher level frameworks.  
Since there’s lots of little things going on, it definitely warrants a feedback 
report.  Please add its number to your reply when you submit it.

FYI, Apple has been putting a lot of effort to support RTL better; in one of 
this year’s early general presentations at WWDC, you might have seen an 
engineer talking about RTL support within the App Store on all devices (well, 
maybe not the HomePod, of course), and the labs definitely had staff there to 
help.  Where you may find your implementation better than what you see in the 
frameworks, please write as many feedback reports as needed so all developers 
can benefit from the desired changes.
--
Gary L. Wade
http://www.garywade.com/ 

> On Dec 19, 2019, at 6:09 AM, Redler Eyal  wrote:
> 
>>> 
>>> OK, I'll try to get the sysdiagnose from my users before submitting. I must 
>>> say I'm really skeptic regarding the relation with my use of CG. It is not 
>>> that CG is not used by CT and everything else is also using CG.
>> 
>> CG may not be the issue… and I cannot offer a better suggestion, but when I 
>> rule out a possibility without proof, it usually turns out that I over look 
>> the solution to the problem.  Good luck!
> 
> You're right, and I wasn't ruling it out. I actually sent my user a special 
> build with an defaults option to turn off page drawing (so the page views are 
> not doing any drawing CG or otherwise), the issue persists.
> 
> I also tried to see this issue while doing remote access using anyDesk, for 
> some reason, the issue never showed up, when I disconnected, it showed up 
> again.
> 
> Eyal
> 
> 
> 
>> Sandor
>> 
>>> The way it looks it seems very much related to the scrolling mechanism, the 
>>> pre-rendered portion is not rendered but for some reason the scrolling 
>>> mechanism thinks that it is. I really don't see how a core-graphic issue, 
>>> and certainly not a misuse on my part could cause a view to be partially 
>>> rendered.
>>> BTW, do you think this type of issue is appropriate for a DTS incident?
>>> 
 Here’s the developer release notes for Catalina:
 https://developer.apple.com/documentation/macos_release_notes/macos_catalina_10_15_release_notes
>>> 
>>> Thanks. I saw that but I recall that in the past you used to have app-kit 
>>> specific release notes which were usually more detailed. 
>>> 
 As an aside, it would be helpful to know why you chose CG for text 
 rendering. CT has gotten better with RTL and bidi text, but if you saw 
 particular issues there, reports about those can help everyone.
>>> 
>>> When I started developing this app (2002), there was no choice other then 
>>> CG since core text didn't exist and the other technologies didn't support 
>>> Hebrew and RTL well, if at all. So I wrote my own text engine and this was 
>>> very good for me commercially as my app was the the first and only 
>>> word-processor to support Hebrew (and later Arabic) properly on Max OS X. I 
>>> had a similar experience with OpenType which was not initially supported 
>>> and that also gave me an edge. As time passed Apple did improve the RTL 
>>> support and was offering more APIs so theoretically I could have rewritten 
>>> my code to use the new APIs but in reality I actually did the opposite and 
>>> relied less on Apple's APIs (for example, parsing 'cmap' tables) because 
>>> there were always bugs and even regressions which could render my app 
>>> unusable upon an OS upgrade. Beyond the bugs, I think my RTL is better, or 
>>> at least as far as I'm concerned as a native Hebrew speaker and having such 
>>> low-level control over something that is core to my app is essential IMO.
>>> 
>>> Eyal Redler
>>> 
>>> "If Uri Geller bends spoons with divine powers, then he's doing it the hard 
>>> way."
>>> --James Randi
>>> www.eyalredler.com
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
 Gary L. Wade
 http://www.garywade.com/
 
>> On Dec 17, 2019, at 2:12 AM, Redler Eyal  wrote:
> 
> I am drawing using core graphics. I tried turning copiesOnScroll and 
> this didn't seem to help.
> 
> I'll gladly write a feedback report but I'm not able to reproduce this so 
> I can't give an xcode project that will reproduce this... Isn't that a 
> requirement?
> 
> BTW, perhaps you know: Are there no release notes for app kit with 
> Catalina? All I can find are very general notes without mention of any 
> specific API. I could not find, for example, any mention of the 
> deprecation of copiesOnScroll and what it means (is is not always on, 
> 

Re: Catalina scroll view issues

[Redler Eyal via Cocoa-dev]

>> 
>> OK, I'll try to get the sysdiagnose from my users before submitting. I must 
>> say I'm really skeptic regarding the relation with my use of CG. It is not 
>> that CG is not used by CT and everything else is also using CG.
> 
> CG may not be the issue… and I cannot offer a better suggestion, but when I 
> rule out a possibility without proof, it usually turns out that I over look 
> the solution to the problem.  Good luck!

You're right, and I wasn't ruling it out. I actually sent my user a special 
build with an defaults option to turn off page drawing (so the page views are 
not doing any drawing CG or otherwise), the issue persists.

I also tried to see this issue while doing remote access using anyDesk, for 
some reason, the issue never showed up, when I disconnected, it showed up again.

Eyal



> Sandor
> 
>> The way it looks it seems very much related to the scrolling mechanism, the 
>> pre-rendered portion is not rendered but for some reason the scrolling 
>> mechanism thinks that it is. I really don't see how a core-graphic issue, 
>> and certainly not a misuse on my part could cause a view to be partially 
>> rendered.
>> BTW, do you think this type of issue is appropriate for a DTS incident?
>> 
>>> Here’s the developer release notes for Catalina:
>>> https://developer.apple.com/documentation/macos_release_notes/macos_catalina_10_15_release_notes
>> 
>> Thanks. I saw that but I recall that in the past you used to have app-kit 
>> specific release notes which were usually more detailed. 
>> 
>>> As an aside, it would be helpful to know why you chose CG for text 
>>> rendering. CT has gotten better with RTL and bidi text, but if you saw 
>>> particular issues there, reports about those can help everyone.
>> 
>> When I started developing this app (2002), there was no choice other then CG 
>> since core text didn't exist and the other technologies didn't support 
>> Hebrew and RTL well, if at all. So I wrote my own text engine and this was 
>> very good for me commercially as my app was the the first and only 
>> word-processor to support Hebrew (and later Arabic) properly on Max OS X. I 
>> had a similar experience with OpenType which was not initially supported and 
>> that also gave me an edge. As time passed Apple did improve the RTL support 
>> and was offering more APIs so theoretically I could have rewritten my code 
>> to use the new APIs but in reality I actually did the opposite and relied 
>> less on Apple's APIs (for example, parsing 'cmap' tables) because there were 
>> always bugs and even regressions which could render my app unusable upon an 
>> OS upgrade. Beyond the bugs, I think my RTL is better, or at least as far as 
>> I'm concerned as a native Hebrew speaker and having such low-level control 
>> over something that is core to my app is essential IMO.
>> 
>> Eyal Redler
>> 
>> "If Uri Geller bends spoons with divine powers, then he's doing it the hard 
>> way."
>> --James Randi
>> www.eyalredler.com
>> 
>> 
>> 
>> 
>> 
>> 
>>> Gary L. Wade
>>> http://www.garywade.com/
>>> 
> On Dec 17, 2019, at 2:12 AM, Redler Eyal  wrote:
 
 I am drawing using core graphics. I tried turning copiesOnScroll and this 
 didn't seem to help.
 
 I'll gladly write a feedback report but I'm not able to reproduce this so 
 I can't give an xcode project that will reproduce this... Isn't that a 
 requirement?
 
 BTW, perhaps you know: Are there no release notes for app kit with 
 Catalina? All I can find are very general notes without mention of any 
 specific API. I could not find, for example, any mention of the 
 deprecation of copiesOnScroll and what it means (is is not always on, 
 always off etc)
 
 Thanks,
 
 Eyal
 
> On 16 Dec 2019, at 16:07, Gary L. Wade  
> wrote:
> 
> 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 

Re: Catalina scroll view issues

[Sandor Szatmari via Cocoa-dev]

Eyal,

> On Dec 19, 2019, at 02:55, Redler Eyal via Cocoa-dev 
>  wrote:
> 
> 
>> 
>> Since you’re using CoreGraphics, it’s very likely there’s an edge case with 
>> your customers’ systems that you aren’t encountering.  CG is pretty much the 
>> lowest practical level in the graphics stack. Since your app does reproduce 
>> the issue but in other configurations than yours, you could still add it, 
>> but if you can include the system configuration data from About This Mac and 
>> data files from those affected customers, as well as screen shots, it can 
>> help. You might be asked for a sysdiagnose after the problem happens, so 
>> consider asking your customers to provide that as well.
> 
> OK, I'll try to get the sysdiagnose from my users before submitting. I must 
> say I'm really skeptic regarding the relation with my use of CG. It is not 
> that CG is not used by CT and everything else is also using CG.

CG may not be the issue… and I cannot offer a better suggestion, but when I 
rule out a possibility without proof, it usually turns out that I over look the 
solution to the problem.  Good luck!

Sandor

> The way it looks it seems very much related to the scrolling mechanism, the 
> pre-rendered portion is not rendered but for some reason the scrolling 
> mechanism thinks that it is. I really don't see how a core-graphic issue, and 
> certainly not a misuse on my part could cause a view to be partially rendered.
> BTW, do you think this type of issue is appropriate for a DTS incident?
> 
>> Here’s the developer release notes for Catalina:
>> https://developer.apple.com/documentation/macos_release_notes/macos_catalina_10_15_release_notes
> 
> Thanks. I saw that but I recall that in the past you used to have app-kit 
> specific release notes which were usually more detailed. 
> 
>> As an aside, it would be helpful to know why you chose CG for text 
>> rendering. CT has gotten better with RTL and bidi text, but if you saw 
>> particular issues there, reports about those can help everyone.
> 
> When I started developing this app (2002), there was no choice other then CG 
> since core text didn't exist and the other technologies didn't support Hebrew 
> and RTL well, if at all. So I wrote my own text engine and this was very good 
> for me commercially as my app was the the first and only word-processor to 
> support Hebrew (and later Arabic) properly on Max OS X. I had a similar 
> experience with OpenType which was not initially supported and that also gave 
> me an edge. As time passed Apple did improve the RTL support and was offering 
> more APIs so theoretically I could have rewritten my code to use the new APIs 
> but in reality I actually did the opposite and relied less on Apple's APIs 
> (for example, parsing 'cmap' tables) because there were always bugs and even 
> regressions which could render my app unusable upon an OS upgrade. Beyond the 
> bugs, I think my RTL is better, or at least as far as I'm concerned as a 
> native Hebrew speaker and having such low-level control over something that 
> is core to my app is essential IMO.
> 
> Eyal Redler
> 
> "If Uri Geller bends spoons with divine powers, then he's doing it the hard 
> way."
> --James Randi
> www.eyalredler.com
> 
> 
> 
> 
> 
> 
>> Gary L. Wade
>> http://www.garywade.com/
>> 
 On Dec 17, 2019, at 2:12 AM, Redler Eyal  wrote:
>>> 
>>> I am drawing using core graphics. I tried turning copiesOnScroll and this 
>>> didn't seem to help.
>>> 
>>> I'll gladly write a feedback report but I'm not able to reproduce this so I 
>>> can't give an xcode project that will reproduce this... Isn't that a 
>>> requirement?
>>> 
>>> BTW, perhaps you know: Are there no release notes for app kit with 
>>> Catalina? All I can find are very general notes without mention of any 
>>> specific API. I could not find, for example, any mention of the deprecation 
>>> of copiesOnScroll and what it means (is is not always on, always off etc)
>>> 
>>> Thanks,
>>> 
>>> Eyal
>>> 
 On 16 Dec 2019, at 16:07, Gary L. Wade  
 wrote:
 
 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 

Re: Catalina scroll view issues

[Redler Eyal via Cocoa-dev]

> Since you’re using CoreGraphics, it’s very likely there’s an edge case with 
> your customers’ systems that you aren’t encountering.  CG is pretty much the 
> lowest practical level in the graphics stack. Since your app does reproduce 
> the issue but in other configurations than yours, you could still add it, but 
> if you can include the system configuration data from About This Mac and data 
> files from those affected customers, as well as screen shots, it can help. 
> You might be asked for a sysdiagnose after the problem happens, so consider 
> asking your customers to provide that as well.

OK, I'll try to get the sysdiagnose from my users before submitting. I must say 
I'm really skeptic regarding the relation with my use of CG. It is not that CG 
is not used by CT and everything else is also using CG. The way it looks it 
seems very much related to the scrolling mechanism, the pre-rendered portion is 
not rendered but for some reason the scrolling mechanism thinks that it is. I 
really don't see how a core-graphic issue, and certainly not a misuse on my 
part could cause a view to be partially rendered.
BTW, do you think this type of issue is appropriate for a DTS incident?

> Here’s the developer release notes for Catalina:
> https://developer.apple.com/documentation/macos_release_notes/macos_catalina_10_15_release_notes

Thanks. I saw that but I recall that in the past you used to have app-kit 
specific release notes which were usually more detailed. 

> As an aside, it would be helpful to know why you chose CG for text rendering. 
> CT has gotten better with RTL and bidi text, but if you saw particular issues 
> there, reports about those can help everyone.

When I started developing this app (2002), there was no choice other then CG 
since core text didn't exist and the other technologies didn't support Hebrew 
and RTL well, if at all. So I wrote my own text engine and this was very good 
for me commercially as my app was the the first and only word-processor to 
support Hebrew (and later Arabic) properly on Max OS X. I had a similar 
experience with OpenType which was not initially supported and that also gave 
me an edge. As time passed Apple did improve the RTL support and was offering 
more APIs so theoretically I could have rewritten my code to use the new APIs 
but in reality I actually did the opposite and relied less on Apple's APIs (for 
example, parsing 'cmap' tables) because there were always bugs and even 
regressions which could render my app unusable upon an OS upgrade. Beyond the 
bugs, I think my RTL is better, or at least as far as I'm concerned as a native 
Hebrew speaker and having such low-level control over something that is core to 
my app is essential IMO.

Eyal Redler

"If Uri Geller bends spoons with divine powers, then he's doing it the hard 
way."
--James Randi
www.eyalredler.com






> Gary L. Wade
> http://www.garywade.com/
> 
>> On Dec 17, 2019, at 2:12 AM, Redler Eyal  wrote:
>> 
>> I am drawing using core graphics. I tried turning copiesOnScroll and this 
>> didn't seem to help.
>> 
>> I'll gladly write a feedback report but I'm not able to reproduce this so I 
>> can't give an xcode project that will reproduce this... Isn't that a 
>> requirement?
>> 
>> BTW, perhaps you know: Are there no release notes for app kit with Catalina? 
>> All I can find are very general notes without mention of any specific API. I 
>> could not find, for example, any mention of the deprecation of 
>> copiesOnScroll and what it means (is is not always on, always off etc)
>> 
>> Thanks,
>> 
>> Eyal
>> 
>>> On 16 Dec 2019, at 16:07, Gary L. Wade  wrote:
>>> 
>>> 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 

Re: Catalina scroll view issues

[Gary L. Wade via Cocoa-dev]

Since you’re using CoreGraphics, it’s very likely there’s an edge case with 
your customers’ systems that you aren’t encountering.  CG is pretty much the 
lowest practical level in the graphics stack. Since your app does reproduce the 
issue but in other configurations than yours, you could still add it, but if 
you can include the system configuration data from About This Mac and data 
files from those affected customers, as well as screen shots, it can help. You 
might be asked for a sysdiagnose after the problem happens, so consider asking 
your customers to provide that as well.

Here’s the developer release notes for Catalina:
https://developer.apple.com/documentation/macos_release_notes/macos_catalina_10_15_release_notes

As an aside, it would be helpful to know why you chose CG for text rendering. 
CT has gotten better with RTL and bidi text, but if you saw particular issues 
there, reports about those can help everyone.
--
Gary L. Wade
http://www.garywade.com/

> On Dec 17, 2019, at 2:12 AM, Redler Eyal  wrote:
> 
> I am drawing using core graphics. I tried turning copiesOnScroll and this 
> didn't seem to help.
> 
> I'll gladly write a feedback report but I'm not able to reproduce this so I 
> can't give an xcode project that will reproduce this... Isn't that a 
> requirement?
> 
> BTW, perhaps you know: Are there no release notes for app kit with Catalina? 
> All I can find are very general notes without mention of any specific API. I 
> could not find, for example, any mention of the deprecation of copiesOnScroll 
> and what it means (is is not always on, always off etc)
> 
> Thanks,
> 
> Eyal
> 
>> On 16 Dec 2019, at 16:07, Gary L. Wade  wrote:
>> 
>> 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
> 

Re: Catalina scroll view issues

[Redler Eyal via Cocoa-dev]

I am drawing using core graphics. I tried turning copiesOnScroll and this 
didn't seem to help.

I'll gladly write a feedback report but I'm not able to reproduce this so I 
can't give an xcode project that will reproduce this... Isn't that a 
requirement?

BTW, perhaps you know: Are there no release notes for app kit with Catalina? 
All I can find are very general notes without mention of any specific API. I 
could not find, for example, any mention of the deprecation of copiesOnScroll 
and what it means (is is not always on, always off etc)

Thanks,

Eyal

> On 16 Dec 2019, at 16:07, Gary L. Wade  wrote:
> 
> 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

[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: Catalina scroll view issues

[Allan Odgaard via Cocoa-dev]

On 14 Dec 2019, at 21:16, Redler Eyal via Cocoa-dev wrote:

I'm getting reports from users complaining about a strange display 
issue on Catalina with my app.

[…]
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.


Does it look anything like this: 
https://github.com/textmate/bugs/issues/33 ?


We’ve gotten a bunch of reports like this for TextMate on Catalina.

The only thing I can think of is that we opt out of responsive 
scrolling, so maybe that is a less tested code path on Catalina. The 
issue itself very much looks like a system bug.


We opt out of responsive scroll because the line numbers is a separate 
NSScrollView and with responsive scroll enabled, I know of no way to 
synchronize the two scroll views (since notifications about positions on 
the main thread may be delayed, due to background thread scrolling).


Since layer backed views effectively broke our ability to support 
transparent backgrounds, I have some unreleased code where we have 
switched to making the line numbers a floating subview so that we 
don’t have to opt out of responsive scrolling. But I have no idea if 
this fixes the issue, as I haven’t updated to 10.15 myself.

___

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

[Rob Petrovec via Cocoa-dev]

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

[Gary L. Wade via Cocoa-dev]

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

Catalina scroll view issues

[Redler Eyal via Cocoa-dev]

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