Re: jumpy scrolling on the Mac

Another observation.

 

Only the text that is entering view is ‘smeared’ (I don’t know how else to describe it). The text already in view is fine. This happens even when I only scroll 1 line at a time very slowly.

 

Also, if I click on the arrows in the scrollbar this does not happen. It only happens when scrolling with the mousewheel.

 

 

From: John Selverian <[email protected]> 
Sent: Tuesday, May 21, 2024 9:06 AM
To: 'Roland Hughes' <[email protected]>; 'Mathew Robertson' <[email protected]>; '[email protected]' <[email protected]>
Subject: RE: [Foxgui-users] jumpy scrolling on the Mac

 

I added a repaint timer. It gets called but I don’t notice any difference, it is still jumpy.

 

I also tried Adie and see the same problem, i.e., jumpy text.

 

I also see this problem in an FXTable not just FXList.

 

If I scroll using the ‘thumb’ in the scroll bar instead of the mousewheel it looks fine.

 

js

 

 

From: Roland Hughes via Foxgui-users <[email protected] <mailto:[email protected]> > 
Sent: Tuesday, May 21, 2024 5:28 AM
To: Mathew Robertson <[email protected] <mailto:[email protected]> >; [email protected] <mailto:[email protected]> 
Subject: Re: [Foxgui-users] jumpy scrolling on the Mac

 

Currently I'm not coding with FOX, but I've been writing software on many different platforms for roughly 40 years. I watched your video and read the reply from dpeterc. It probably is an XQuartz specific issue like they say . . . but . . .

 

Where are you getting your data from?

 

I see this a lot with new developers and the occassional developer that just wasn't thinking. They do database/file I/O and __wait__ for its completion rather than catching a signal it has completed via some connected callback. With a tiny amount of data it works even on an underpowered test machine. Then you get production levels of data. Things jerk, hang, appear to lock up, because there is some form of data/network I/O blocking everything.

 

I do like the two solutions dpeterc proposed. I have no idea how to do such things on Mac because I never write software for that platform. I have worked on many low powered embedded devices and I can tell you that caching any image, even a solid background color, and BLITting it onto the screen can give you a snappy UI on a machine that has no GPU, like this one.

 

https://www.hillrom.com/en/products/connex-spot-monitor/

 

Although we used Qt 4.8 for that, the concept is the same. So is the solution. You have to develop for your least capable platform (Mac), then cross compile the solution for better more capable platforms.

 

To support the hardware management wanted to base the above unit on, we had to code our own base Widget, completely replacing the default paint method provided by Qt so we could BLIT from caches. The built in image caching wasn't enough.

 

Just my 0.0002 cents.

 

On Tue, 2024-05-21 at 16:45 +1000, Mathew Robertson wrote:

Is a solution to this simply force a repaint() say after 100ms ? see below.

 

And/or could FXApp.cpp detect a "slow repaint" scenario, say by measuring the time between chores ?

 

cheers,

Mathew Robertson

 

 

FXMAPDEF(...this-class...)   this-class[] = {

  ...

  FXMAPFUNC(SEL_COMMAND,FXScrollArea::ID_HSCROLLED,this-class::startRepaint);

  FXMAPFUNC(SEL_TIMEOUT....this-class::doRepaint)

}

 

this-class::startRepaint(...) {

    getApp()->addTimeout(.... window->repaint()   ... );     // <-- obviously need to remove-repaint if the scroll-event is stopped.

}

 

this-class::doRepaint(...){

   getApp()->repaint();

}

 

 

On Tue, 21 May 2024 at 10:02, Jeroen van der Zijp <[email protected] <mailto:[email protected]> > wrote:

On Mon, 20 May 2024 18:48:20 -0400
"John Selverian" <[email protected] <mailto:[email protected]> > wrote:


> I'm running XQuartz 2.8.5 (xorg-server 21.1.6) and the scrolling
> is very jumpy. The text gets blurred until the scrolling stops.
> Other apps not using X11 are fine when they scroll.
> 
>  
> 
> I posted this to the XQuartz site with a short video:
> 
>  
> 
>  
> 
> https://github.com/XQuartz/XQuartz/issues/397#issuecomment-212073
> 4621


I can't say what the problem is, but my gut feeling says it has something
to do with events piling up somewhere.


FOX tries to be very efficient processing events: we're pulling the event
queue dry, and only start drawing when we catch up.  XExpose events are
piled into the "repaint list"; rectangles which touch or overlap are
consolidated, if the new area is less than the sum of the two old
areas.


So, onces it starts painting, it actually paints less rectangles than
originally were received.


If a widget gets scrolled, parts of the window may have not getting
repainted yet.  FOX solves this by elongating the to-be-repainted
areas in the direction of the scrolling, and bitblits the rest.


Thus, we keep compounding dirty-rectangles until paint-time.


This works pretty well, and prevents processing of the event loop
from falling behind.


This may feel counter-intuitive, but redrawing is often more expensive
than processing regular events, so deferring this until we've caught up
with the event stream means we're never in the position of redrawing
something that we may ALREADY know to be have to be redrawn AGAIN. 
[think of multiple consecutive scrolls].


So what are we seeing in the video? we're seeing LOTS off scrolling,
and the system keeps piling up (or growing) repaint rectangles, not
being able to catch up.


Possible causes:


        1) Extremely high event rate from mouse?


        2) Slow drawing?


        3) Very high refresh-rate screens?


        4) Other callbacks going on preventing the system to reach
           the "idle" state, i.e. select() or pselect() returning
           with NO events. 


On my i5-8500T with 165 Hz screen (2K), using iGPU, it has no trouble
whatsoever to smoothly keep up.  


So it must have something to do with how Apple does things, or may 
depend on something going on inside the application.


To rule out your application, may load a bunch of text into the Adie
text editor and scroll it vigourously. If you seen the same problem,
it may be the Apple issue; if the problem is confined to your app,
then some profiling may help.

 


   -- JVZ

 

 

 

 

 

 

 

 


_______________________________________________
Foxgui-users mailing list

[email protected] <mailto:[email protected]> 

https://lists.sourceforge.net/lists/listinfo/foxgui-users

_______________________________________________

Foxgui-users mailing list

[email protected] <mailto:[email protected]> 

https://lists.sourceforge.net/lists/listinfo/foxgui-users

 

-- 

Roland Hughes, President

Logikal Solutions

(630)-205-1593

 

http://www.theminimumyouneedtoknow.com

http://www.infiniteexposure.net

http://www.johnsmith-book.com

http://www.logikalblog.com

http://www.interestingauthors.com/blog

_______________________________________________
Foxgui-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/foxgui-users