Lazarus
Using the Lazarus IDE => Editor => Topic started by: Martin_fr on February 03, 2014, 02:21:02 pm
-
Started as reply to:
http://forum.lazarus.freepascal.org/index.php/topic,23238.msg140277.html#msg140277
2. One of the (almost) show stoppers for Lazarus in Mac Os is the terrible slowness of the Source Editor. At least in my dual core MacBook.
I thought that this would be fixed in RC2 but this behavior still exists.
Well I am not aware, that his was reported by anyone. So there is (was) no work/investigation into that.
And afaik, for many people this does no happen, for them it works fast.
Before going into details, there are 2 or 3 possibilities that come to mind first.
I assume a normal unit? few 100, maybe 3 or 4 thousand lines, of up to 1000 chars length.
Bigger should work too, I test with massive files sometimes, but lets start with that.
1)
(probably not) scrolling. This would be, if only scrolling was slow, but nothing else.
In old days (0.9.28 or 0.926 even), scrolling would mean to print all the chars in the new position, instead of moving the existing bitmap.
But then typing would be fast.
2)
font. Please try a different font or font size.
If your font is not strictly monospaced then the editor has to force it. This is more work. (though 40% cpu seems to high for this alone)Also on Mac,
(read notes at the end of post)
Some fonts use sub-pixels, which is not supported and leads to the same effect. For testing use a different font sizes.
Also ensure in the editor settings, page "editor/display", that the field "extra CHAR spacing" is set to 0. Any other value causes the same effect.
3)
too much repaint....
Can you disable the following 2 settings, and retry please. Page "editor/display":
- "Show overview Gutter"
- "Show Class/Proc Hint"
4)
Any other IDE operation.
Open a none-pascal/plain text file, and see if there is a difference.
Or put SynEdit (if you want with pas HL) on a Form, and run this (if you copy and paste text, then you need no file loading, no code of your own)
5)
How much is it affected by the size of the window? Is the dependency "linear" ?
e.g. editor shows only 2, 10, 20, 40 lines, (always the same length)
Does the cpu go like 2%, 10%, 20%, 40% ?
-----------------
About "2 font"
- Re-compile the IDE with SYNFONTDEBUG defined ( -dSYNFONTDEBUG ),
- Then start it from console, with a logfile:
In a shell:
/path/to/lazarus/lazarus.app/Contents/MacOS/lazarus --debug-log=/path/to/yourfiles/laz.log
Check for lines, like:
Final result for FONT Width=xxx Overhang=xxx eto=BOOL
If eto is FALSE, (for the font, that you use / see name) then all is good. If it is true, then the extra work happens.
About "3 too much repaint"
- Re-compile the IDE with SYNSCROLLDEBUG defined ( -dSYNSCROLLDEBUG ) Can be done together with the above)
- Then start it from console, with a logfile
Look for the lines that say
PAINT SynEdit123 0x200000 sfHasScrolled=BOOL rect=(10,5,200,100)
- If you edit a line, the high of the rect(last minus 2nd figure / 100-5 = 95) should be 1 or 2 lines only.
- Note you may get a 2nd paint of 40 to 60 pixel width all to the right rect=(500, Y, 550, Y2)
------
Additionally, to make sure nothing else of unexpected nature happen, you might want to compile with:
SynCheckPaintLock
AssertSynMemIndex
SynAssert
SynAssertFold
Those cause Exceptions, if things go wrong, so you will notice.
And add -Criot too
-
I use Lazarus 90% of the time on Mac, with debugging and compiling on Windows XT and Ubuntu. I run it on three Macs, two desktops and one MacBook Pro. Mostly OS X 10.6.8, but also 10.8.5. Lazaus 1.0.14 at the moment.
I have not noticed anything unusual about the editor. Martin will know better, but perhaps a clean reinstall might help?
Cheers,
Frederick
Edit:
The MacBook Pro is 2.7 GHz Intel Core i7 with 4 GB RAM.
Sorry, I may be off topic, I have not yet tried RC2. :(
I'll give it a try and report back.
-
Just installed RC2 on OS 10.6.8 and compiled a couple of big projects. No obvious problems, and nothing noticeably slow about the editor.
Cheers,
Frederick
-
@Frederick
How about, if you set "Extra Char Spacing" to 1 ?
-
Maybe (?) a bit slower with Extra char spacing = 1, but really hard to notice any diference.
Not sure why I would want that, but it seems to work ok. I use Andale Mono font by the way.
Cheers,
Frederick
-
@Marti_Fr,
Wow! Great post! Lot's of homework! :)
I've used the Lazarus Windows version and was impressed by it's lightness and performance compared to Delphi.
On the Mac, which is my main computer, I've been experiencing choppy editing (High cpu usage) since version 0.9.
If I'm the only one, there's probably something wrong with my editor settings. Maybe an old pref/config file?
Anyway, I will try what you suggest and report back.
Thanks a lot! :)
Hoch.
-
@Martin_Fr,
This is what I found:
CPU Usage goes up to 40% on a unit of about 800 lines and 20% on a program file of 27 lines. So length matters... But code length is not the problem!
The CPU goes up *when I'm seeing the cursor*. If I scroll up or down with the scroll bar, so I do not see the cursor, the CPU usage drops to 0.
If I click to reposition the cursor in the new section of the code I'm watching, CPU goes up again.
Anyone can reproduce this?
Thanks! :)
Hoch.
-
If you do the log, please also add: -dSynCaretDebug
-
CPU Usage goes up to 40% on a unit of about 800 lines and 20% on a program file of 27 lines. So length matters... But code length is not the problem!
That is also odd. Especially since I can not see how that relates to the caret.
Can you attach or mail your EditorOptions.xml please?
I tested Code here with 300 thousand lines, and no problems, except:
- Select all, and perform indent / unindent => DO not do that with more than 20 thousand lines. That does work in trunk. (1.3)
- replace all for a search term that appears 100000 times. Again better in trunk.
- anything with several lines of more than 100 thousand chars in one line, starts slowing down
Not scenarios that are very common.
-----------------------
Does the option "allow caret past end of line" make a difference? (Settings, Editor/ General)
-
Even on a 12 years old eMac with 700 MHz PPC processor I didn't perceive the editor to be slow.
-
I can easily get the %CPU above 50, even 70, by scrolling rapidly. I can't confirm a connection with the cursor though. However, I never noticed the editor being choppy, so have had no concern about it.
-
@Martin_Fr,
Testing on a unit with 758 lines:
1) Scrolling with the scroll bar slider's is pretty slow and a bit jumpy. My mouse pointer is always faster than the slider, unless I scroll really slow. When doing normal scroll (not too fast or slow) CPU usage goes up 80%
2) When seeing the cursor, switching from Monaco 13 antialiased to Andale Mono antialiased makes things a bit worse. CPU goes up more or less 5%.
NOTE: Disabling antialiasing *reduced the CPU usage from 40% to 20%* (average). But Monaco, 13 looks too ugly...
3) Disabling those two options didn't do much difference
4) Opening a text file of 370 lines had the same effect as with a pascal file. When I see the cursor, CPU usage goes up. When I scroll or resize the window so I don't see the cursor, CPU usage goes down to 0.
5) Size of the window affects CPU usage if the cursor is visible. If I make the window bigger, CPU usage goes up. If I make it smaller, it goes down.
*If I resize so the cursor gets hidden, CPU usage goes to 0*.
By the way if I have two docs opened, I select the second one and I make the window very thin so the editor can't show the doc tab, Lazarus hides the second tab and switches automatically to the first document instead of keeping the second document visible.
Seeing the cursor or hiding it from view, makes all the difference.
Thanks and greetings! :)
Hoch.
-
@Martin_fr,
I append my EditorOptions.xml
Thanks and greetings! :)
Hoch
-
@Martin_fr,
I found the problem with code indent. Indent was set to 0 spaces/tabs in my prefs.
If this is default, then no problem, if not, I've never touched this option so I probably suffer from a bad/old EditorOptions.xml file.
How can I reset this file?
Thanks! :)
Hoch.
-
If you delete the file (while the IDE is closed), a new one should be created automatically.
IIRC default is 2 spaces.
--------
About the PageControl tabs. After I found that "thin" means reduce width, not height, yes that is reproducible.
It should be reported on the bug tracker.
(Sorry, I do not maintain the carbon page control, so I cant help with this)
--------
About the speed. My bes guess is that something causes lots of repaints.
Can you try: open SynEdit.pp go to line 3688, that is inside
procedure TCustomSynEdit.Paint;
FScreenCaret.Hide;
Comment that line.
Note, you may (or may not) get ghost images (left overs) of the caret, when you navigate
-
Ok, I may have found something, but I need to get our carbon expert on it.
It seems, that when a tiny bit (1 or 2 lines need repaint) the cliprect (which specifies the area) does not work.
So the editor paints all.
The caret triggers a paint of the area, where it was, each time it gets hidden. That are a few pixel, but due to the issue, it is a full repaint.
However, that does not link to the code size (unit of 30, or 700 lines).
-
@Martin_fr
I deleted the file EditorOptions.xml and recompiled Lazarus commenting the line you suggest in SynEdit.pp but it does not fix the issue, there's still high CPU usage when I have the Source Editor window selected and the blinking cursor visible.
What you suggest about the full repaints makes a lot of sense.
Hope you can fix this soon. Right now editing, scrolling and debugging feels really choppy here.
Thanks again for the support and fast answer! :)
Hoch.
-
I handed it to a colleague in the team.
He just reported back. So far a fix in trunk (1.3). Decission on merging (1.2) still needs to be done.
Revision: 43872
Author: dmitry
Date: 04 February 2014 05:17:45
Message:
carbon: minimize the custom view invalidation to reduce resources use
----
Modified : /trunk/lcl/interfaces/carbon/carbonprivate.pp
Attached is a patch. You can try that against 1.2RC
-
I am just testing. It seems to fix the speed, but introduces issues scrolling...
-
@Martin_fr,
I'm testing the patch and it seems to fix the high cpu usage when viewing the blinking cursor.
before the patch cpu usage was 40% with antialiasing on. Now it goes down to more logical 0,5% with antialising on.
Typing is faster but cpu usage when typing moderately fast is very high (50-60%).
Scroll is not fixed. It is as it was, too jumpy and slow with very high cpu usage (almost 90%).
Maybe too many redraws when scrolling?
Thanks and greetings! :)
Hoch.
-
@Martin_fr,
Window resize, scroll with slider and with scroll wheel are very slow (high cpu usage).
Any possibilities of fixing this?
With those fixes, the editor would reach near perfection on Mac OS! :)
Thanks and greetings! :)
Hoch.
-
As I said, it is a colleague of mine who looks at it.
I maintain SynEdit, however this problem is caused by the underlying carbon widget code in the LCL. And that is maintained by someone else.
When he gets back, I will let you know.
-
@Martin_fr,
Ok! Great!
Thanks! :)
Hoch.
-
there should more updates through this weekend. please wait.
-
@skalogryz,
Ok. Thank you! Looking forward to have good news from you!
The patch you issued does make a *huge difference*.
Lazarus feels much faster and the fans of my Macbook are quiet now, less CPU usage also means less watt consumption and less CO2 emissions! :-)
Hope you can fix the scroll and typing issues.
Keep up the good work, guys! The Lazarus editor is one of the best!!
Happy Pascal coding and Greetings! :)
Hoch.
-
@skalogryz,
Any news?...
Thanks and greetings :)
Hoch.
-
No updates, sorry. Didn't get enough time to debug and fix properly.
We'll try to work some night this week.
One thing that could help: is it possible for you to create a stand-alone project with SynEdit that shows the problem?
-
@skalogryz,
It is easy to reproduce.
Just execute Lazarus on Mac Os, open a long unit and scroll with the slider or the mouse wheel.
You will notice that the scroll is slow and jumpy and that the CPU usage is very high.
Same thing when you type moderatly fast. But it is not as annoying as the scroll issue.
Thanks and Greetings! :)
Hoch.
-
@skalogryz,
It is easy to reproduce.
Just execute Lazarus on Mac Os, open a long unit and scroll with the slider or the mouse wheel.
You will notice that the scroll is slow and jumpy and that the CPU usage is very high.
Same thing when you type moderatly fast. But it is not as annoying as the scroll issue.
Thanks and Greetings! :)
Hoch.
could you please test the following project. Is there any difference in CPU usage between No Paint TextOut and ExtTextOut?
-
Scrolling may indeed be an issue. That code does not work for me either....
As for typing text, please try in the Options (Editor/display) to hide the "overview gutter", this may speed up things a little.
-
@skalogryz
Thanks for your code!
I'm I supposed to see a timer? If so, I don't see it. I append a screenshot.
@Martin_fr
I disable 'overview gutter' but does not seem to make a difference.
What I see is that when you type moderalty fast in document with a few lines (20) the cpu usage is more or less 10%
Which is normal. When the document is long, a unit of 1250 lines, the cpu usage goes up to 20-30%.
It is strange but I can live with this.
As you say, scrolling with the slider or mousewheel is a real issue.
Thanks and greetings! :)
Hoch.
-
@skalogryz
I'm I supposed to see a timer? If so, I don't see it. I append a screenshot.
No timer show should up. I was curious about the CPU usage.
The time is there on the page and it invalidates/repaints the whole form every 67 mls.
There're 2 types of rendering text. TextOut and ExtTextOut. TextOut is supposed to be faster and less CPU expensive.
Another thing I expect is when you select ExtTextOut your CPU usage should be the same or higher than when you've the Lazarus editor opened.
(Please note that this test form size needs to be resized to match the source editor).
What I'm trying to do is to figure out the slowest part of the text rendering.
-
@skalogryz
TextOut is marginally faster, 71-72% vs 74-75% for ExtTextOut.
With the patch issued here the Lazarus editor has a near 0 cpu usage except when you scroll.
Seems a stable patch. Should go into 1.2.
Thanks and greetings! :)
Hoch.
-
You refer to the patch I posted (the one that is in trunk already)?
You said cpu also depends on size of unit. Please compare:
When the editor is scrolled all to the end of the file (at least 1000 lines in file)
- edit the last visible line in the editor
- edit the first visible line in the editor
Same when the editor is scrolled to the top of the unit
DO those with and without the overview-gutter, please.
-
@Hoch, @Martin_fr
what is your OSX version?
@Hoch,
If you select No Paint, what's the CPU usage? (please note that the form is still invalidated by the timer)
-
Well, it's quite obvious that the text rendering is extremely slow in Carbon.
As an example the same test on Windows consumes at around 1%-2% of CPU (Intel Core(TM) 2CPU 2Ghz).
That's with ClearType enabled (ClearType acts pretty much the same as OSX default font anti-aliasing). Also, even if antialiasing is disabled for Carbon the CPU consumption is still higher.
Looking at the carbon code, I can see a lot of objects are being reallocated, so I'll try to improve the performance by caching some of them.
Another thing that **might** help is to rewrite the rendering engine, that's based on ATSU now (for OSX 10.4 compatibility) to CoreText. Both APIs are deprecated anyway with the whole Carbon. But ATSU is more deprecated :)
-
Hoch, could you please run this test. Please compare CPU for "Quartz 2D" and "CoreText" (they should be the same) to the "TextOut"
-
Martin_fr & skalogryz,
Sorry for the delay. I had a very busy month and also, I'm not receiving the emails notifications from the forum…? So I thought that there were no new answers to this topic.
@ Martin_fr
Cpu usage of character drawing while typing is high but I can live with that.
What I think is critical and needs a fix, and maybe related, is the scrolling issue on Mac OS X. It is slow, jumpy and consumes a lot of cpu.
@scalogryz, my OSX version is 10.6.8.
I ran your last test and cpu usage is:
. No Paint: 11%
. TextOut: 73%-79%
. ExtTextOut: 68%-77%
. Quarz2D: 63%-76%
. CoreText: 75% (steady. But shows a white screen)
...Overall very similar.
Thank you and greetings! :)
-
Thanks for testing. No sure why CoreText would show you blank screen.
...Overall very similar.
Well, it appears that without any kind of caching we won't get any better results from Mac.
With that said, it appears that large scrolling and/or resizing would always end up in high CPU usage (since cache would need to be refreshed at all times).
-
@skalogryz,
So, You mean that the slowness is in the Mac OS libraries and how they handle text?
This looks strange to me... Obviously there are other Mac OS applications that don't have this scrolling issues...
Thanx and greetings! :)
Hoch.
-
So, You mean that the slowness is in the Mac OS libraries and how they handle text?
No. It's not an issue with OSX, it's more an issue with LCL (and how LCL treats the text and text drawing).
OSX itself encourages "caching" of text-object used for rending. But in LCL there's no such "text objects".
This looks strange to me... Obviously there are other Mac OS applications that don't have this scrolling issues...
Please give an example.
The app should contain the same amount of text though as SynEdit. (I believe just copying a unit text and adjusting the font size to match Lazarus IDE should be enough for testing).
-
@skalogryz,
Ok. Thanks for the explanation.
So no way of fixing this in LCL? Maybe too complex?...
By other apps I meant, those outside of free pascal (browsers, openoffice, etc.)
Thanks and greetings! :)
Hoch.
-
So no way of fixing this in LCL? Maybe too complex?...
Still should be possible. Again caching should improve the performance somehow.
By other apps I meant, those outside of free pascal (browsers, openoffice, etc.)
How about less text-layout sophisticated :) Such as Xcode, TextEdit? What's the CPU usage for them on scrolling (scrolling by dragging scrollbar from top to bottom)?
-
@skalogryz,
If I scroll up and down a pas file of 4.300 lines, same window size, using the slider, with more or less the same scroll speed, I get the following cpu usage:
. TextEdit: 18%-22%
. Lazarus editor: 65%-70%
No Xcode, sorry.
Greetings! :)
-
I can confirm that the issue is still present.
Any info about fixing it?
-
TCarbonWidgetSet.ScrollWindowExIs definitely not working here. It is called with
if ScrollWindowEx(Handle, 0, LineHeight * Delta, @srect, @srect, 0, nil, SW_INVALIDATE)
If you look at it, then it first checks
if (flags and SW_SCROLLCHILDREN <> 0) then
Which is False.
Then
if (Flags = 0) thenwhich is also false.
So it goes to the last block
if flags and SW_INVALIDATE <> 0 then
And that will invalidate "prcClip". Meaning the entire synedit is invalidated.
But it should use HIViewScrollRect to scroll
I once tried to fix it with {$IFDEF NewScrollWindowEx}
But IIRC that is not fully working yet either.
You can try to define NewScrollWindowEx, and see if it helps. But I do not know.
------------------
You can also just try to do
flags := 0
At the start of ScrollWindowEx
-
I've just tried both options. They adds a performance, but:
first - lots of glitches, regions updated only partial
second (flags:=0) is almost perfect, but there is a text caret trail if you scroll via keys (up and down) by one line.
I think the updated region should be one line wider somehow.
-
I've just tried both options. They adds a performance, but:
How much?
Yes the IFDEF code is unfinished...
first - lots of glitches, regions updated only partial
second (flags:=0) is almost perfect, but there is a text caret trail if you scroll via keys (up and down) by one line.
I think the updated region should be one line wider somehow.
As workaround you can deal with that in SynEdit.pp
Line 4405
if ScrollWindowEx(Handle, 0, LineHeight * Delta, @srect, @srect, 0, nil, SW_INVALIDATE)
Just add
FScreenCaret.Hide;
in front of it.
You may need to do (but I do not think you need/ and if not needed then do not:
UpdateCaret;
after the if then else block.
TCarbonWidgetSet.ScrollWindowEx would need to call
LCLIntf.HideCaret(Handle)
and
LCLIntf.ShowCaret(Handle)
-
Btm, if flags = 0 has side effects (e.g maybe TScrollbox)
then
if flags and SW_INVALIDATE <> 0 then flags := flags - SW_INVALIDATE
So other flags are kept
-
Talking about performance improvement - after "flags:=0" I'm really satisfied with it. There is no lags, you can just scroll and edit text normally.
I think we should beat this issue down and commit a fix to the trunk.
I've just tried to hide a caret as you suggested, but it didn't help. The caret was still there. Also please note the screenshot - there is also a green trail of the current line highlight.
I think it would be better to somehow invalidate one additional line or find a way to hide both things - a caret and a line highlight.
Please suggest anything else to fix this. I'm ready to change the source and test it.
-
The it seems, that HIViewScrollRect does not deal with already invalidated areas.
SynEdit first invalidates the current line (if there is highlight on the current line *AND* the current line changes), and then scrolls.
This may mean there may be other artefacts (like the red border for begin/end pairs).
You can add an
InvalidateLines(1,1) // first line on screen
OR
InvalidateLines(LinesInWindow, LinesInWindow+1) // last line on screen
in the
if ScrollWindowEx(Handle, 0, LineHeight * Delta, @srect, @srect, 0, nil, SW_INVALIDATE)
then begin
depending on delta being positive or negative.
If you add them unconditional, you will have a full screen invalidate.....
---------------
Yes it needs a proper fix.
But I am a bit short on time now.
-
I've tried to
InvalidateLines(1,1) or InvalidateLines(LinesInWindow, LinesInWindow+1) or both, or different values, but it doesn't seem to affected anything(
-
You tried in SynEdit, and AFTER the scrollWindowEx?
Then try
InvalidateLines(1,2) // first line on screen
OR
InvalidateLines(LinesInWindow-1, LinesInWindow+1) // last line on screen
Though it may be that this is outmarted by SynEdits internal, and you need to call InvalidateRect directly...
Then you need to calculate the rect yourself.
Anyway.
Sorry, but I havent got the time to look deeper now.
This needs to go into the carbon class.
The IFDEF was a start on that. But it needs to be finished.
-
Oh I've found out why it didn't work - it invalidates a first and a a last line of the entire synedit, not just of what is on screen.
So yes, we need to calculate a rect that is on screen to use correct values.
-
Ups, then it is Invalidatelines(TopLine, TopLine)
But topline is already changed.... So that will not work either.
You have the rect that was scrolled, you either need to invalidate the top (delta) pixels, or bottom delta
-
Ok,
Something is finally working:
Invalidatelines(TopLine+1, TopLine+1);
But only when you scroll up.
-
That is decreasing performance btw... even if we invalidate just one line it adds lags on scrolling.
-
If you invalidate the wrong line, then yes.
FYI:
If you invalidate the top/left 1 pixel of a form or control, AND the bottom right 1 pixel, then you have invalidate the whole control (minimum enclosing rectangle of the 2 pixels)
So if the caret (text cursor) is on the bottom line, and you press down, therefore scrolling up, then there will be new lines scrolling in from the bottom.
In this case you can invalidate additional lines at the bottom.
But if you invalidate one single line at the top, then you invalidated all.
-
I see. Then the best workaround would be just to hide a caret somehow.
-
btw maybe you know, is there someone who is working on cocoa interface and when to expect something that works on it?
-
Hiding the caret, just invalidates the area of the caret. The next paint will deal with it.
BUt the scroll comes before. And it does not honour the invalidate correct.
That must be fixed.
I have no idea how much work that will be. The IFDEF code was a start. But it will be some time before I might have any chance to even think about continuing on it.
All else is just workarounds, no solutions
-
Well, that is pretty sad. It looks like just a few people is interested in lazarus on osx. :(
-
From what I see, there're 2 completely different issues:
* scrolling issues with not improper invalidation. To debug it - a stand alone project is needed that would show the problem. Debugging it with SynEdit is too complicated.
* performance issues with rendering text. Refer to earlier Hoch post. If font antialiasing is disabled the text is rendered much faster. Thus text output needs to be revised (on widgetset level) to use caching (?) or something.
-
I thought I always saw scrolling mentioned.
At current I want have the time. But if I have it I may look at a test case for ScrollWindowEx.
The issue is, that if any part of the to-be-scrolled area is invalid, then only the valid part should be scrolled, and the rest should be invalidated.
Unless Carbon can have several invalidated areas. (all other WS do minimum enclosing rectangle)
-
I thought I always saw scrolling mentioned.
The test cases I made for Hoch had nothing but text rendering.
That's why I consider one of solutions is to speed up the text output... besides Carbon it using the deprecated ATSU API anyway.
So updating to conditional usage of CoreText might allow Carbon widgetset to survive another OSX release :)
Why conditional? CoreText is not available in OSX 10.4
This knowledge my be beneficial to Cocoa (if Cocoa suffers from the same issue).
IIRC, Cocoa is good enough to compile an application with SynEdit.
For scrolling issue - yes, please review ScrollWindowEx test case. The morel lightweight example is, the easier it would be to debug and fix.
Trying to reproduce an issue with SynEdit (with lot of it's settings and compiler conditions) doesn't seem easy enough to spend time on it.
-
Report it as a bug, assign; writing a testcase to me.
I will do it, but if no miracle happens it will be a couple of weeks before I get there
-
In my opinion this is not text rendering problem but scrolling problem. Here is my test app and bug report: https://bugs.freepascal.org/view.php?id=34829. Whole content is full repaint while scrolling in TScrollBox, TDrawGrid , but not in TListBoxe. Only TListBox scrolls smoothly on MacOS.